search

Dlloydev / jtag2updi

HV UPDI / UPDI programmer software for Arduino (targets Tiny AVR-0/1/2, Mega AVR-0 and AVR-DA/DB MCUs)
MIT License
27 stars 8 forks source link

Probable bug #17

Closed dduehren closed 3 years ago

dduehren commented 3 years ago

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)

  1. On most devices, when power is attached, it still reports RSP_ILLEGAL_MCU_STATE as expected.
  2. In an board where the ATtiny is embedded, and where it was initially programmed (with the wrong ID), the behavior is the opposite. In Mode: PHV or HV. Power connected to device, but report is RSP_NO_TARGET_POWER. If I remove power, I get RSP_ILLEGAL_MCU_STATE.

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?

Dlloydev commented 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:

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)

dduehren commented 3 years ago

Thanks for the reply. Here is my setup.

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

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

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

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

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

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

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

Dlloydev commented 3 years ago

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.

image

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.

dduehren commented 3 years ago

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.

Dlloydev commented 3 years ago

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

dduehren commented 3 years ago

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.

dduehren commented 3 years ago

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

dduehren commented 3 years ago

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

dduehren commented 3 years ago

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

Dlloydev commented 3 years ago

No problem, glad you got it working.