-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AVRDUDE not erasing locked UPDI device #1124
Comments
Looks like Reference comment from: |
Thanks for reporting @avrfreak! I'm able to reproduce the issue, and it seems to be a problem on all UPDI parts, since, unlike classic AVRs, they don't reveal their device signature when locked. As a temporary solution, you can add the -F flag to force erasing even though Avrdude.
|
However, there is a pattern here we can look for to determine that we're dealing with a locked chip. This would be the logic we'll ve to implement:
(Note that this can only be applied for chips with UPDI. The Arduino as ISP programmer has a "bug" that results in an |
The SerialUPDI programmer has a slightly different output and forcing the erase command doesn't work at all for JTAG2UPDI. SerialUPDI output
JTAG2UPDI output
|
When reading the ASI System Status register of a locked UPDI mcu, the response will be 0x83 (Lockstatus = 1). I believe the erase method & key is the same for all UPDI chips. I checked into this a few months back when I was getting sick and tired of having to erase the device with Studio7 every time. All that needs to be done is to send the erase key, and then a reset instruction. I did this on an ATtiny2313. It just erases and nothing else. I wouldn't know how to modify & compile avrdude. |
Sounds reasonable. However, when looking at the ASI System Status register, it's not obvious to me why it would return 0x83 when locked. We should probably check the least significant bit instead since this is the bit that indicates if the part is locked or not. |
I've taken a closer look at the root cause. The main problem is that the function Lines 1186 to 1232 in e14e5d2
|
OK, I totally fell down the rabbit hole. I'll submit a PR, and then we can discuss the solution I've come up with |
Yes you are right to just check bit 0. I just did a quick erase program to fill my needs. I found that every device I tested either returns 0x82 (10000010) or 0x83 (10000011). Strange how only bit 1 & bit 7 read as 1 while the other reserved (bit 6) reads 0. I think if the lockstatus bit = 1, and the -e option is enabled, avrdude should just erase the chip. (not sure if this was already mentioned in the next thread. I will go over there now and have a look) Thanks MCUdude |
Oops, I did not read this properly. Now I need to learn how to use Microchip SNAP with this Nano 4808 board.
|
@MCUdude Connection as per the pinout from your MegaCoreX and SNAP user guide (Section 10.3.2, DS50002787C-page 38 ) SNAP Pin -- Nano 4808 Pin
Edit to add: I will try out the modification mentioned here (remove pull-down R48 and add external pull-up resistor to the SNAP). I have another Nano 4808 so I can test whether the connection is good there or not. |
what is the fix another avrdude version? |
Works with my (modified) SNAP:
|
With PR #1125, you can get the binary from github action. For example, 32bit mingw build here. |
does not work at all.
the same programmer works with the previous version but won't program a locked chip. |
@avrfreak the programmer issue is not related to this PR. But if you look at the Avrdude output, you can see that you've set the UPDI clock to 5000kHz. That won't work fore sure! Try using |
BTW, the Right now the codes look through different USB PIDs and for sure will print out this error message. We should only print out this as an error message when all three USB PIDs are not found. |
Once I modify the SNAP as per Microchip ETN36, yes I can confirm the temp workaround works (
|
And PR #1125 fixed the issue. Tested with SNAP.
|
ElTangas/jtag2updi#66 (comment)
Indeed the trick by the author of jtag2updi works. I was hoping no need to rebuild with
|
For jtag2updi, PR #1125 does not help but it does not make things worse either, it is the same as git main.
|
I am using avrdude with a Microchip Snap Debugger as a UPDI programmer only (no debugging).
Everything works really well with the SNAP programmer with only one exception:
If you program the lock bits, you can no longer access the target device using avrdude.
The same thing happens when using jtag2updi as the programmer. This is avrdude related and not a hardware issue.
Here is the error log:
The text was updated successfully, but these errors were encountered: