High Voltage Programming on ATtiny3216

[Nbelles]

Hello,

I have spent some time trying to get high voltage programming working on the ATtiny3216 but have not been successful. I have been doing the same thing I do with the ATtiny412 and ATtiny1614 (which have all been successful). I could definitely use some help. I've tried using multiple chips and none of them have been successful while in High Voltage mode but all have been successful when in normal UPDI mode. This is using the Arduino Nano HV Shield purchased through your Tindie store.

Thanks!

[Dlloydev]

What hardware are you using regarding the ATtiny3216 - development board or SOIC to DIP adapter? So for the the ATtiny3216, only UPDI Mode programming works (jumper removed) and HV Mode and PCHV Mode do not work? Are you using a direct connection to PA0 or is there any additional series or pullup resistor?

Note that any changes made in the Tools menu regarding any board or chip options requires a "Burn Bootloader" operation prior to uploading a sketch. You previously mentioned using Arduino 1.8.10 - have you tried Arduino 1.8.13? Its highly recommended for use with the latest megaTinyCore.

[Nbelles]

I'm using an SOIC to DIP adapter (a 24-pin version because they don't often make 20-pin versions) and I know it's not a soldering issue because I have lots of experience soldering and have tested multiple ATtiny3216 boards (both soldered by myself and by others). Correct, UPDI Mode works and neither of the HV modes work. I am using a direct wire to the three main pins (T5V, GND, and UPDI).

I am aware that I need to burn the bootloader for those kinds of changes. I have been unable to even burn the bootloader when in either HV mode. I am eventually trying to switch these pins to GPIO and don't want to brick my chips if I switch the UPDI pin to GPIO and then can't upload or burn bootloaders anymore...

You are correct, I normally use 1.8.10 but I just tried using 1.8.13 and got the same results: able to upload and burn when in UPDI mode but unable to upload or burn in either of the HV modes.

[Dlloydev]

OK, this is pointing to something with the enable sequence for this chip. I haven't specifically tested this chip variety so I just ordered a few of the ATTINY3216-SN‎ (40°C to +105°C) and ATTINY3216-SF (40°C to +125°C) chips and 20-pin SOIC to dip adapters with Digi-Key to see if I can reproduce the problem. The datasheet for these seems to offer more details than the info provided with other parts. To date, the closest to these I've already tested is the 20-pin ATtiny1606.

[Nbelles]

Yeah, I only have three different versions of the chip:

• ATtiny412 (UPDI, HV, and PCHV working)
• ATtiny1614 (UPDI, HV, and PCHV working)
• ATtiny3216 (UPDI working, HV and PCHV not working)

If there's anything that I can do to help in the testing process, I have an oscilloscope and have the technical knowledge to use it. I just ordered the parts to make my own HV programmer (using the DIY guide you have posted) and once those parts get in I will be able to test using a different version of the programmer to see if that has any effect.

(My very uninformed and uneducated thoughts: maybe the voltage spin-up that is generated by the ATtiny-based charge pump isn't precise enough of an on/off for the chip to recognize the timing of the HV pulse? I'm thinking the dedicated charge-pumps, although they are expensive might have a better on/off effect because they constantly generate the voltage internally, they just connect or disconnect it from the UPDI line whenever the shutdown line changes state.)

Edit: To clarify, I didn't order the parts for the DIY HV programmer just to help problem solve this issue, I also just wanted to be able to make it myself on a breadboard or small PCB.

[Dlloydev]

maybe the voltage spin-up that is generated by the ATtiny-based charge pump isn't precise enough of an on/off for the chip to recognize the timing of the HV pulse? Yeah - the charge pump's output has an exponential ramp up taking about 200µs with about 500µs clipped at 12V, then a fast turn off with a MOSFET shutdown. Although this is within the 100µs to 1ms specified range, it would be interesting to find out if there's any difference when using the LTC1262CN8 charge pump with opto isolator, which provides a quicker, linear ramp-up. I already have this setup (DIY Nano HV UPDI Programmer) on a breadboard for testing. Another difference with the Dickson charge pump is some minimal ripple on the signal.

Actually, it may have something to do with the lack of SYNC character. Initially I had SYNC as part of the enable sequence and everything worked fine, then there were some upstream updates made to the master jtag2updi where I needed to remove SYNC in order to make everything work. Then there were more updates made and AVR DA support added. The HV functions still work fine, but perhaps SYNC would now work if added back, or perhaps its an absolute requirement with the 3216 MCUs.

Anyways, I'll check all this when the parts come in. Thanks for your offer to help with testing ... I'm quite sure we'll get this resolved soon.

[Dlloydev]

