ATTiny1607 hiccups while getting started.

[dattasaurabh82]

First of all thanks for all the effort. I'm not an embedded sys engineer so lack quiet a bit of internal knowledge.

I was looking for a small low power uC and the new ATTiny series were too tempting to not try. So I got myself ATTiny1607 I soldered it on a breakout board and followed the steps here: https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

My arduino type head says: first upload bootloader (although not necessarily necessary here) and then uC is ready for easy programming.

So I wired up accordingly and here are the details of my setup:

1. Serial programmer used: FTDI chip based on FT232RL (Don't have CH340G based serial adapters in hand at the moment) :
   • [ ] To be checked later: With CH340G based Serial Adapter after I get one. 😞
2. Used a 4.7K resistor between Rx & Tx lines: according to this There is no inline resistor, in series, to TX line on my FTDI board.
3. I do not also have Schottky diode in hand as well ☹️
   • [ ] To be checked later: Use Schottky diode 😞 . Also If that Schottky diode is used, do we really need to worry about any other resistor?

[ Serial Adapter ]                                [ ATTiny1607-MFR ]
VCC [tried both 5 & 3.3V lines]  --------------->  Pin number 4 (VCC pin according to data-sheet)
GND -------------------------------------------->  Pin number 3 (according to data-sheet)
RX _____________________________________________> UPDI/!RESET pin (Pin number 23 according to data-sheet)
                     /
TX ___/\/\4.7K/\/\__/

Here's my setup in the Arduino IDE:

After that I have tried uploading the boot-loader and it seem to work:

Arduino <---> pymcuprog bridge by Quentin Bolsee and Spence Konde
Version 1.1.0 - May 2021
Using serial port /dev/cu.usbserial-00000000 at 57600 baud.
Target: attiny1607
Set fuses: ['0:0x00', '1:0x00', '2:0x02', '4:0x00', '5:0b11000100', '6:0x04', '7:0x00', '8:0x02']
Action: write
File: /Users/saurabhdatta/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.3.2/bootloaders/hex/optiboot_txyz.hex
Pinging device...
Ping response: 1E9423
Setting fuse 0x0=0x0
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x1=0x0
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x2=0x2
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x4=0x0
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x5=0xc4
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x6=0x4
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x7=0x0
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x8=0x2
Writing literal values...
Verifying literal values...
Action took 0.19s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type internal_sram is always erased
Memory type lockbits is always erased
...
Erased.
Action took 0.06s
Writing from hex file...
Writing flash...
[==================================================] 8/8
Writing flash...
Action took 0.85s
Verifying...
Verify successful. Data in flash matches data in specified hex-file
Action took 0.18s

But then if I try a basic blink sketch:

void setup() {
  // put your setup code here, to run once:
  pinMode(20, OUTPUT); // Pin number 2 on the breakout board and the data-sheet
}

void loop() {
  // put your main code here, to run repeatedly:
  digitalWrite(20, HIGH);  
  delay(1000);
  digitalWrite(20, LOW);
  delay(1000);
}

And try uploading by using Sketch->Upload Using programmer (I did not save the sketch) I get this error and it doesn't blink:

Arduino <---> pymcuprog bridge by Quentin Bolsee and Spence Konde
Version 1.1.0 - May 2021
Using serial port /dev/cu.usbserial-00000000 at 57600 baud.
Target: attiny1607
Set fuses: ['2:0x02', '6:0x04', '8:0x02']
Action: write
File: /var/folders/yp/37w_03rx1qdbfsqckbyyk9t80000gn/T/arduino_build_643606/sketch_jun07a.ino.hex
Pinging device...
Ping response: 1E9423
Setting fuse 0x2=0x2
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x6=0x4
Writing literal values...
Verifying literal values...
Action took 0.19s
Setting fuse 0x8=0x2
Writing literal values...
Verifying literal values...
Action took 0.19s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type internal_sram is always erased
Memory type lockbits is always erased
...
Erased.
Action took 0.06s
Writing from hex file...
Writing flash...
[==================================================] 12/12
Action took 0.94s
Verifying...
[==================================================] 2/2
pymcuprog.programmer - ERROR - Verify failed: Verify mismatch starting at location 0x000200: 0x0C vs 0x00
Action took 0.22s

Any pointer would be helpful? 🤔

[hmeijdam]

That's what you get if you select "with bootloader" (optiboot) but not using the bootloader to load your sketch. Select without Optiboot when uploading via UPDI

[dattasaurabh82]

That's what you get if you select "with bootloader" (optiboot) but not using the bootloader to load your sketch. Select without Optiboot when uploading via UPDI

Got it. Thanks. 😅 So after selecting the chip series without optiboot. It works now fine.

One more question though; if I upload the boot-loader (after selecting the chip series with optiboot), then connect the RX/TX pins from the Serial Adapter to the TX/RX pins of the ATTiny, I could upload the code for the first time by just clicking upload. But next time if I want to upload (by just clicking upload and without changing anything in HW), it chokes and doesn't upload. Any thing to do with RESET?

[hmeijdam]

I don't use Optiboot myself, but assume that if you just burn Optiboot to the chip, with no other software on it, the bootloader is the only thing on it and will wait for some upload to come.

Once you upload the first sketch then, Optiboot will no longer wait, but handover to the sketch, that is then running. You would have to reset to have Optiboot looking again for a brief moment if there is an upload. Have you tried resetting (powercycling) the Attiny, while your uploader is waiting for a response from it?

[SpenceKonde]

The issue you are having uploading after the first bootloading is due to the fact that the bootloader only runs after a reset.

You can turn the updi pin into a reset pin and use autoreset on that, but then if you ever need to program via UPDI again, you need an HV programmer. Do note that the diode from reset to vcc that the traditional autoreset circuit has, which is present for cargo-cult purposes on classic AVRs, is actually needed here to keep it from triggering hv mode when it releases DTR). I don't recommend it if you don't already have an HV programmer. Hell, I do already have an HV programmer - several that folks sent me, actually - and still haven't even bothered to get set up with one. I just put the boards I brick into the dogpile. and I know that all the 0/1/2 tinyAVR parts in there are there because they need fuses fixed in HV mode if they don't have obvious physical defects like the chip mounted backwards. There are at least a half dozen 1614's like that in there, some day I will get around to unbricking them and putting them back into my inventory, but I have much more important fish to fry atm....

