HV Programmer PCB - available

[greenonline]

Hi Wayne, I am sorry to raise an issue that isn't directly related to this repository, but I didn't know how else to ask this question.

---

A the bottom of the page AVR/Arduino Hardware Debugger on the Cheap (revisited), there is a tantalising photo of a mini shield HV programmer, that looks to have been fabricated using OSHPark.

However, looking through your OSHPark shares, I can't see that particular board being available.

Is it available? If not, could it be made available?

Many thanks

[wholder]

Please see:Wayne's Tinkering Page - AVR/Arduino Hardware Debugger on the Cheap (part 3)sites.google.com WayneOn May 29, 2023, at 2:16 PM, greenonline ***@***.***> wrote: Hi Wayne, I am sorry to raise an issue that isn't directly related to this repository, but I didn't know how else to ask this question. A the bottom of the page AVR/Arduino Hardware Debugger on the Cheap (revisited), there is a tantalising photo of a mini shield HV programmer, that looks to have been fabricated using OSHPark. However, looking through your OSHPark shares, I can't see that particular board being available. Is it available? If not, could it be made available? Many thanks —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[greenonline]

Thanks for the reply.

I have both read AVR/Arduino Hardware Debugger on the Cheap (part 3) and watched AVR Debugger Part 2
a few times now and unless I am missing something, both that board, DebugWire Programmer-Debugger-10 and its earlier revision DebugWire Programmer-Debugger-09 only deal with standard 5V programming. However, they do not appear to be capable of High Voltage (HV) programming and fuse resetting. They do not appear to have an input for 12 V.

Whereas the board shown at the bottom of AVR/Arduino Hardware Debugger on the Cheap (revisited), appears to have a shunt/link or connector labelled HV and 5V.

Indeed, even point 5 at the bottom of the page (just above the photo) states:

5. A new and improved AVR High Voltage Fuse Reset circuit you can use to recover accidentally "bricked" AVR devices.

I am only asking because you appear to be the only person who has made an actual PCB of a "mini-shield" version of a HV programmer. I am aware of the stripboard versions of Ralph Bacon (et al.) and have myself made a dual ISP/HVSP stripboard version (ATtiny_HVSP-ISP_stripboard).

However, I prefer the look of your mini-shield HV programmer PCB, that uses only through-hole components, and doesn't use any SMD components.

[greenonline]

Ah, after actually looking through the code of DebugWireDebuggerProgrammer.ino and having read the comments, it would seem as if I had indeed missed a major point that wasn't raised in the blog nor video (apologies for that).

These comments would seem to imply that the debugWIRE board and the sketch can be used to set the fuses:

//  Similar commands support writing to Fuse bytes, etc:
//    ispSend()             Effect
//    0xAC 0xA0 0x00 <val>  Writes <val> into ATTiny85 Low Fuses byte
//    0xAC 0xA8 0x00 <val>  Writes <val> into ATTiny85 High Fuses byte
//    0xAC 0xA4 0x00 <val>  Writes <val> into ATTiny85 Extended Fuses byte
//    0xAC 0xE0 0x00 <val>  Writes ATTiny85 Lock Bits
//    0xC1 0x00 <pg> 0x00   Sets selected EEPROM Page to (<pg> & 0x03)
//    0xC0 0x00 <add> <val> Writes <val> to EEPROM address (<add> & 0x3F) on selected Page
//
//  IMPORTANT: Be very careful when changing the value of fuse bytes, as some combinations will put the chip in
//  a state where you can no longer program or communicate with it.  This can be especially tricky because the
//  enabled fuses are typically such that setting a bit to '1' disables the fuse and '0' enables it.

So, it would seem that passing 0xAC 0xA8 0x00 0x5F to ispSend() would allow one to set the RSTDISBL bit of the high fuse (HFUSE), thus providing 6 IO pins. However, the warning comment seems to imply that once the RSTDISBL bit has been set, it is thereafter no longer possible to communicate with the ATtiny, even using the debugWIRE protocol. Am I correct in that assumption?

Therefore, there would still be a requirement for a high voltage programmer to effectively unbrick the ATtiny, in order to upload a new sketch. Is that correct?

So, without wishing to labour the point, getting back to my original query:

• Assuming that my assumptions above are correct, it would still be useful to have a standalone HV programming mini shield, so that the ATtiny can be unbricked.
• Even if my assumptions above are incorrect, and once the the RSTDISBL bit has been set, the debugWIRE protocol can in fact still be used to unset the the RSTDISBL bit, it would still be nice to have a HV programmer that can be used, without the need to resort to using the debugWIRE protocol.
• Lastly, if you have gone to the effort of making a nice mini-shield for a HV programmer, it seems a bit of a shame to let that hard work go to waste and not to release an (unsupported) board :-). Could I ask why you decided to withdraw the HV programmer from the OSHPark shares? Was there an issue with the board, or you didn't want to support it?