The problem might now be solved .. now all wrappers used include HV support for ATtiny1604, 1614, 1606, 1616, 3216, 1607, 1617 or 3217. Also added HV support for the ATmega4809 Family. The jtag2updi firmware has been updated.

[Nbelles]

I have tried uploading the new code you just pushed and it doesn't seem to have solved the problem for me. I am still able to program the 3216 when in UPDI mode on the Arduino Nano HV programmer and it cannot find the board when I try to program the 3216 when in PCHV mode or HV mode.

[Dlloydev]

OK, thanks (that was quick!). The parts I ordered should arrive in 2 or 3 days. Will hopefully have some test results by the weekend.

[Nbelles]

Sounds good, I look forward to seeing what you come up with!

[Dlloydev]

The parts have arrived and I've soldered the ATTINY3216-SN‎ (40°C to +105°C) part to an SOIC adapter.

This is duplicating the exact same issue that you're having - unable to program (burn bootloader or upload) when in either HV or PCHV mode. UPDI mode works fine for all options with or without optiboot.

Then, I programmed it with the UPDI pin as Reset, and yes, its now bricked (I finally have something to work with). After looking through and interpreting the datasheet, I've come up with a table describing the steps for the UPDI enable sequence. Most of the timings can be found in section 36.21 UPDI Timing in the datasheet.

EDIT:

The Nano HV Programmer shield uses Schottky diodes with 1μA leakage and has a HV shutdown MOSFET which reduces the HV turn off time to about 2µs. Testing with the Nano HV Programmer, this is as far as I can get with a new enable sequence. I've gone through the datasheet with a fine-toothed comb (see references below).

This sequence works perfectly on the 1606 for all modes, but I still can't get it to communicate with the 3216 with its UPDI pin configured as Reset.

EDIT2:

I'll push the details of an updated enable sequence in the Wiki when ready. Just installed MPLABX IDE so I can try out the Power Debugger I purchased some months ago ... so there's a learning curve to overcome.

OK, I now have a minimal setup (project) working for the ATtiny3216. Can read and program the Configuration Memory (fuses) and use the Power Debugger's HV activation modes. Capturing the UPDI signal on a Saleae Logic Pro 8 with both digital and analog channels reveals that they're using some unpublished differences in the sequence, timing and communication.

[Dlloydev]

The firmware has been updated with a New HV Enable Sequence similar to the Power Debugger The waveform and timing closely resemble the Power Debugger's output.

This should have full compatibility for all programming modes for the ATtiny3216 and possibly others that have the more strict UPDI enabling / activation requirements.

Note that after power up, the very first attempt to program an ATtiny3216 with PA0 as Reset or GPIO will usually fail, but subsequent programming sessions are successful. This is similar to the MPLAB PICkit 4, where HV activation fails the first time but will work if tried the second time.

[Dlloydev]

Another new firmware update!

Added a double-enable sequence on power-up.

This resolves any UPDI enable issue on initial power-up. Just like double-break is sometimes needed to ensure reset, a double-enable for the UPDI seems to work fine, even with ATtiny MCUs with the older silicon revisions.

[Nbelles]

Alright, that seems to have fixed my issues with programming the ATtiny3216 in HV modes. But, now I can't program the ATtiny412. Will update soon about testing results for the ATtiny1614...

I did verify that it wasn't my chip by switching back to commit 89c10e61d02267d681f3556aa5e82df8e7f422ad and testing with that version.

[Dlloydev]

Thanks ... I do have an ATtiny412 on hand in another circuit so I'll investigate. The easy solution would be to just detect the 3216 and put a wrapper around the code, but I'll only do this as a last resort because most likely the existing timing / code could be adjusted to work with everything. I'll see what the Power Debugger reveals.

