[bug #44644] Missing access to user signature rows in ATmega256RFR2 et al.

[avrs-admin]

Jörg Wunsch
Fri 27 Mar 2015 09:22:29 AM UTC

ATmega256RFR2 and its relatives offer user signature rows.

AVRDUDE currently has no way to access them.

This issue was migrated from https://savannah.nongnu.org/bugs/?44644

[mcuee]

Reference discussions.
https://www.avrfreaks.net/forum/solved-reading-user-signature-pages-c
https://www.avrfreaks.net/forum/user-signature-row
https://www.avrfreaks.net/forum/read-mac-address-atmega-256rfr2-chip-c

[mcuee]

@jkent

Sorry to ping you here, Since you have the ATmega128RFA1, just wondering if you are able to access the user signature area of the chip. Thanks.

[mcuee]

Help wanted from the community to check whether the issue still exists. PRs are welcome.

[mcuee]

@stefanrueger

-c dryrun does help to reproducing the issue here even though I do not have the chip. From the output we can see there are no access to the user signature section.

We probably do not need -c dryrun to confirm this issue but using -c dryrun is an easy way.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dryrun -p atmega256rfr2 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1ea802 (probably m256rfr2)
avrdude> part
AVR Part                      : ATmega256RFR2
Chip Erase delay              : 18500 us
PAGEL                         : PD7
BS2                           : PE2
RESET disposition             : possible i/o
RETRY pulse                   : SCK
Serial program mode           : yes
Parallel program mode         : yes
Timeout                       : 200
StabDelay                     : 100
CmdexeDelay                   : 25
SyncLoops                     : 32
PollIndex                     : 3
PollValue                     : 0x53
Memory Detail                 :

                                  Block Poll               Page                       Polled
  Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
  ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
  eeprom                 65    50     8    0 no       8192    8      0 13000 13000 0x00 0x00
  flash                  65    50   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
  lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
  hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
  efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
  lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
  signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
  calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00
avrdude> quit

avrdude done.  Thank you.

[stefanrueger]

So looks like the we need to define usersig at the very minimum. From reading the data sheet, it should be sth like:

    #####
    # 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;
    ;

[stefanrueger]

The usersig memory of classic parts ATmega*RF(A1|R2) is a special memory in that it is only programmable with JTAG or HVPP. Reading source code I think

• stk500v2.c misses usersig code for these classic parts (looks like only the XMEGAs are catered for)
• jtag3 and/or jtagmkII might have code for ATmega*RF(A1|R2)'s usersig

Anyone who wants to program usersig access: the relevant pages are in this datasheet, pages 525-39 and, in particular, pages 538-9:

[MCUdude]

Now that @dl8dtl has confirmed that PR #1406 works as expected, this issue can be closed.
Or should PR #1406 be tested with a jtag3 compatible programmer as well?

[stefanrueger]

@dl8dtl @MCUdude It would be great to test with a HVPP programmer, too. usersig should be accessible only with JTAG and HVPP.

[dl8dtl]

HVPP needs full access to many pins. It's basically incompatible with any device soldered in an UHF-compatible way into a target board. The only way for it would be a ZIF socket adapter, but I don't have one.

[MCUdude]

I won't be able to test HVPP with the board I'll be receiving either, as I won't have access to all the pins.

[dl8dtl]

Well, soldering a simple breakout board might be an option, just to see whether it works at all …

[stefanrueger]

soldering a simple breakout board might be an option

I've just remembered that usersig is only mentioned for XMEGA functions stk600_xprog_...() in stk500v2.c. So I am guessing HVPP is unlikely to work for the ATmega256RF2 et al's usersig memories. If you intended to add relevant code, soldering a breakout board would be fab for testing, indeed.

The other outstanding question is why AtmelICE does not use the offset = 0x100; line from this PR's avrdude.conf usersig memory definition.

[dl8dtl]

So I am guessing HVPP is unlikely to work for the ATmega256RF2 et al's usersig memories.

You're probably right on that. The RF parts added the usersig feature but other comparable AVRs (the core of the ATmega128RFA1 has basically been taken from the ATmega1281) didn't have it. They only have a single read-only signature row, for the device signature, calibration data etc.

I don't think it's worth the effort to spend much time on that. Unless someone would really want to use AVRDUDE for bang programming, I don't see why anyone would ever want to use HVPP. Btw., it's not even HVPP, the RF devices use the TST pin to activate the parallel programming procedure, using normal logic voltage levels. As you might guess it, that one is also used on the wafer- and chip-level testers during production.

[dl8dtl]

To add to this: if someone were really want to use PP on them, it's probably easier to setup a separate programming hardware to do it …

[stefanrueger]

@dl8dtl OK, once we've sorted the AtmelICE issue of ignoring the m->offset, we can close this issue as PP is not planned.