Hello,
I made a small modification which improves HVSP compatibility, at least in my setup. Maybe it's useful for others:
The datasheet for the HVSP-compatible tinys lists two methods for entering HVSP mode. One is to apply Vcc which must rise within 20us from 0V to at least 0.9V, then apply 12V to RESET. This is fine when you program a tiny in the socket. But when you use HVSP for in-circuit programming (this is what I do, need to program SO8-Tinys which are soldered to a board using a SO-testclip) and the tiny is connected to a capacitor for Vcc stability, this condition can't be met.
In that case, the datasheet has a second way: power up Vcc and monitor it. As soon as 0.9V is reached, apply 12V to RESET.
I noticed that the 0.9V level isn't critical, however, entering HVSP mode will fail if you apply 12V to RESET too early. In my setup, the tiny is connected to an 47µF cap (and 100nF either), so voltage after 20us is about 0.1V.
So I connected Vccprog to PC2 on the ATmega8 which is ADC channel 2. Then I modified vreg.c to monitor this channel as well (as long as it's not needed for ISP programming ofcorse). The HVSP mode was modified to wait until PC2 reads more than at least 0.9V before powering up 12V.
With that setup, I had no more problems to flash my tinys. Before that, sometimes it worked, sometimes it did not. The STK500 does monitor Vccprog too. The solution mentioned is not very exact as the ADC channel has quite a low sampling frequency. But as noted above, the tiny doesn't care about the timing and voltage level as much as long as RESET goes high after Vcc.
The source code changes are simple, if you are interested, I can submit a diff file.
Regards,
Sebastian
AVRDoper - Entering HVSP mode
Re: AVRDoper - Entering HVSP mode
Please post the diffs here in the forum so that others who are interested can apply them.
I'm not sure whether we should change the default implementation. I have tested it with most of the available 8 pin devices and am therefore reluctant to change anything. Our circuit has a only a programming socket, after all, not a connector for in-circuit high-voltage programming.
I'm not sure whether we should change the default implementation. I have tested it with most of the available 8 pin devices and am therefore reluctant to change anything. Our circuit has a only a programming socket, after all, not a connector for in-circuit high-voltage programming.