AVR128DB28 "Locked.." a bug, BDU Error, or bad batch of chips? #412
Replies: 2 comments 7 replies
-
|
The locked chip issue was fixed last Thanksgiving. It should automatically
fire a chip erase
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Sun, Mar 5, 2023, 17:37 Peter Nichols ***@***.***> wrote:
I "Burned Bootloader" in 1.5.4 for Optiboot. Everything was fine, then
went over to the Serial port to upload my code, and nothing. "Oh....I
probably didn't change it from PA4/5 to PA0/1, no problem....re-burn it."
Error:
Failed to enter NVM programming mode
The device is in a locked state and is not accessible; a chip erase is required.
Locked AVR UPDI devices can:
- be unlocked using command: erase --chip-erase-locked-device
- write user row values using command: write --user-row-locked-device
Ok...finding that while adding unlocks to prog.py was in the queue (due
last Turkeyday if memory serves), sounds like it's not there yet. Soooo....
% pymcuprog ping -t uart -u /dev/cu.usbserial-AL0122RA -d avr32da28
Connecting to SerialUPDI
The device is in a locked state and is not accessible; a chip erase is required.
Locked AVR UPDI devices can:
- be unlocked using command: erase --chip-erase-locked-device
- write user row values using command: write -m user_row --user-row-locked-device
% pymcuprog erase -t uart -u /dev/cu.usbserial-AL0122RA -d avr32da28 --chip-erase-locked-device
Connecting to SerialUPDI
Pinging device...
pymcuprog.pymcuprog_main - ERROR - Error with st_ptr
Still no dice...and no idea if it's pymcuprog, my board (doubtful, 2nd
board, and components to the working one are identical) or the new batch of
AVR128DB28's. Other likely extraneous facts: I noticed that my FTDI was set
to 3.3V and I have since tried this in 1.5.5....already replaced with
another AVR128DB28 from the same batch, which I will drop on one of my
breakout boards.
Suggestions?
—
Reply to this email directly, view it on GitHub
<#412>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW5GORXXCO7VR3RMH23W2UISBANCNFSM6AAAAAAVQNUZNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That sure makes sense, except it’s not (firing a chip erase). I guess I’ll pull a chip I know works from a breakout board onto this board. There’s no sending these back to Digikey, so I’ll try reaching out to Microchip. |
Beta Was this translation helpful? Give feedback.
-
|
Update: Put a known working chip from a board that worked, still get "Locked". When I find out what's causing that, I'll post here. I've also moved that "Locked" chip that was on that board onto a board I know works. Will post that also... really weird...makes me think it's my environment, but while I tried the pymcuprog on an RPi, I didn't try programming it via the Arduino IDE. |
Beta Was this translation helpful? Give feedback.
-
|
Update: Checked that circuit is on the board is correct...the "original" circuit was a 1N4148 and a 5K resistor. I changed out the 1N4148 for a BAT43 and removed the resistor. No dice, still locked....not really surprised, as comms seem fine. The stumper is that in moving the "original" chip to another board, that chip works fine...no problem with it. I'll dig through the pymcuprog code to see if can get it to tell me exactly what's going on. |
Beta Was this translation helpful? Give feedback.
-
|
....and the winner is... Shorted cap across the reset line (stuck in reset mode). I'm thinking this is pymcuprog not DxCore that should be trapping for this. So is this a bug, feature request, BDU Error? Would have been really nice to have a "RESET not released", because pymcuprog did attempt to do that, and should have failed right there. Instead I got a squirrel to chase. |
Beta Was this translation helpful? Give feedback.
-
|
The version of pymcuprog that we include is absolutely not the stock version. The stock version doesn't even beat 1k/s with most serial adapters. it's unspeakably slow The version we include has been very aggressively optimized for performance, down to doing some really horrifying things, like sending all the commands that get sent for a given page, from the setting of the Response Signature Disable bit prior to a write, and when we turn that off after each page to make sure we haven't lost the plot somewhere along the way, as a single giant wad of text. (RSD is responsible for the lion's share (a very slow moving lion... I'm picturing something with the upper body of a lion and the lower body of a slug or snail....) of the slowness of pymcuprog, so we can't leave it on - it would make the computer wait for a 1 byte reply after every 2 bytes it sent. But the minimum time that that can take is around 1-2ms (depending on serial adapter) due to USB latency. So writing 1 page would have 256-512 ms of latency time, compared with (at 345600 baud, the maximum we support on Dx, the 512 bytes themselves take less than 20ms to transmit. You don't even notice the guard time between sending the word and receiving the response even though it's set to the maximum: that only takes about 5x as long as the data, so it just vanishes into the USB latency black hole). We can no longer merge the official pymcuprog code into SerialUPDI :-( But that's okay - just because Microchip swore on their mothers grave that they would keep the code up to date, doesn't mean jack shit. I know during that optimization push, we had the DA/DB 128's, but not the smaller DA/DBs. So like a year after the 64DB's came out, someone reported that the core couldn't program them, it didn't recognize the chip name. Okay, well let's just grab the latest version of pymcuprog and get the device definitions from it, right? Oh, huh, they don't seem to be here, I guess I'll synthesize them from the other device definitions. Falling for that old trick was one of the most pathetic blunders I've made in recent memory; I mean, you've just been looking through the pymcuprog code right? What do you think of that code? But anyway - yes, wouldn't it be nice if there was a way to do that? But I'm not sure the responses it gets are distinct from the responses it would get from a locked chip. Maybe they are, maybe not. This is the situation almost all programming tools end up in when they can't get any sort of intelligible response from the device... All they can do is shrug their shoulders and be like "I dunno, something's wrong" - the protocol says it's supposed to send X in response. but I get nothing back. Maybe it's not connected. Maybe it's wired incorrectly. Maybe someone ran the circuit board through a bandsaw and threw away the part with the microcontroller on it. Maybe someone soaked it in lighter fluid and set fire to it Maybe the wrong port was selected. It all looks the same. It's like a failure to upload to a device using a serial bootloader - if you have no communication, you have no communication. That's why every failed upload through optiboot gives the same f'ing useless error. Errors in programming an mcu are very hard to correctly detect. I realize that our error messages are worse than they need to be (I've tried to get help on this from quentin. but no luck and I don't have the skill to fix that) And while there are ways that this specific case can be trapped (since you can run a modem control input to reset, Most of them would require running extra dedicated wires, if that would even work? (and often times it wouldn't) But adding another wire would increase and not decrease the liklihood of failure - you'd just have more problems because there would be 4/3rds as many wires to connect wrong, so it's at least 33% more likely that you'll make a wiring mistake Programming tools either successfully start writing the flash, or they don't. Once you've started to write the flash, you've got tons of debugging information from the transition from writing to failing-to-write, but that 's a vanishingly rare situation: 99% of the time, you have no communication whatsoever - or you succeed at the write in it's entirety. I mean, think of the old classic AVR days. Those had purpose made programmers, but it was only barely better; jtag2updi is worse. You've only got one data line. How it is supposed to work out why it can't see a response. I was surprised when I discovered that holding down reset would break programming on modern AVRs though. |
Beta Was this translation helpful? Give feedback.
-
|
Wow…ok…calling this answered. A good note though to other folks to learn from my mistake…make sure reset works as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Did you look at that code like you said you were going to? You don't get away with shirking! I expect you to read at least 2 Advils of that code. (advil - a unit of code equal to the amount sufficient to produce a headache that could be treated effectively with the stated number of Advil or equivalent generics. 2 Advils of that code won't take you very long! |
Beta Was this translation helpful? Give feedback.
-
|
That's on my homework list!! I've been beating on the Blinkenlights board....and finally got Burcom CP/M to run. |
Beta Was this translation helpful? Give feedback.
-
I "Burned Bootloader" in 1.5.4 for Optiboot. Everything was fine, then went over to the Serial port to upload my code, and nothing. "Oh....I probably didn't change it from PA4/5 to PA0/1, no problem....re-burn it."
Ok...finding that while adding unlocks to prog.py was in the queue (due last Turkeyday if memory serves), sounds like it's not there yet. Soooo....
Still no dice...and no idea if it's pymcuprog, my board (doubtful, 2nd board, and components to the working one are identical) or the new batch of AVR128DB28's. Other likely extraneous facts:
Suggestions?
Beta Was this translation helpful? Give feedback.
All reactions