Many thanks anyway for all of the work that you have put into these project(s). I am sorry if I come across as being persistent, but I would be most interested to read your reply. Thanks again. :-)

[wholder]

Have seen this project on my tinkering page?Wayne's Tinkering Page - ATTiny10 C IDE and Improved Device Programmersites.google.comWayneOn May 30, 2023, at 10:08 AM, greenonline ***@***.***> wrote: Ah, after actually looking through the code of DebugWireDebuggerProgrammer.ino and having read the comments, it would seem as if I had indeed missed a major point that wasn't raised in the blog nor video (apologies for that). These comments would seem to imply that the debugWIRE board and the sketch can be used to set the fuses: // Similar commands support writing to Fuse bytes, etc: // ispSend() Effect // 0xAC 0xA0 0x00 <val> Writes <val> into ATTiny85 Low Fuses byte // 0xAC 0xA8 0x00 <val> Writes <val> into ATTiny85 High Fuses byte // 0xAC 0xA4 0x00 <val> Writes <val> into ATTiny85 Extended Fuses byte // 0xAC 0xE0 0x00 <val> Writes ATTiny85 Lock Bits // 0xC1 0x00 <pg> 0x00 Sets selected EEPROM Page to (<pg> & 0x03) // 0xC0 0x00 <add> <val> Writes <val> to EEPROM address (<add> & 0x3F) on selected Page // // IMPORTANT: Be very careful when changing the value of fuse bytes, as some combinations will put the chip in // a state where you can no longer program or communicate with it. This can be especially tricky because the // enabled fuses are typically such that setting a bit to '1' disables the fuse and '0' enables it. So, it would seem that passing 0xAC 0xA8 0x00 0x5F to ispSend() would allow one to set the RSTDISBL bit of the high fuse (HFUSE), thus providing 6 IO pins. However, the warning comment seems to imply that once the RSTDISBL bit has been set, it is thereafter no longer possible to communicate with the ATtiny, even using the debugWIRE protocol. Am I correct in that assumption? Therefore, there would still be a requirement for a high voltage programmer to effectively unbrick the ATtiny, in order to upload a new sketch. Is that correct? So, without wishing to labour the point, getting back to my original query: Assuming that my assumptions above are correct, it would still be useful to have a standalone HV programming mini shield, so that the ATtiny can be unbricked. Even if my assumptions above are incorrect, and once the the RSTDISBL bit has been set, the debugWIRE protocol can in fact still be used to unset the the RSTDISBL bit, it would still be nice to have a HV programmer that can be used, without the need to resort to using the debugWIRE protocol. Lastly, if you have gone to the effort of making a nice mini-shield for a HV programmer, it seems a bit of a shame to let that hard work go to waste and not to release an (unsupported) board :-). Could I ask why you decided to withdraw the HV programmer from the OSHPark shares? Was there an issue with the board, or you didn't want to support it? Many thanks anyway for all of the work that you have put into these project(s). I am sorry if I come across as being persistent, but I would be most interested to read your reply. Thanks again. :-) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[greenonline]

Ah, very interesting indeed, I like the use of the MAX662ACPA. Thanks.

The page ATTiny10 C IDE and Improved Device Programmer shows a photo of the PCB. However, again, I am unable to find the PCB in your OSHPark shares . Will that be made available at some point?

[wholder]

Perhaps you didn't notice but, at the bottom of the page you referenced, you can find the file gerber.zip. You can upload this file to Oshpark, or many other PCB fabrication sites to have it made for you. With Oshpark, simply drag and drop the file onto the indicated place at the top of main page. On another note, it's been some time since I worked on any Attiny 10 projects. Since then I've directed my efforts to the newer tinyAVR® 1-series and 0-series and my MegaTinyIDE project, which you can read about here: https://github.com/wholder/MegaTinyIDE At one time I had planned to integrate the features from my earlier ATTiny10IDE <https://github.com/wholder/ATTiny10IDE> project into it but, due to health issues, I had to set that aside. Wayne

…

On Fri, Jun 2, 2023 at 7:29 AM greenonline ***@***.***> wrote: Ah, very interesting indeed, I like the use of the MAX662ACPA. Thanks. The page ATTiny10 C IDE and Improved Device Programmer <https://sites.google.com/site/wayneholder/attiny10-c-ide-and-improved-device-programmer> shows a photo of the PCB. However, again, I am unable to find the PCB in your OSHPark shares <https://oshpark.com/profiles/wholder> . Will that be made available at some point? — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIDM4SCUGQJE6X5SDHGM4LXJH2FLANCNFSM6AAAAAAYTFSZDI> . You are receiving this because you commented.Message ID: ***@***.***>

[wholder]

https://www.eevblog.com/forum/microcontrollers/(atmega-0-series)-eeprom-workings/