Closed dduehren closed 3 years ago
Its been awhile since I've used any HV programmer and I see megaTiny core is now at v2.3.2. Anyways, no matter what HV programming circuit or board you're using or how the 1604 became bricked, here's some tips to bring it back:
Preparation:
HV Programming
Here's the latest test results I had using a Nano HV UPDI Programmer with Attiny412 target:
Arduino 1.8.13
megaTinyCore 2.1.5 via Boards Manager
Chip Settings: Clock 20MHz, default timer, Support serial event: No, BOD 1.8V, BOD Mode: Disabled, EEPROM Retained, SUT 8ms
ATtiny412F on SOIC-8 to DIP-8 adapter
Programmer UPDI connected directly to target UPDI pin (PA0)
Success 1: Success or Fail toggles, may require 2 programming attempts
Fail: ...bad response to leave progmode command: RSP_NO_TARGET_POWER
Workaround: Use 5V power pin or switch jumper to HV mode (may require 2 programming attempts)
Thanks for the reply. Here is my setup.
The HV programmer is the one that you sell, though I built it myself. I have tried it in both the HV and PHV modes without success. I used it the way it’s pictured with power, gnd and the hvupdi signals going to the target. No other power source was used. The 1604 has a bypass cap. There are other circuits on the target board. There are no additional series resistors on PA0 (updi).
When it didn’t do anything, I was concerned that I hadn’t built it properly. I have a USB scope from BitScope but it doesn’t show accurate voltage levels, or I haven’t figured it out. So while I saw a pulse, I couldn’t tell if it were 12 Volts.
That prompted me to build a hybrid with your design and the DIY HV UPDI programmer. Instead of the LCt1262CN8, I used a 12V external supply, and I used a different opto-isolator/switch because I had these things around. I tested the opto circuit statically to set the series resistor driven by D12 so that 35ma was driven to a resistive load. I connected directly to the UPDI line at the header. Looking at the circuit for your design, I figured it wouldn’t hurt. In any case, when I got that circuit working, I tried again with the same result as in #1 above.
As for your other points. I am using a DC powered USB hub for the USB to the Nano. I have tried both HV and PHV modes. I am sure the software is working because I see the blue flash and I have used the D12 signal to trigger my scope. The 12V signal does fall quickly when the pulse ends. I know there’s internal resistance to your programmer and the board has other 5V loads. I have tried both embedded devices and stand-alone devices and have gotten similar results.
I have also successfully programmed the ATtiny 1604 in the embedded setting using jtagupdi without HV. I bricked the device because I had the wrong part selected 1614, not 1604. Seems like the programmer should do better than that.
What does the bootloader have to do with this? I shouldn’t need the bootloader for an embedded part. I prototyped the code on an uno, and once working, just retarget the pins and download.
Is being bricked by setting the wrong target something that can be fixed with HV programming, or does that do some other kind of damage?
From: Dlloydev @.> Sent: Saturday, June 5, 2021 8:49 AM To: Dlloydev/jtag2updi @.> Cc: David Duehren @.>; Author @.> Subject: Re: [Dlloydev/jtag2updi] Probable bug (#17)
Its been awhile since I've used any HV programmer and I see megaTiny core is now at v2.3.2. Anyways, no matter what HV programming circuit or board you're using or how the 1604 became bricked, here's some tips to bring it back:
Preparation:
HV Programming
Here's the latest test results I had using a Nano HV UPDI Programmer with Attiny412 target:
Operational Test Results
Programmer Mode
UPDI Pin Mode
Optiboot Option
Target Power
Upload Using Programmer
Burn Bootloader
UPDI
UPDI
No
T5V
Success
Success
5V
Success
Success
Yes
T5V
Success
Success
5V
Success
Success
HV
Reset
No
T5V
Success 1
Success 1
5V
Success 1
Success 1
Yes
T5V
Success
Success
5V
Success
Success
PCHV
GPIO
No
T5V
Fail
Fail
5V
Success 1
Success 1
Yes
T5V
Success
Success
5V
Success
Success
Success 1: Success or Fail toggles, may require 2 programming attempts
Fail: ...bad response to leave progmode command: RSP_NO_TARGET_POWER Workaround: Use 5V power pin or switch jumper to HV mode (may require 2 programming attempts)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dlloydev/jtag2updi/issues/17#issuecomment-855258112 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAY6Z6MPABHTDIXEOOB753TRJBNHANCNFSM46D5RZLA . https://github.com/notifications/beacon/ACAY6Z46EOOLOXISQ4BE5S3TRJBNHA5CNFSM46D5RZLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGL5DIAA.gif
Thanks for your detailed reply.
Overall, your preparation and connections are described OK, however I'm concerned with the UPDI circuit you're using. The UPDI signal at the target is quite sensitive to timing, delays, voltage levels and the programmer's ability to quickly switch off the signal to high impedance mode.
If you're working a lot of IC's, it would be good to have access to a Power Debugger. I know this is very costly, but it works incredibly well and if it can't unbrick an IC, there's no recovery to be had. Note that with this debugger, the signals are quite strong and buffered. The HV pulse is ultra fast and sharp (far beyond their published recommendation of 100µs min width as its only 30µs) and it is directly multiplexed onto the target UPDI signal.
I've tested this fast multiplexed approach on my UPDI-Key design and it achieves similar results. Unfortunately, I don't have the appropriate equipment and time to produce some of these, but its fully open source, so maybe someone will give it a try.
Thanks, I will try with D12 instead of D21. The opto I have is a FOD814 which I think has comparable performance to the TLP185.
My biggest problem is accurately measuring the amplitude of the pulse with my Bitscope device.
Who makes a power debugger?
David
Sent from my iPhone
David Duehren
On Jun 9, 2021, at 7:03 AM, Dlloydev @.***> wrote:
Thanks for your detailed reply.
Overall, your preparation and connections are described OK, however I'm concerned with the UPDI circuit you're using. The UPDI signal at the target is quite sensitive to timing, delays, voltage levels and the programmer's ability to quickly switch off the signal to high impedance mode.
The HV voltage level should be within 11.5-12.5V If using an opto-isolator, it needs to be fast acting and the opto emitter's output should be directly connected to target UPDI. Use D12 on the Nano instead of the signal at the header. The header signal has components in between intended for the internal charge pump which will interfere with the required opto led signal.
If you're working a lot of IC's, it would be good to have access to a Power Debugger. I know this is very costly, but it works incredibly well and if it can't unbrick an IC, there's no recovery to be had. Note that with this debugger, the signals are quite strong and buffered. The HV pulse is ultra fast and sharp (far beyond their published recommendation of 100µs min width as its only 30µs) and it is directly multiplexed onto the target UPDI signal.
I've tested this fast multiplexed approach on my UPDI-Key design and it achieves similar results. Unfortunately, I don't have the appropriate equipment and time to produce some of these, but its fully open source, so maybe someone will give it a try.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
If you're using an external 12V power supply (and if its regulated) the voltage should be OK. However, unregulated 12V DC adapter might output 16V at no load which is far too high. I would check the supply voltage with a multi-meter. The voltage loss through the opto-transistor would be quite small, probably around 0.2V drop when switched on. Power Debugger
I’ve already measured it at 12v. The only reason it could be lower, as I observed, is if the current requirement is more than 35ma, because the resistor controlling the current into the emitting diode sets that.
Sent from my iPhone
David Duehren
On Jun 9, 2021, at 9:14 PM, Dlloydev @.***> wrote:
If you're using an external 12V power supply (and if its regulated) the voltage should be OK. However, unregulated 12V DC adapter might output 16V at no load which is far too high. I would check the supply voltage with a multi-meter. The voltage loss through the opto-transistor would be quite small, probably around 0.2V drop when switched on.
Power Debugger
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I have not worked on the HV programmer since last email. I’m wondering about the behavior of jtag2updi.
I had successfully programmed a ATtiny 1604 and it’s been running just fine over the last week. Tonight I tried to download an update to the code that was running. But jtag2updi / aversive retuned the infamous RSP_ILLEGAL_MCU_STATE message. The part isn’t really bricked because it is still running the old code.
Does it just get confused, and there’s nothing really wrong with the part(s)?
And does the serial adapter version behave differently? This is an extraordinarily frustrating experience with these parts. Maybe I should buy a real programmer and forget this DIY stuff which is so problematic. Any model you’d recommend?
Sent from my iPhone
David Duehren
Hi,
This is the setup that I have been using. I have been using D12, albeit with a smaller resistor value that I found experimentally to get me to 35ma with the opto I’m using.
I’m interfacing to the HVUPDI signal on your HV programmer and assuming that the normal UPDI signal is coming through. I haven’t verified that, but I don’t think my soldering is that bad.
From: Dlloydev @.> Sent: Wednesday, June 9, 2021 7:04 AM To: Dlloydev/jtag2updi @.> Cc: David Duehren @.>; Author @.> Subject: Re: [Dlloydev/jtag2updi] Probable bug (#17)
Thanks for your detailed reply.
Overall, your preparation and connections are described OK, however I'm concerned with the UPDI circuit you're using. The UPDI signal at the target is quite sensitive to timing, delays, voltage levels and the programmer's ability to quickly switch off the signal to high impedance mode.
If using an opto-isolator, it needs to be fast acting and the opto emitter's output should be directly connected to target UPDI. Use D12 on the Nano instead of the signal at the header. The header signal has components in between intended for the internal charge pump which will interfere with the required opto led signal.
If you're working a lot of IC's, it would be good to have access to a Power Debugger. I know this is very costly, but it works incredibly well and if it can't unbrick an IC, there's no recovery to be had. Note that with this debugger, the signals are quite strong and buffered. The HV pulse is ultra fast and sharp (far beyond their published recommendation of 100µs min width as its only 30µs) and it is directly multiplexed onto the target UPDI signal.
I've tested this fast multiplexed approach on my UPDI-Key design and it achieves similar results. Unfortunately, I don't have the appropriate equipment and time to produce some of these, but its fully open source, so maybe someone will give it a try.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dlloydev/jtag2updi/issues/17#issuecomment-857722261 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAY6Z3YYWK74WHBFSAU3A3TR5YEZANCNFSM46D5RZLA . https://github.com/notifications/beacon/ACAY6Z6GRBT5ZM327NCOC2TTR5YEZA5CNFSM46D5RZLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGMP43FI.gif
Hi,
Please disregard previous email about illegal mcu state. The good part was able to be reprogrammed. Somehow I managed to disconnect VCC.
It's getting late.
Sorry to bother you.
David
No problem, glad you got it working.
I have some bricked ATtiny 1604s that I have been trying to unbrick using your HV/PHV programmer with JTAG2UPDI. I am not sure how some of these devices got bricked in the first place, They were programmed in normal UPDI mode, and then became bricked over time. My programming success improved once I made a nano based dedicated programmer. That programmer bricked at device because I had selected 1614 instead of 1604, even though the programmer detected the mismatch in IDs.
Now I am observing the following behavior, using the latest version of the code (which BTW seems to have fixed ...sign-on command: status -1 problems)
Any thoughts on what could cause this result. Could it explain why the device was bricked in the first place by selecting the wrong chip?