For the next update (which shouldn't take so long, I'll make sure this works with the ATtiny412/1604/1606/3216 (4 parts) as that's all I have on hand.

[Nbelles]

I can verify that the current version works on the ATtiny3216 and the ATtiny1614.

[Dlloydev]

Great.

OK, the ATtiny412 dev board I have on hand tests OK for all modes. The one I have doesn't have tight enable spec because it doesn't stretch the enable trigger pulse at any time. I'll be able to test with the Power Debugger later this evening to see if I can find any timing differences.

I wonder if the Rx pin floating could cause issues? For my setup, I used 20MHz clock and BOD at 4.2V.

Still, since the older code works on your chip, something in the timing / code must be borderline. Another thought ... maybe your chip is a different hardware version.

[Nbelles]

Is there an easy way to check hardware version?

[Dlloydev]

Not sure if it can be read out from the chip or not. This is the pic for the one I tested.

EDIT: From the part marking guideline

Line	Marking
Line 1= Device Name	1412-N
Line 2 = Device Information	920B TW
Line 3 = Lot Traceability	19207W1

Probably Revision B judging from the device information. The markings on the above image of the ATtiny3216 would imply Revision C.

[Nbelles]

Information from the chip that I have been programming:

Line	Marking
Line 1 = Device Name	T412-F
Line 2 = Device Information	835B TW
Line 3 = Lot Traceability	183546Y

It looks like we have different temperature rated versions of the chip. The temperature ratings can be found below. Maybe the possible ranges of temperatures allowed means their timing tolerances have to be different? Although, if yours are less capable to handle wide ranges of temperature (signified by the N) then I would think their timings would have to be more precise and that the chips that are capable of wide ranges of temperatures would have to be tolerant to less accurate timings. Not sure...

Marking	Temperature Rating
N	-40°C to 105°C
F	-40°C to 120°C

[Dlloydev]

I'll order both temperature versions today then test them on SOIC-8 to DIP adapters soon after they arrive.

I've just tested the T412-N part with default settings in megaTinyCore 2.05 with optiboot, and UPDI/reset pin as GPIO with clock speed at 20, 16 and 10 MHz. All tests worked, so various MCU clock frequencies didn't harm the communication .

I think the first 2 digits in Lot Traceability might be the year. If that's the case, mine would be 2019 and yours 2018 year of manufacture. I do have a part on hand that appears to closely match yours, except its the 2K version, so I'll give it a try.

I've yet to decipher most of the initial UPDI commands used by the Power Debugger. New at this, but going from the hex code to the appropriate command and register setting in the datasheet is starting to make sense.

[Nbelles]

I'll try again one more time to verify that I can't upload to it with the latest version just to make sure. Sorry that you have to keep buying parts on my behalf. Hopefully we can get this figured out quickly.

[Dlloydev]

Oh, I'm collecting the parts anyways ... lots of future projects in mind (but short on time). I've just tested the ATtiny212 shown above and it works OK for all modes, UPDI pin configurations, and at 20/16/10MHz. This could take a while, but glad you have a version that works with your ATtiny412. In the meantime (and spare time) I'll learn more about the UPDI protocol and later get some test results from the 412 parts on order.

[Nbelles]

Just verified again with the following parameters:

• Arduino 1.8.13
• megaTinyCore 2.0.5
• jtag2updi 468193cca69b2f9230970b1e6f226ba46436ad69 (most recent commit as of this post)
• Arduino Nano HV UPDI Programmer
• Mode: PCHV

Target Device	Device Information	Lot Traceability	Status
ATtiny3216N	1850C TW	18501C4	Working
ATtiny1614N	940A TW	19407JR	Working
ATtiny412F	835B TW	183546Y	Not working

[Dlloydev]

Gosh, look what I've found! (order cancelled). Will have results later today.

[Nbelles]

Oh good. I was going to work on sending you the oscilloscope data so that you could compare the differences between the ones that are working and the ones that aren't but I don't currently have access to the high quality oscilloscopes that I normally do. Glad you found some!

[Dlloydev]

OK, didn't take long to setup and test. Yep, it totally replicates the issue you're having. I'm out of time for now ... but I've got something to work with!

[Dlloydev]

Resolved! Just needed to disable Collision/Contention detection and disable the UPDI interface in preparation for normal program operation. Tested on the ATtiny3216, ATtiny412F and ATTiny1604. I suspect everything's OK with the complete 0-1 series of parts now. Firmware updated.

[Nbelles]

I'm unable to program my ATtiny1614's and my ATtiny 412's but am still able to program the 3216's...

I'm going to check and see if the ATtiny1614 works with the previous version, just want to make sure it was something you did and not something I messed up accidentally.

EDIT: Commit Number: 89c10e61d02267d681f3556aa5e82df8e7f422ad	Target Device	Device Information	Lot Traceability	Status
ATtiny3216N	1850C TW	18501C4	Not working
ATtiny1614N	940A TW	19407JR	Working
ATtiny412F	835B TW	183546Y	Working

Commit Number: 90f1bf70914f258ea73701ec3098202563516f23	Target Device	Device Information	Lot Traceability	Status
ATtiny3216N	1850C TW	18501C4	Working
ATtiny1614N	940A TW	19407JR	Not working
ATtiny412F	835B TW	183546Y	Not working

[Dlloydev]

Had a compiler warning I missed ... fixed the new command to disable collision/contention detection and the UPDI interface (now applied only at startup).

Arduino 1.8.13 megaTinyCore 2.0.5 Arduino Nano HV UPDI Programmer (shield) Mode: PCHV Firmware updated: Tested the following MCUs, all working. PA0: GPIO Target Device	Description	Status
ATtiny212N	On SOIC-8 to DIP-8 adapter	Working
ATtiny412F	On SOIC-8 to DIP-8 adapter	Working
ATtiny412N	Development board	Working
ATtiny1604N	Development board	Working
ATtiny1606F	Development board	Working
ATtiny3216N	On SOIC-20 to DIP-20 adapter	Working

[Nbelles]

Now I'm in a really weird place. I can burn the bootloader on the 412F but I can't upload sketches. On the 1614N I can upload sketches but not burn the bootloader. On the 3216N I can upload sketches and burn the bootloader. This is all in the PCHV mode, I haven't tested the other modes because they are so many combinations.

[Dlloydev]

OK thanks, I was wondering what your results were.

The only part I can find issue with on my end, is the ATtiny817, where its on an XPLAINED MINI with its built in debugger isolated. Here, I'm finding that everything works when the optiboot option is used. When the optiboot isn't used, a second try is needed for success. The weird thing is that the success/fail is in a "toggle mode" where it always remembers the previous success/fail status, even if I disconnect then reconnect the USB cable. So the temporary workaround here is to try twice.

Does a second attempt change anything?

For 3 of the parts I tested, they were all being powered simultaneously - I only switched the UPDI signal. I have a 47µF cap across the power rails. (this breadboard is being powered by the Nano HV UPDI Programmer).

I've just now got the MPLAB Snap Debugger running so it'll be a good second reference for normal UPDI mode tests.

Yeah, your non 3216 parts remain affected by their temperature grade. I've also encountered this on an earlier firmware version. The temp grade isn't even a consideration or option in MPLAB or with their debuggers.

Seems like a borderline timing issue ... more research, testing and (ahem) trial and error required!

[Nbelles]

I have a very similar setup. After testing again, I am no longer able to upload to or burn the bootloader on the 1614N or the 412F... Still able to do both functions on the 3216N though.

EDIT: Not sure why I can't upload an image properly but if you can see it great, if not, just look at your setup, they are almost exactly the same. Chips down the middle on breakout boards using the rails for power distribution. Just moving the UPDI cable between them.

[Dlloydev]

So if you try a second programming attempt right away, it still fails? Note the voltage level might make a difference ... I'm getting only about 4.7-4.8V. There's 5V available on the 6-pin connector - there'll be no power-cycle but I wonder if it works better. For the pics, I just drag n drop. Gotta go for now .... will be able to do some tests later tonight.

[Nbelles]

(I was dragging and dropping, and I've gotten photo upload to work before. Not sure why it isn't working now.) So I just tried again by supplying voltage to the rail directly from the ICSP connector on the Arduino Nano like you mentioned and that seemed to fix it. Now I can upload every other time on the 1614N or the 412F just like you experienced. But it seems that no matter what state it was in before, I can always upload to the 3216N.

It seems like this version is working for all chips (assuming you're okay with having to double upload on some chips and assuming your voltage level to the chip is high enough).

EDIT: I've been using your version of the high voltage updi programmer for some time now to program chips and just now realized after re-reading your last message that the chip has to be powered off of the T5V pin for the power cycling to work properly. I always thought that the PCHV mode would send a UPDI command when it was done programming to have the chip power cycle itself. Looking back, I'm sure that was the cause for a lot of issues I've had in the past with trying to get the GPIO working on the UPDI pin because I didn't use the T5V when setting the fuses in the bootloader and then would immediately upload a test sketch and not see the output working properly so I would assume I did something wrong and then come back to it later (after unplugging and plugging back in) and it would start working and be very confused. It might be that I didn't read you documentation well enough and just looked to see what mode I needed it to be in and moved on. Also looking back, it makes total sense why you called it T5V (for Target 5V) and makes sense why you need to use that pin to turn off the chip and back on. Learn something new everyday.

[Dlloydev]

Thanks so much for your help. I think now the issue that remains is quite similar if not exactly the same as known issues here.

• I've noticed some UPDI baudrate differences between products.
• jtag2updi is by default at 225,000 but this setting can only be lowered to 160,000 minimum.
• For the Power Debugger and Snap Debugger, you can set the baudrate from 100,000 to 750,000 maximum. However, the initial commands during a programming session (activation sequence and activation key) runs at a lower baudrate 25,000 for the Snap and 100,000 on the Power Debugger. Then they switch to the set rate. Anyways, more testing to do....

[Nbelles]

Thank you so much for going through all this work! I know it wasn't easy and took a lot of time. I really appreciate all the effort you put in to fixing this issue. If there's anything I can do to help in the future, feel free to @Nbelles whenever and I'll be glad to help out. I would love to continue to support this repo because of how much it has helped me.