[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Joerg Wunsch]

Follow-up Comment #10, patch #9507 (project avrdude):

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
trouble.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

Follow-up Comment #9, patch #9507 (project avrdude):

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)
___

Additional Item Attachment:

File name: unlock_avr8x_fix.patch Size:10 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

Follow-up Comment #8, patch #9507 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Joerg Wunsch]

Follow-up Comment #7, patch #9507 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

Follow-up Comment #6, patch #9507 (project avrdude):

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
(https://savannah.nongnu.org/patch/?9506) to work. Patch #9506 contains all
the changes to avrdude.conf.in.

(file #42847, file #42848)
___

Additional Item Attachment:

File name: unlock_avr8x.patch Size:11 KB
File name: unlock_test_output.txt Size:2 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Joerg Wunsch]

Follow-up Comment #5, patch #9507 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

Follow-up Comment #4, patch #9507 (project avrdude):

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).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

Follow-up Comment #3, patch #9507 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Joerg Wunsch]

Update of patch #9507 (project avrdude):

  Status:None => In Progress
 Assigned to:None => joerg_wunsch   

___

Follow-up Comment #1:

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

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [patch #9507] Fix UPDI chip erase

[Jan Egil Ruud]

URL:
  

 Summary: Fix UPDI chip erase
 Project: AVR Downloader/UploaDEr
Submitted by: je_ruud
Submitted on: Thu 30 Nov 2017 05:32:48 PM UTC
Category: None
Priority: 6
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

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



___

File Attachments:


---
Date: Thu 30 Nov 2017 05:32:48 PM UTC  Name: fix-updi-chiperase.patch  Size:
5KiB   By: je_ruud



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev