High Voltage Programming Protocol Question

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greets!

 

I am working up a project that has a built in ATTiny fuse reset function, and have a question on the HVSP as per Atmel's information...

 

 

  1. Set Prog_enable pins (SDI, SII, SDO, SCI) “0”, RESET pin and VCC to 0V.

  2. Apply 5V between VCC and GND. Ensure that VCC reaches at least 1.8V within the next 20 microseconds.

  3. Wait 20 - 60 us, and apply 11.5 - 12.5V to RESET.

  4. Keep the Prog_enable pins unchanged for at least 10 us after the High-voltage has been
  applied to ensure the Prog_enable Signature has been latched.

  5. Release the Prog_enable[2] (SDO pin) to avoid drive contention on the Prog_enable[2]/SDO pin.

  6. Wait at least 300 us before giving any serial instructions on SDI/SII.

  7. Exit Programming mode by power the device down or by bringing RESET pin to 0V.

 

 

The question regarding the above basic information is...

 

If the ATTiny is already powered up, can I jump right to step 3, or does the 20-50 microsecond delay between power up and the application of 12v count?

I am assuming that I can jump right to step 3, which is optimal for my application.

 

Perhaps someone has tried this and has a real answer?

It will be a few days before I can test this and report back.

 

Thanks,

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brad,

 

I have never looked at it, but from ARM experience I would suggest and think you will need to do all the steps.

step 1 might be for setting up all the special pins to be tested by the internal programming block to see if it needs to go to either just serial programming or highvoltage programming.

step 2 is just to make sure that the programming block does not latch-up and thus corrupt itself.

then step3 is actually activating the chip and providing the voltage needed to do the high voltage programming.

 

but for you as usual ;)  you just could try it on a chip and see what happens.

be careful with the 12V though if it 'spreads' towards the rest of your big breadboard then you can probably replace all the logic chips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an HVSP programming shield (of my own design) which fits on an UNO.  I use it to program 8-pin tinies.  I use HVSP only to reset fuses, and then use ISP for normal programming.  I don't know off hand whether it skips any steps (wrote the firmware long ago), but I'll poke at the firmware and run some tests.  Won't be till at least later today (after work).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried a couple of different variations of entering HVSP mode with the target already powered (with or without pulling /RESET low first, with or without pulling the Prog_enable[2:0] pins low first).  None of them work.  Looks like you need to start from step 1.  Sorry :(

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

I tried a couple of different variations of entering HVSP mode with the target already powered (with or without pulling /RESET low first, with or without pulling the Prog_enable[2:0] pins low first).  None of them work.  Looks like you need to start from step 1.  Sorry :(

 

Thanks.

I almost called you on it though!

 

Made a simple resetter in assembly and verified its operation. I then tried resetting with VCC already connected and not controlled by the program.

The first 4 resets I did actually worked! Seems it's hit and miss with uncontrolled VCC. I can do a reset maybe 25% of the time. Oh well!

 

No big deal, my plan will still work.

The one "doh" issue though is that they left B.4 not connected instead of B.3 for HV programming!

Like dude... why? With a clock input on B.3, now I have to switch the damn thing!

 

Yeah, I am making a "Backpack" for my AVRISP that does a quick fuse reset before programming.

Need to use every last byte in the ATiny85, as well as all 5 available IO for output.

Call it ICHVSPM... In Circuit High Voltage Serial Programming Mod.

 

Thanks to using B.3 rather than B.4, I now have to include a 74HC4066 analog switch in my ICHVSPM!

Ok, no more complaining, and back to making it work.

 

Brad

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I had some time to mess around on my project and so far it is working perfectly.

 

I wrote a pure assembly program for Atmega88 setup to reset fuses on an ATiny.

For the 12 volt source, I used a Dickson style Charge Pump using only 3 diodes, 3 caps. (no transistor).

Built the charge pump to only require .1uf caps as these are easy to source (decoupling caps).

The pump driver uses 2 PWM pins set as anti-phase, with a frequency "tuned" to the .1uf caps.

I also control the charge pump source wit an IO pin, so the entire IO can go invisible to the target.

 

The end goal for this project is a "wedge" that goes between the AVRISP and the ATiny.

When the AVRISP tries to program a locked ATiny, my wedge quickly resets the fuse before Studio times out.

I have not tested my theory of a "man in the middle" attack as of yet, but assume it will work.

Some crude tests show that you can yank VCC off the target for a second and Studio will keep trying.

As long as my HV Resetter can get in there and do it's magic quickly, it should work fine.

After my Resetter does its thing, it completely releases all pins and goes invisible.

 

The end result... You can free up that reset pin on an ATiny and use only AVRStudio and an AVRisp.

 

Now the only part I am missing is a good document explaining the actual AVR HV Protocol.

I don't want to ONLY reset the fuses, as this leaves the internal 8MHz OSC set by default.

I want to change the fuses so they are set to : External OSC and no clock divide.

 

Does anyone know where I might find a DOC showing the full details of the AVR HV Protocol?

 

Also, if there is any interest in a pure assembly fuse resetter, I will post this project here.

 

Cheers!

Brad

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Tue. Jun 28, 2016 - 03:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
Does anyone know where I might find a DOC showing the full details of the AVR HV Protocol?

Hmmm--Indirectly, you did mention Tiny85 so at this point you are specifically targeting that model/family?

 

Are all Tiny AVRs [excluding brain-dead] created equal as far as HVSP is concerned?

 

I'm not an HV guru, but perhaps another model's datasheet has more info if identical or nearly so?

 

I deal mostly with Mega devices and am used to seeing Parallel Programming Parameters, Pin Mapping, and Commands
and Parallel Programming
(which has algorithm description).  I'd have expected similar in Tiny datasheets.  And in the Tiny24A datasheet I have open I find

19.7.8 Programming and Reading the Fuse and Lock Bits
The algorithms for programming and reading the Fuse Low/High bits and Lock bits are shown in
Table 19-16 on page 170

 

Same in Tiny85 datasheet:

...

I looks pretty complete to me--but I've never messed with it.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi brad,

 

you are talking about a 'locked' processor.

with locked do you mean locked in the way that the fuses have been programmed wrong and you need to recover from that, or locked as in the lock bits are set but you need to reprogram.

the first can be done as you describe and sounds logical.

teh second should be fixed by performing a full chip erase and thus should not need HVSP

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't want to ONLY reset the fuses, as this leaves the internal 8MHz OSC set by default.

I want to change the fuses so they are set to : External OSC and no clock divide.

It would be the same procedure regardless.  Fuses are explicitly set in HVSP mode, just as they are in ISP mode.  There is no 'restore-to-default-fuses' command.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you are talking about a 'locked' processor.

No they're not.  They're talking about a chip that was intentionally programmed to use the RESET pin as a GPIO.  A bunch of chips allow this, and the only way to reprogram them is with HVSP.

You can do it the easy way, and only re-enable reset with HVSP and then do the rest "normally", or you can do everything via HVSP.

(I always figured that ISP consists approximately of sending SPI commands while RESET is active (0V normally), and I don't understand why HVSP doesn't just use the same commands with "HV" on RESET replacing "0V" as the way for RESET to be "active", but ... they didn't let me design the chips!)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I don't understand why HVSP doesn't just use the same commands with "HV" on RESET replacing "0V"

Bill, you'd better patent that before you lose the rights! wink

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe I have sorted it out.

When I wrote my ASM fuse resetter, I used some of the other examples to get the Data,Instuction sequence.

I just figured this sequence told the ATTiny to go back to factory defaults.

From what I am being told, these are the actual fuse settings, so I just need to find the DOC file to explain them all.

 

To further explain what weirdness I am doing here...

 

I have an ATTiny project that requires every single IO pin and every last byte of program memory.

Obviously, gaining back PINB.5 requires setting the fuses to disable reset, which also disables the ability to program the part using AVRStudio and an AVRisp.

 

To get around this, some have made simple "Fuse Resetter" program that require pulling the ATTiny, putting it on another breadboard, running a reset program, then putting it back on the original breadboard with the fuses set to the default internal 8MHz osc with clock divide enabled.

 

To me, this limitation and lengthy kludge is not acceptable.

 

What I did is study a few of these resetters, and rewrote one in pure assembly that works as fast as possible. I also took inspiration from Wayne Holder's excellent resetter project shown here that uses a Dickson Charge Pump to generate the 12 volts required for HVSP...

 

https://sites.google.com/site/wa...

 

I simplified the Charge Pump idea down to only 3 diodes, and 3 decoupling caps (.1uf), and it does not require a transistor.

I also wrote my resetter to tristate all pins so that it can become "invisible" to the target.

 

My final evil plan is to have my resetter perform a "Main in The Middle" attack on my AVRISP so that it will hijack the programming bus just as Studio initiates an ISP to the AVRISP. Becasue the AVRISP does take a few seconds to realize that the ATTiny is locked, I believe that within this time, I can quickly set the fuses back to the desired settings, which for this project would be...

 

RSTDISBL : Disabled
SPIEN : Enabled
CKDIV8 : Disabled
SUT_CKSEL = EXCLK_6CK_14CK_0MS

 

Once the resetter quickly intervenes and sets the fuses, it then hides by tristating all of its pins, and hopefully, ARStudio will be able to complete a normal programming.

 

This way, I am able to free the ATTiny pin without jumping through hoops like a Circus Monkey each time I want to program the chip.

Since I run a programming sequence several hundred times during an afternoon, this would be painful indeed!

 

So now I just need to dig up the codes for the fuse settings I want.

When I have access to a real internet again, i will try downloading the "big" datasheet.

 

Cheers,

Brad

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee has already shown this, but let me highlight:

 

 

 

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Jul 1, 2016 - 03:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
This way, I am able to free the ATTiny pin without jumping through hoops like a Circus Monkey each time I want to program the chip. Since I run a programming sequence several hundred times during an afternoon, this would be painful indeed!

Now, I know that you do different stuff than us mere mortals.  (but really, you do a cut-and-try once a minute or so during dev?!?)

 

Anyway, if it were me I'd be tempted to do the main dev on a similar AVR model with enough pins, "porting" to the end model at intervals.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can see both Lee's and Brad's point of view. I imagine the nature of Brad's work tends to require the solving of very device specific issues. I have an inbetween approach where I've made my own hvsp/isp capable programmer (Dickson charge pump!) for PDIP 8pin tinies with a header which exposes all of the pins for connection to an external board. I'm still not a member of the hardware debuggers club, but I've built some rudimentary monitor functionality into the programmer. Fine for me, but a straight-jacket for zombies :)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks for the highlighting! The info was all there, but it was my lack of experienc with fuse bits that made it invisible. I have what I need now.

 

Yes, I do in fact "code and burn" often more than once per minute.

When you are writing VGA demos that require line by line line chasing, your debugger is your monitor!

Often, one single instruction is enough to make it or break it, so I hit "program" a LOT!

 

This new approach to HV programming is a continuation of this project...

 

https://www.avrfreaks.net/forum/a...

 

Which was created to support this project...

 

https://www.avrfreaks.net/comment...

 

The "Self Replicating Boot Unloader" did work, but it had some drawbacks.

First, it ate 1K of program memory, which is too much on an ATTiny.

Second, it could brick the ATTiny if you did something really stupid, and this would require an HV resetter.

 

So now, I have solved every annoyance and gotcha associated with the ATTiny series...

 

- You can now use every IO pin properly.

- You get to use 100% of the program memory.

- You can work with Studio and an AVRISP only.

 

I enjoyed the Quark-85 VGA Demo System so much that I want to keep it going.

After my brief  seduction to to PIC8 and PIC32, I truly appreciate how unmatched the AVR is.

 

Anyhow, thanks again for the pointers (and I ain't talkin' no C lingo when I say that!).

I will post this simple project here with code and photos when I get it completed.

 

One last question if I may!...

 

I heard that it is possible to add the fuse settings in code, and found this C example...

 

FUSES =
{
.low = LFUSE_DEFAULT,
.high = (FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN & FUSE_JTAGEN),
.extended = EFUSE_DEFAULT,
};

 

I am not sure if the above does anything, as I am an assembly dude, so if anyone knows if it is possible to define fuse settings in code (without screwing around with make files and such), this would be nice to know.

My program is a single main.s file (GCC GAS) program.

 

 

Cheers,

Brad

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sat. Jul 2, 2016 - 01:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I heard that it is possible to add the fuse settings in code, and found this C example...

That does result in the fuses ending up in the .o/.elf as separate section(s) at the end of the build process.  That section(s) can then be broken out of the .elf and passed to avrdude.  There are a few ways to approach this.  I do it like this (makefile fragments):

	srec_cat $(PROJECT).fuz -Intel -crop 0x00 0x01 -offset  0x00 -O $(PROJECT).lfz -Intel
	srec_cat $(PROJECT).fuz -Intel -crop 0x01 0x02 -offset -0x01 -O $(PROJECT).hfz -Intel
	srec_cat $(PROJECT).fuz -Intel -crop 0x02 0x03 -offset -0x02 -O $(PROJECT).efz -Intel

... and then pass each of the .?fz files to avrdude.

 

EDIT: whoops I see I missed:

ZFLAGS=-O ihex -j .fuse --set-section-flags=.fuse=alloc,load --no-change-warnings --change-section-lma .fuse=0
	$(OBJCOPY) $(ZFLAGS) $(PROJECT).elf $(PROJECT).fuz

... and some other details

/EDIT

 

Remember also to -R .fuse when objcopy'ing the flash and eeprom sections.

 

Yes the above is somewhat C specific in my own case (I don't use Studio, by the way), but I expect there is a way to achieve the same in an all-assembler project.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Jul 2, 2016 - 03:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just wanted to say thanks again, I now have the fuses being written as required.

The final step will be to isolate the project onto a board that plugs between AVRISP and Breadboard.

 

Hey Joey, how did you implement your Charge Pump?

This is how I did mine...

 

Dual IO Pins set for PWM at 500KHz, each at 180 degrees to the other.

At this frequency, I found that .1uf caps were ideal to generate the ~12 volts.

Taking into consideration the internal resistance of the reset pin, I have 4 caps and 3 diodes.

3 caps and 3 diodes form the pump, and the 4th cap is the "buffer" to smooth the pulsed DC.

To control the HV, I disable PWM and set the Charge Pump input pin to Low.

 

To make this thing "part of" my AVRISP, I now actually power the ATTiny directly from the ATMega99 IO pins!

Several IO pins are tied together to source VCC to the ATTiny, although I found one IO to be fine.

 

The last piece of the puzzle is going to be the switching of the ATTiny external oscillator module.

It has no EN pin, so I will need to route it to the Resetter board and back, through an HC logic switch.

 

Once completed, the Resetter will be invisible to be toolchain, which consists of only Studio7 and an AVRISP.

Now I can utilize 100% of the ATTiny resources (or lack thereof)... 6 IO pins, and all of the Program Memory.

 

.... All this just to push the ATTiny a little further! Already running it at 36MHz!

 

Cheers!

Brad

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dual IO Pins set for PWM at 500KHz, each at 180 degrees to the other.

At this frequency, I found that .1uf caps were ideal to generate the ~12 volts.

I experimented quite a bit with the PWM frequency.  I settled on 300 kHz.

 

Taking into consideration the internal resistance of the reset pin, I have 4 caps and 3 diodes.

3 caps and 3 diodes form the pump, and the 4th cap is the "buffer" to smooth the pulsed DC.

To control the HV, I disable PWM and set the Charge Pump input pin to Low.

Same here, except that I disable the pump by tristating the three pump inputs (2 PWM, and the high-side).

 

To make this thing "part of" my AVRISP, I now actually power the ATTiny directly from the ATMega99 IO pins!

Several IO pins are tied together to source VCC to the ATTiny, although I found one IO to be fine.

I do the same.

 

The pump output is around 17V IIRC.  I experimented also with modulating the pump output in software by enabling/disabling the PWM output and/or changing the PWM frequency (much like a normal switcher), but in the end I decided to just put a 78L12 on the output and leave the pump configured for maximum output.  The pump/reg output can source about 5 mA before the output drops below the regulated 12V.  HVSP programming current is ~250 uA so that is sufficient.

 

The reset pin can be delivered any of the four basic states: FLOAT, GROUND, VCC, HV(12V), controlled by a few transistors.

 

I also have monitoring of the 12V output, and HVSP doesn't begin until the pump/reg output is stable and within specs (11.5V-12.5V).

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Jul 3, 2016 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Homestead has been keeping me extremely busy, but I did get a few hours to finish my new programmer, and it works great!

I now have what may be the first "AVRISP compatible In Circuit ATiny HV Programmer" ever!

 

Well, it really isn't a programmer, it just does a quick fuse programming through HVSP right before Studio takes control with the AVRISP.

To make this work, I actually ended up using 2 DPDT relays salvaged from old modems.

The relays disconnect the external oscilator, VCC, and a few other pins to allow the HV programmer to "Hijack" the ATiny for a few milliseconds.

 

Now I can program in AVRStudio using my AVRISP, and can use every IO pin on the ATiny, even the normally unavailable PINB.5 (reset).

 

The only thing I have not been able to do is specify the fuse settings in my code (see my question in post #16).

I need to set the RSTDISBL fuse to disabled so I don't have to open the fuse dialog each time, which adds an extra step.

It seems you can do this in C or with something called an AVR Dude, but I use neither.

 

Does anyone know if this can be done in a Studio6.2 Assembly program?

Some kind of #define or assembler switch?

Have not found anything in my searching yet.

 

Cheers!

Brad

 

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Mon. Jul 25, 2016 - 08:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Had another look around and it would appear that what I am trying to do in Studio is impossible.

I know a production file will do this, but that is not what I need.

 

I need to be able to write code in the editor, and then press the "Start Without Debugging" button to program the ATiny.

During programming I want the Reset Disabled fuse set...

 

 

The above image shows the programming dialog box, which I don't want to use.

Pressing the "Start Without Debugging" button is soooooo much faster!

 

I may dig into Studio with a Hex editor and see if I can hack the checkbox to default checked somehow, but this is ugly!

 

One last glitch in my otherwise perfect Matrix to fix!

It is nice to have a 6 IO ATint85 up and running though!

 

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Thu. Jul 28, 2016 - 01:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I realize that the only way to make the programming dialog window do what I want is by the way of an ugly hack... aka HEX Editor.

Does anyone here know the inner works of Studio7 enough to offer a hint as to which file needs "adjusting"?

 

I am probably close, but most of the files will take some time to look through. In this folder, I found 2 possible targets...

 

C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application

 

One is "programming.dll", and the other is "ioview.dll".

I will start with programming.dll, as it seems more logical.

 

Sooner or later I will find the file that controls the Device Programming window shown in the my last post, and I will tame it.

If anyone is interested in a "Switch" program to hack certain default fuse selection boxes on or off, let me know.

 

Software just has to realize that I am in charge, and one way or another I always get what I want.

Hex Editor bliss!... reminds me of the C-64 Basement Boys Fast Hackem' days!

 

Cheers,

Brad

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com