Assuming you do not want to take such drastic action, the default bootloader option (as described briefly in the tools submenu, and in more detail in the documentation) states that the bootloader will run after a software reset or powercycle, for 8 seconds. so you would disconnect it from power, reconnect power, and start upload within 8 seconds. Thi is is even shown in your screenshot, the line "Optiboot for 8 sec. after power on and reset".

On the tinyAVR 2-series parts with 20 or 24 pins, there is a newly added option to use an alternate reset pin (PB4) and get the best of both worlds - in that case, after bootloading with that option selected, you'll get normal optiboot behavior (optiboot only after software or reset pin reset, only waits 1 second for upload attempt) while still having a UPDI pin.

Regarding the upload using programmer: Hmm yeah... we paper over the difference in fuses when you have a chip that is bootloaded with Optiboot, and then try to upload via UPDI with UPDI board definition selected (sketch would not work - it needs to be known at compile time whether it's running with a bootloader or not, because that determines the address the vectors start at) - we set those fuses whenever we upload via UPDI, because that erases the bootloader)

But I hadn't considered the possibility of "upload using programmer" when an optiboot board definition is selected. In the next release I will correct this so that a more useful error message is shown (eg "Upload using programmer is not supported for board definitions which use a bootloader.")

This will always be the case when programming through any method other than SerialUPDI. It is entirely possible to make SerialUPDI smarter, so that it could be told to, instead of triggering a chip erase cycle, erase page by page. I think for NVM v1, the changes would be trivial. NVM v2 is a bit more complicated, especially if we care about performance. (if we don't. it's still more work than for NVM v1)

[SpenceKonde]

Bug (target fix 2.4.0 release): Core will attempt to upload using programmer with optiboot board definitions selected and show an unhelpful message. This should be corrected to a better error.

Enhancement (no timeline): Add support for "bootloader aware" UPDI programming to SerialUPDI.

Issue should not be closed until an issue has been opened for the second half of this in the SerialUPDI repo. This is gated by required code review with Quentin before we make that repo public.

[SpenceKonde]

To answser question about resistor and diode It is preferred to have at least a little resistance somewhere between the target and the TX pin of the programmer, so that they can be completely out of sync indefinitely without having to worry about damage to the target. On tinyAVR the pin drivers are so weak on that pin that i don't think it matters one way or the other though. also, I was about to say that that adapter has a resistor on it already. but I just checked mine that looks like that and was stunned to find that it does not. That is only the second adapter design I've seen without one (also, I think the real boards that that design is a ripoff of (pretty sure the chip on it is also counterfeit) does have the series resistor. A long time ago when I learned about the existance of that resistor, there was confusion as I tried to reconcile my results with those of a collaborator, and we ev entually determined that I was using a custom adapter I'd designed before I knew about the use of that resistor, and he was using a commercial FTDI brand one).

Clearly you can get away without the resistor (I used that for all my development work using the FT232), and you can get away with it indefinitely except under particularly exotic fault conditions.

[SpenceKonde]

And a final note: if UPDI with FT232 is agonizingly slow (like hundreds of bytes per second slow no matter which option is selected), there's a driver setting you need to fix. It defaults to 16ms latency timer (ie, minimum time taken for round trip), and even when that is set to the minimum (1ms), write operations to tinyAVR are dominated by that latency at 230400 baud and up. So with default 16ms instead of 1ms, uploads will take 8.5x longer than they need to. Why FTDI would pick such a dumbass default is another issue.... 0.85s to write 512b flash makes me suspect you haven't fixed that setting, buit it's hjard top be sure wit such tiny upload

[dattasaurabh82]

Oh wow! 😀. Thanks everyone for so much in depth clarification and support. I will play with them a bit more ( tonight after work )and keep here posted. After that I think we can close this issue.

[SpenceKonde]

As I said above...

Bug (target fix 2.4.0 release): Core will attempt to upload using programmer with optiboot board definitions selected and show an unhelpful message. This should be corrected to a better error. Enhancement (no timeline): Add support for "bootloader aware" UPDI programming to SerialUPDI. Issue should not be closed until an issue has been opened for the second half of this in the SerialUPDI repo. This is gated by required code review with Quentin before we make that repo public.

There is indeed a bug (unsupported programming pathway attempted anyway) and I need to make sure not to lose that note about enhancement for SerialUPDI. It could also be used alongside the Flash module on the Dx-series parts to make data stored that way that persisted. The flash module here has a completely different API (the different API's are reflective of both hardware differences and tighter flash constraint for Dx, and the dramatically different views of what the right way to program is between the two authors - I did the one for Dx; I was working with basically no space in the bootloader section for the entry point yes so straight Optiboot-write-from-app method didn't fit anyway, MCUDude did tinyAVR one, because it's the same implementation as his MegaCoreX). MCUDude and I are both called to provide cores for every AVR under the sun (you'll notice that one of the two of us has a core for every AVR device that makes sense to use with Arduino that isn't something really bizzaro. .... but our programming styles could not be more different

[dattasaurabh82]

On the tinyAVR 2-series parts with 20 or 24 pins, there is a newly added option to use an alternate reset pin (PB4) and get the best of both worlds - in that case, after bootloading with that option selected, you'll get normal optiboot behavior (optiboot only after software or reset pin reset, only waits 1 second for upload attempt) while still having a UPDI pin.

I'm sorry but it's still a bit confusing for auto-reset part... 😅 I can see there are many RESET pin related options under tools-> and as mentioned in the readme as well But for ATTinys, with 20-24 pins, which option to select from tools-> dropdown to keep the UPDI programmer as UPDI and move RESET to PB4 (I'm aware that then PB4 will be un-usable as regular GPIO)?

Also For the Auto reset circuit, is it as below: (I created it after the reading more in details the README and after consulting the Arduino's auto reset schematic):

Does this look correct?

Also why the diode?

And after uploading code through Serial adapter, through RX-TX pins (RX-TX pins being the ones as set from tools->UART Pins menu before boot-loading) on 20-24 pin ATTinys, can those pins be used for Serial Read Write? I'm guessing, for those specific pins, if they can be used for Serial Read Write, we won't need Serial1 and just Serial Object and can use the same FTDI adapter?

[SpenceKonde]

Autoreset schematic is correct, yes.

Why the diode? Well. what happens when the adapter releases DTR? (I know, I know, strictly speaking it should be open drain so it shouldn't rise quickly - in practice many adapters have push-pull outputs there) That would generate a pulse of a voltage higher than Vcc on the reset pin - now usually, this wo9uld just make the clamping diodes discharge it to the positive supply rail - like that diode = and then you'd get to argue about whether the current was at any time exceeding the current injection spec. Except that the reset pin doesn't have the normal clamping setup. Applying 12v to reset is an intended programming mode. HV (high voltage) programming is what you use on a classic AVR if you disabled reset, or disabled normal SPI programming, or screwed up in a manner that so thoroughly hosed it that you can't get an ISP programmer to talk to it to un-hose it). Programmers for it are rare, and hobby grade solutions obscure. On classic tinies with under l;ike 12 pins or something it's HVSP,for bigger parts, it's HVPP and you need like >10 wires. Likewise the modern tinyAVR devices have HV UPDI mode. Except HV UPDI is way simpler - it's just an HV pulse followed by normal UPDI. ) (the new DA and DB-series and the megaAVR 0-series, both being blessed with plenty of pins, have dedicated reset and UPDI pins, and all you can do is disable reset. the UPDI pin remains UPDI. The upcoming AVR DD-series, however, will have that option, as it's going to be available down to 14-pin packages - though details of it's implementation are not in the IO headers that they've released,

On classic AVRs, the diode is there for superstition (there is a belief - entirely unproven might I add - that the cases where a problem that cannot be accounted for is fixed by burning bootloader. Thus, the theory is that a positive spike on the reset pin produced when DTR is released and goes high again can briefly throw the part into HV programming mode and somehow all the pins would receive signal or noise to exactly replicate a programming command that would corrupt the bootloader. This is a theory that strains belivability in the extreme wouldn't you say? One might expect that before the whole damned communirty downed the kool-aid and accepted that crackpot theory, folks would expect that the individual proposing this would have some sort of evidence. A smoking gun would be a flash dump from an impacted part. Of course, I have heard of no such "capture". Basically, the diode was put there on classic parts either because the Arduino team accepted with whacky theory, or just to make people shut up (it's harder to argue with people than just put an extra 2 cent diode onto the board).

However, on the tinyAVR 0/1/2-series parts,. that diode is essential. Because here, you don't need any complex programming pattern to manifest symptoms of HV programming options - simply putting an appropriate HV pulse on that pin can result in it turning back into UPDI until powercycled ( IIRC there was something weird about this, it was not nearly that simple - I think some of the 0/1 series are that easy to reset, others require communications within milliseconds of the pulse, forgety the deets, if I ever knew them).

On the tinyAVR 2-series parts (those would be ones where the 10's digit is a 2 - the ATtiny1627 for example - you would select the option " UPDI w/reset on PB4 (2-series only)" (non-optiboot), or "UPDI on PA0, RST on PB4 (Optiboot for 1 sec after reset)" (on the Optiboot 2-series board definitions). This functionality is not available on tinyAVR 0-series and 1-series devices - this (and the fact that it is so obviously the right thing to do on a 2-series if you want to use optiboot) is pretty much WHY there is a separate board listing for 2-series vs 0/1-series with Optiboot (and not without optiboot).

On ther 0/1-series, the best you can do is "ersatz reset" (putting an interrupt on LOW level on a pin and firing software reset in the ISR - there's an example included in the core with the megaTinyCore library and a bit more information about the software reset in the readme) if you don't want to disable UPDI entirely.

Whether the bootloader is in use has no bearing on how the pins behave when the bootloader is running (eg, if you put it on the alternate pins, your sketch will still default to the normal pins, and ir doesn't matter to the bootloader whether you use the same pair of pins or the alternate ones). The bootloader only runs immediately after hardware resets, and bootloader operation is always followed by a hardware reset (for Optiboot. This is not the case with some bootloaders, a fact which has been the cause of many issues over the years...). If you want it to work on the same pins as the serial port, if you bootloaded with the default pin option selected, and your sketch doesn't call Serial.swap(), that's what you get.

tinyAVR 0/1-series parts only have a single serial port, Serial.

tinyAVR 2-serties parts have a second serial port, which has it's own two sets of pins, named Serial1. Though it's default pins are the same as the first serial port's alternate pins! (nothing in the core prevents you from trying to start them both on the same pins at the same time either)

Worth noting that one of the main reasons I don't use optiboot much is that it uses the same pins for upload as the default serial pins. That means the only serial terminal you can use without having to manually disconnect before each upload is the arduino serial monitor, which is unspeakably bad. I generally develop with 1 serial adapter for UPDI programming and the other on the serial port, so I can leave that connected in hTerm (a much better serial terminal - designed by an embedded systems guy so it has the features we need,, which is really a rather different set of features than what normal folks seem to care about) while uploading sketches through UPDI.

[dattasaurabh82]

@SpenceKonde Thanks for taking time to explain and with a sense of humor 😂. In short, I will go with your "2 serial adapter method", as it also suites my current situation.

[SpenceKonde]

Yah, that's what pretty much everyone does when they absorb what the reset pin situation means.

IMHO,. the bootloader isn't worth it on most parts even with a normal reset pin. . The reason it is so much better for the Uno/nano/etc is that ISP programming of classic AVRs occupies so many important pins

it is also a lot less unpleasant to program something using UPDI than it is to use ISP >.>

Reopening because the bug that initially prompted this is not corrected. and it never will; be if the issue is closed.

[SpenceKonde]

That bug should be sorted in 2.4.0 - upload using programmer doesn;'t work for bootloader configurations and gives an error to that effect.