Re: AVR HV Rescue Shield Support

Topics related to the HV Rescue Shield:
http://mightyohm.com/hvrescue2
matthewbeckler
Posts: 5
Joined: Sun Aug 01, 2010 3:47 pm

Re: AVR HV Rescue Shield Support

Post by matthewbeckler »

Hi Jeff,

Just received my HV rescue shield 2.0 in the mail today, and soldered it up. I haven't bricked any AVRs yet, so I thought I'd try setting the fuses on an attiny13 I had lying around. I used interactive mode, and here is a short snippet of my serial session:

Code: Select all

Select mode:
1: ATmega (28-pin)
2: ATtiny2313
3: ATtiny (8-pin) / HVSP
HVSP
Selected mode: ATtiny/HVSP
Insert target AVR and press button.

Target device fuse values:
LFUSE: FF
HFUSE: FF
Enter desired LFUSE hex value (ie. 0x62): 62
Enter desired HFUSE hex value (ie. 0xDF): FF
Burning fuses...

Read LFUSE: FF
Read HFUSE: FF
Burn complete.

It is now safe to remove the target AVR.

Insert target AVR and press button.
(My attiny13a wasn't originally at FF:FF; it was originally at 62:FF) Before the log above, I had first tried to re-burn the original fuse values (62:FF), but it just appeared to have set them to FF:FF, and subsequently read them back as FF:FF. Any thoughts? This chip was working just fine yesterday, using my tinyisp.

2. While poking through the sketch code, I noticed what might be a bug, or at least a spot of ambiguity, starting at line 293:

Code: Select all

if(mode == HVSP)
    // reset SDO after short delay, longer leads to logic contention because target sets SDO high after entering programming mode
    delayMicroseconds(10);  
    pinMode(SDO, INPUT);    // set to input to avoid logic contention
I'm not sure if you meant to have both the delayMicroseconds and pinMode lines inside the if() block, or if the pinMode line shouldn't have been indented that far. Just a heads-up. (I tried adding braces around both lines, and that didn't help my "always FF:FF" problem above.)

3. In the code there is a commented-out warning to "Ensure target AVR is removed before entering fuse values." Is this still an issue? What if I'm only using 8-pin devices which don't use the DATA bus that uses D0/D1?

Thanks much, I'm excited to get this working with my tiny13.
--Matthew

EDIT: I'm using arduino0021 on Ubuntu 10.4. Tried with both my freeduino and an official Duemilanove. I'm going to try it in an XP vm tonight.
EDIT 2: Same behavior in an XP vm with arduino0021.
Last edited by matthewbeckler on Thu Dec 16, 2010 7:23 pm, edited 1 time in total.
matthewbeckler
Posts: 5
Joined: Sun Aug 01, 2010 3:47 pm

Re: AVR HV Rescue Shield Support

Post by matthewbeckler »

Also, I had trouble compiling when I changed to non-interactive mode by setting #define INTERACTIVE 0. I think the issue is related to the curly brace on line 336 interacting (overlapping?) with the #if (INTERACTIVE == 1) block.

Currently:

Code: Select all

else {
  // ATtiny2313: if I don't strobe OE here, the first fuse read returns 0xFF.
  // I'm not sure why this is necessary!
  //digitalWrite(OE, LOW);
  //delay(1);
  //digitalWrite(OE, HIGH);
  
  #if (INTERACTIVE == 1)
    // Get current fuse settings stored on target device 
    read_lfuse = fuse_read(LFUSE_SEL);
    read_hfuse = fuse_read(HFUSE_SEL);
    #if (BURN_EFUSE == 1)
      read_efuse = fuse_read(EFUSE_SEL);
    #endif
  }
I think this change (adding an #endif above the curly brace, and another #if (INTERACTIVE == 1) before the next section) fixes things properly:

Code: Select all

else {
  // ATtiny2313: if I don't strobe OE here, the first fuse read returns 0xFF.
  // I'm not sure why this is necessary!
  //digitalWrite(OE, LOW);
  //delay(1);
  //digitalWrite(OE, HIGH);
  
  #if (INTERACTIVE == 1)
    // Get current fuse settings stored on target device 
    read_lfuse = fuse_read(LFUSE_SEL);
    read_hfuse = fuse_read(HFUSE_SEL);
    #if (BURN_EFUSE == 1)
      read_efuse = fuse_read(EFUSE_SEL);
    #endif
  #endif
  }
  
  #if (INTERACTIVE == 1)
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

Matthew -

1. You have debug mode enabled in the serial session you posted, right? Otherwise you wouldn't see the 'HVSP' by itself right after option 3.

2. I'll take a look at the code.

3. The comment about removing the AVR is from an old release, around the same time I added the interactive mode. You can ignore it. I'll remove the comment in the next rev.

It appears that HVSP is broken, I just tested a 13A and I am getting FF/FF as well. I'm not sure why this didn't show up in my testing, but I must have broken it right before I released 2.0. Teaches me to optimize code at the last minute. I'll have a fix ready shortly.

I'll see if I can fix non-interactive mode as well, thanks for posting your observations.
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

Ah-ha.

The ATtiny85 works. When I tested the code before releasing it, I tested with the 85 and assumed the 13A was working as well. Something I did in the last couple days before releasing the code must have broken the 13A. I'm working on fixing it now.

Sorry for the broken code. Argh!

Update: Out of the three ATtiny13A's I have on the bench here, two work and one doesn't (gives FF's).

Have you tested any other ATtiny13a's? It seems very unlikely that both of us have one bad IC, but it would be interesting if there is a timing problem that is causing problems on some parts and not others.
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

matthewbeckler wrote: 2. While poking through the sketch code, I noticed what might be a bug, or at least a spot of ambiguity, starting at line 293:

Code: Select all

if(mode == HVSP)
    // reset SDO after short delay, longer leads to logic contention because target sets SDO high after entering programming mode
    delayMicroseconds(10);  
    pinMode(SDO, INPUT);    // set to input to avoid logic contention
I'm not sure if you meant to have both the delayMicroseconds and pinMode lines inside the if() block, or if the pinMode line shouldn't have been indented that far. Just a heads-up. (I tried adding braces around both lines, and that didn't help my "always FF:FF" problem above.)
The pinMode statement can be inside or outside the if statement, because if the programmer is not in HVSP mode, that pin is already an input anyway. That said, it is more correct for it to be included in the if statement, and since it doesn't change the program operation I'll add brackets in the next release.
matthewbeckler
Posts: 5
Joined: Sun Aug 01, 2010 3:47 pm

Re: AVR HV Rescue Shield Support

Post by matthewbeckler »

Jeff, thanks for the update. I only have one dip tiny13, the others are soic on my pcbs, and have too much other stuff on the circuit to work with HVSP.

Yes, I did have debug mode enabled, while trying to figure out what was going wrong. I think I have a tiny24 or 44 lying around that I'll try later today.
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

Ok. It would also be helpful if you could test the shield with an ATmega or Attiny2313 if you have one handy, to help make sure the rest of the shield is working.

Meanwhile, I will try to figure out why one of my ATtiny13A's is not responding.

Thanks for your patience.
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

Ok, I figured out why only one of my parts wasn't working, it's because that was the only part with LFUSE set to 0x62 and not 0x6A (the default).

The issue seems to be related to LFUSE settings that set the startup timer (bits SUT1:0) to 0ms. This includes 0x62 and 0x61. All other fuse values I have checked don't have the issue. If you set LFUSE to anything other than 0x62 and 0x61 with a normal SPI programmer, the Rescue Shield should be able to read and write the fuse values.

I think what is happening is that when VCC is applied to the part by the rescue shield, the part is beginning program execution internally before RESET has a chance to reach 12V and force the part to enter programming mode. I have been able to get HVSP working by enabling reset ahead of time, so that less time is spent with VCC =5V and RESET < 12V.

Other parts show the same issue for some combinations of SUT and internal clock frequency. (eg LFUSE=0x42 causes the same issue on the ATtiny85)

I need to do some more testing before deciding on a fix, but I will keep you posted.

Thanks again for your patience while I debug what is turning out to be a much trickier problem than I expected!
User avatar
mightyohm
Site Admin
Posts: 1064
Joined: Fri Apr 03, 2009 10:29 pm
Location: Seattle, WA
Contact:

Re: AVR HV Rescue Shield Support

Post by mightyohm »

I have attached a scope capture that shows the situation with the ATtiny13A.
Yellow=RESET
Green=Vcc (highly expanded scale)
Blue=SDO (serial data out from the target)
Magenta=SCI (ignore for now)

The issue seems to be the fairly lazy way that RESET makes its way from 0 to 12V. For whatever reason, the slow rising edge of RESET, coupled with the zero startup timer fuse setting (LFUSE=0x62) is causing the 13A to either never properly enter or drop out of HVSP mode by the time I am able to read fuses.

Interesting, this issue affects more than just LFUSE=0x62 on the 13A, and it affects more than the 13A as well. Every part I have tested (ATtiny85, 13A, 2313, ATmega168) experiences the same issue if the fuses are configured for a (14CK + 0ms) startup timer and a fast (greater than 128KHz at least) internal clock. On the 13A, LFUSE=0x61 and 0x62 seem to cause the problem, other fuses I have tested don't.

This is a problem.

I have always known that the DC-DC converter ramps up fairly slowly, and until now this has never been an issue. Risetime is a tradeoff with ripple on the 12V supply, and since I had never seen an issue, I designed the supply for minimum ripple and what I considered to be a "reasonable" risetime, since having a fast edge didn't seem to matter. In fact, Atmel doesn't spec a risetime or any other timing requirements on RESET that I can find in any of the datasheets I have looked at. I have submitted a support request to see if they will give me a recommendation or spec on what the risetime is supposed to be.

Based on my testing this week, I can safely say that all Rescue Shields that I have made to date, including both version 1 and 2, suffer from this issue, and apparently after almost 2 years you are the lucky one to uncover it. :D

So what do we do now?

The options at this point seem to be:

1. Modify the VCC/RESET sequencing in the Arduino sketch so that when VCC goes high, RESET is already somewhere in the middle of it's rise to 12V. This is definitely a hack, but it seems to work for the ATtiny13A at least. I have not tried it on any of the other parts.

2. Rework DC-DC converter design to "speed it up" at the expense of ripple in the output voltage. There are a couple ways to do this, both with and without changing the layout of the PCB. Unfortunately, the ways that require PCB changes seem to give better results. :(

3. Keep existing DC-DC and add a passgate or switch external to the DC-DC that would switch the RESET signal very quickly. This will give the fastest edge but would definitely require a PCB respin.

While I'm waiting to hear back from Atmel I am continuing to test various solutions and workarounds. I'll keep you posted with my progress. I'm away from the lab over the next week, so what I don't finish by tomorrow evening will have to wait until I get back on 12/30.

You can test solution 1 yourself pretty easily by changing this part of the code:

Code: Select all

  // Enter programming mode
  digitalWrite(VCC, HIGH);  // Apply VCC to start programming process
  delayMicroseconds(100);
  digitalWrite(RST, HIGH);   // Apply 12V to !RESET thru level shifter
to this:

Code: Select all

 // Enter programming mode
  digitalWrite(RST, HIGH);  // Apply 12V to !RESET thru level shifter
  delayMicroseconds(60);  // May need to play with this value to get consistent results
  digitalWrite(VCC, HIGH);   // Apply VCC to start programming process
Attachments
NewFile6.png
NewFile6.png (4.6 KiB) Viewed 40720 times
matthewbeckler
Posts: 5
Joined: Sun Aug 01, 2010 3:47 pm

Re: AVR HV Rescue Shield Support

Post by matthewbeckler »

I'm very impressed by the investigation you've done into this issue. Glad that I'm the 'lucky' one to uncover the weird behavior. :- )

Thanks for the temporary, "hacky" fix, I'll give it a shot tonight and post my results. Don't worry about spending time over the holiday, we've all got holiday plans, most not involving microcontrollers :- )

--UPDATE--
The three line code change successfully got my shield up and running, successfully rescuing my attiny13 chips. Thanks much!
Post Reply