patchAVR Downloader/UploaDEr - Patches: patch #9507, Fix UPDI chip erase


You are not allowed to post comments on this tracker with your current authentication level.

patch #9507: Fix UPDI chip erase

Submitted by:  Jan Egil Ruud <je_ruud>
Submitted on:  Thu 30 Nov 2017 05:32:48 PM UTC  
Category:  None Priority:  6
Status:  In Progress Privacy:  Public
Assigned to:  Joerg Wunsch <joerg_wunsch> Open/Closed:  Open

( Jump to the original submission)

Tue 16 Jan 2018 09:18:24 PM UTC, comment #10: 

Applied in r1417 (with minor modifications).

Flash byte read is used in terminal mode (avrdude -t), and I
can confirm it appears to be broken now.

Unlocking my unresponsive XplainedPro board worked without

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Tue 16 Jan 2018 07:18:32 AM UTC, comment #9: 

So, after sorting some stupid mistakes related to debug HW and misunderstanding of code I myself had made, I finally got it working again.

This fix introduces a new unlock-function, which basically is the jtag3_chip_erase_updi that I have renamed. Unlock is a better name for what it actually do, and I needed the general jtag3_chip_erase function for normal erasing.

Another change I've made is using the jtag3_memaddr() when filling in the address in a EDBG command. This gives a more smooth handling of the memory offsets, and it should work fine for both new and old devices. My only concern is flash byte read due to some changes to addr at jtag3.c:1860 (after this patch is applied), but when is that actually used?

I've also added code so it avoids calling jtag3_edbg_prepare() and jtag3_edbg_signoff() when tool is "xplainedmini_updi". It now works with the buggy mEDBG_UPDI FW.

(file #42921)

Jan Egil Ruud <je_ruud>
Wed 10 Jan 2018 07:09:03 AM UTC, comment #8: 

This is just confusing. My XPlainedPro is also failing now, but with reason 0x1a, which we've never seen before... And it doesn't help to revert back to earlier commits either, still same failure.

Good thing you also remember that it was OK before, otherwise I would seriously start questioning my memory/sanity.

Jan Egil Ruud <je_ruud>
Tue 09 Jan 2018 11:33:02 PM UTC, comment #7: 

Thanks, looks good.  Commited in r1405.

Only thing: after chip erase, my XplainedPro doesn't want to
update its flash anymore:

avrdude: jtag3_paged_write(.., flash, 64, 64)
avrdude: jtag3_paged_write(): block_size at addr 32768 is 64
avrdude: Sending write memory command:
avrdude: jtag3_edbg_send(): sending 77 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 62 (command_sequence == 62)

Raw message:
12  a0  00  ff
[AVR] FAILED, reason: 0xff
avrdude: bad response to write memory command: 0xa0

I think I could successfully write that board before.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Fri 05 Jan 2018 12:53:26 PM UTC, comment #6: 

Here's another attempt on the unlocking, and it should be according to your suggested strategy.

One significant change I had to do was to allow the error code received in jtag3_recv() to trickle all the way up to main.c to be able to identify that the device was locked. Since all return status checks I could find only checked for "<0" I chose to replace some "return -1;" with "return status;", and in jtag3_recv() I return "-(RSP3_FAIL_OCD_LOCKED)".

The attachment unlock_test_output.txt is a "screen shot" of the terminal when trying out the different scenarios.

This patch needs the latest patch in patch #9506 ( to work. Patch #9506 contains all the changes to

(file #42847, file #42848)

Jan Egil Ruud <je_ruud>
Tue 02 Jan 2018 09:32:02 PM UTC, comment #5: 

Thanks for the explanation.

I suggest the following strategy then:

The UPDI-capable devices get their Family_ID added to the config file ("tinyAVR"), so there is something to minimally compare against when the signature is unreadable.

Then, if reading the signature yields an indication an UPDI device is locked, and the user specified -e, we compare the Family_ID to at least minimally ensure we are talking to a valid device.  (Can be overridden with -F, as usual.)  Then proceed to erasing the device (and internally clear the -e flag).  Might be a good idea to try reading the signature again at that point.

If the device was not locked, everything is operated in the usual sequence, no change needed.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Tue 02 Jan 2018 11:03:32 AM UTC, comment #4: 

With the new UPDI AVR's the locking concept has changed. Previously, on old AVR's, when you locked a device you just made the flash unreadable. With the new UPDI AVR's you lock down the whole chip, including the ability to read the signature. There are datasheets that state otherwise, but that is wrong and will be corrected (as soon as possible...).
One of the things you can read from a locked device is the SIB (System Information Block). The first 7 bytes of the SIB is Family_ID, which for all the new UPDI tiny's are 0x74 0x69 0x6e 0x79 0x41 0x56 0x52 => tinyAVR. Not a really good replacement for the current signature verification.
The CMD3_SIGN_ON command will return the first four bytes of the SIB, in this case "tiny".

So, my suggestion is:
We could do a compare on the CMD3_SIGN_ON response, but if you have selected a UPDI device and CMD3_ENTER_PROG_MODE is responded with RSP3_FAIL_OCD_LOCKED, avrdude should continue and check if the user have specified "-e" (chiperase).

Jan Egil Ruud <je_ruud>
Mon 01 Jan 2018 12:40:21 PM UTC, comment #3: 

The "enter prog mode" to read signature failed on a locked device, which meant that you were unable to issue a chip erase to unlock it.
I'll have another go at it and see if I can fix the signature reading.

Jan Egil Ruud <je_ruud>
Sat 30 Dec 2017 12:06:35 AM UTC, comment #2: 

Committed in r1403, except for the changes in main.c (by now,
until discussed).

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Fri 29 Dec 2017 11:51:18 PM UTC, comment #1: 

Why did you put the UPDI chip erase that early in the main()

It's now even before the signature verification, and before
"safemode" (which is probably not very useful on UPDI though).

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Thu 30 Nov 2017 05:32:48 PM UTC, original submission:  

Chip erase on devices with UPDI is done by setting a special parameter before entering prog mode. This patch fixes that.

Jan Egil Ruud <je_ruud>


Attached Files
file #42921:  unlock_avr8x_fix.patch added by je_ruud (10KiB - application/octet-stream)
file #42847:  unlock_avr8x.patch added by je_ruud (12KiB - application/octet-stream - Patch for unlocking AVR8X devices, and an example command line output.)
file #42848:  unlock_test_output.txt added by je_ruud (2KiB - text/plain - Patch for unlocking AVR8X devices, and an example command line output.)
file #42535:  fix-updi-chiperase.patch added by je_ruud (5KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by je_ruud (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-16 je_ruud Attached File- => Added unlock_avr8x_fix.patch, #42921
    2018-01-05 je_ruud Attached File- => Added unlock_avr8x.patch, #42847
        Attached File- => Added unlock_test_output.txt, #42848
    2017-12-29 joerg_wunsch StatusNone => In Progress
        Assigned toNone => joerg_wunsch
    2017-11-30 je_ruud Attached File- => Added fix-updi-chiperase.patch, #42535

    Back to the top

    Powered by Savane 3.6