Define usersig memory for ATmega*RF[AR]* parts #1406
Conversation
#####
# Three separate flash pages
# - Offset 0x100 in signature row
# - Only programmable with JTAG or HVPP
# - Readable from an application
# - Cannot be read using ISP
# - Not erased by chip erase
#
memory "usersig"
paged = yes;
size = 768;
page_size = 256;
num_pages = 3;
offset = 0x100;
mode = 0x41;
delay = 50;
blocksize = 256;
readsize = 256;
;
|
Since you have access to ATmega128RFA1, just wondering if you can help testing this PR once you have some time. Thanks. |
|
I don't have any hardware I can test this with, sorry. |
No. My understanding is that usersig is special. Apparently it does not allow ISP programming. Has to be Jtag or HVPP. |
|
My hope(!) is that the current code base caters for this special usersig memory: |
|
I think we can still merge this if no one comes forward to help testing before 7.2 release. I tend to think it may work. Even if it does not, it does not really make things worse. |
|
But we may want to hear from @dl8dtl to see if he is comfortable to merge without testing, as this usersig memory for the RF AVRs seem to be quite different from others. |
|
Updated the definition of the ATmega*RF(A1|R2) parts. I would argue that while this might not be sufficient to deal with Issue #379 it is at least necessary to do so. Edit: while I was at it, I also updated the memory write delays and chip write delays for all ATmega8/16/32/64/128[A] parts |
I'd ague we can, as the memory description is taken from the relevant datasheet entries. |
|
How important is it for us to really test this? Someone in Norway sells a complete Atmel Zigbee kit with an ATmega256RFR2 Xplained Pro board for ~$8 including shipping. https://www.finn.no/bap/forsale/ad.html?finnkode=309369539&ci=16 |
|
At that price, I will say go ahead. Thanks. |
|
OK, I just bought it. It will arrive within a week or so. Hopefully, I can use this to make sure #379 can be closed |
|
Umm, sorry, I read it too late. I have been part of the development team of the ATmega…RF… devices, and have a number of boards to test with (including a small self-built temperature sensor network). |
|
I'll dig out a board, and test. Promised. ;-) |
That Btw., test conducted on FreeBSD/arm64. I wonder how much work it would be to also have (read-only) access to |
Great to hear it works! I own a really flakey AVR Dragon (I have to touch the JTAG ping with a wet finger in order to get it to work), and I'm always getting an
Is it only the "RF" AVRs that has this memory? |
|
Basically all (newer) AVRs have a kind of production signature flash row, but for most of them, neither the access nor the contents is documented. Only the very first cells are documented (the device signature, and oscillator calibration values). Usually, they also contain the lot number, the number of the wafer inside the lot, and the X/Y position of the chip on the wafer – maybe more. Hmm, I thought they were documented for the RF devices, but it seems they aren't. It's only the Xmegas that started to document some of them. So OK, let's forget about that right now. ;-) |
|
Btw., using the AtmelICE, access to the user signature row does not work. Instead, it returns me the production signature row: You can for example recognize the "1e a8 02" signature ID (the flash is organized in 16-bit words, but the signature only uses the even bytes). However, if I proceed reading, I get the user signature (offset one page): Also, as soon as I switch to a different memory region, the command starts to timeout, even though it eventually returns the correct data: This behaviour could not be observed with version 7.1. (I have both compile trees in parallel here.) |
|
@dl8dtl So with this PR applied to v7.1, it works fine with the Atmel ICE, but not with the git main version? BTW I'll receive an ATmega256RFR2 Xplained Pro board (together with various zigbee addons) soon that I can use to help out with testing |
|
It works as intended with the Git version, and a JTAGICEmkII. |
|
So different programmers do different things when instructed to read the |
Good question. |
With a bit of fair wind the following memory definition for
ATmega128RFA1ATmega256RFR2ATmega128RFR2ATmega64RFR2ATmega2564RFR2ATmega1284RFR2ATmega644RFR2could be sufficient to solve Issue #379. Only tests will tell whether JTAG or HVPP programmers "do the right thing" with this special memory of these special parts. If anything, perhaps theoffsetmight be problematic but let's see who can help testing.