Serial Programmer unidentified

[aklassen117]

I followed the Serial programming instructions, however I am trying to use the CP2102 (its what I currently have in hand). I set the baud rate 57600, and wired according to the schematic you provided. Issue is the ide is saying that a programmer is required to upload.

Any ideas?

[SpenceKonde]

Did you select one from tools -> Programmers? for serial adapter as UPDI it's SerialUPDI

[aklassen117]

Yes, so I just read that it is not set up to work on the 2.0.x software. So I just downgraded and I am getting new errors seen below.

So I set the programming device to "SerialUPDI - SLOW: 57600 baud" the the board and chip have both been selected as ATiny402. I double checked to make sure that the correct port was selected. All other settings were left as default. I did try lowering the clock speed below 5MHz but it didn't change anything.

Hardware: I am using the CP2102 dev module from silicon labs. It is providing 3.3V to the 402. The TX pin is tied to the RX/UPDI pins though a 4.7K resistor. I did try using a switching diode as well as lowering the resistor value, however no change.

I'm going to set up the device with a new chip to see if that works (It's possible that mine is bricked), I am also getting a the Serial CH340 device to rule out the CP2102.

Does the 402 require some sort of bootloader? Its my understanding that the serial programming method is capable of programming to the device, however it can not change the fuses, is this correct (should require a HV programmer to set fuses)?

#define led 3

void setup() {
  // put your setup code here, to run once:
  pinMode(led,OUTPUT);
  digitalWrite(led,HIGH);
}

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

Error Message:

Arduino: 1.8.19 (Windows 10), Board: "ATtiny412/402/212/202, ATtiny402, 20 MHz internal, 1.8V (5 MHz or less), Disabled/Disabled, EEPROM retained, TCA0 (default on 402/202), 8ms, Master or Slave (saves flash and RAM), Default (doesn't print floats, 1.4k flash use), Disabled (recommended), No delay before window "opens""

Sketch uses 458 bytes (11%) of program storage space. Maximum is 4096 bytes.

Global variables use 10 bytes (3%) of dynamic memory, leaving 246 bytes for local variables. Maximum is 256 bytes.

SerialUPDI

UPDI programming for Arduino using a serial adapter

Based on pymcuprog, with significant modifications

By Quentin Bolsee and Spence Konde

Version 1.2.3 - Jan 2022

Using serial port COM15 at 57600 baud.

Target: attiny402

Set fuses: ['0:0b00000000', '2:0x02', '6:0x04', '7:0x00', '8:0x00']

Action: write

File: C:\Users\klassena\AppData\Local\Temp\arduino_build_265571/quik_LED.ino.hex

Traceback (most recent call last):

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5/tools/prog.py", line 286, in <module>

    main()

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5/tools/prog.py", line 128, in main

    return_code = pymcuprog_basic(args, fuses_dict)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5/tools/prog.py", line 201, in pymcuprog_basic

    args_start)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\pymcuprog_main.py", line 545, in _start_session

    backend.start_session(sessionconfig)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\backend.py", line 362, in start_session

    sessionconfig.interface_speed)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\programmer.py", line 83, in setup_device

    options=self.options)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\nvm.py", line 42, in get_nvm_access_provider

    accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\nvmserialupdi.py", line 54, in __init__

    self.avr = UpdiApplication(port, baud, self.dut)

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\serialupdi\application.py", line 79, in __init__

    datalink.init_datalink()

  File "C:\Users\klassena\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.5\tools\libs\pymcuprog\serialupdi\link.py", line 44, in init_datalink

    raise PymcuprogError("UPDI initialisation failed")

pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed

pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed

[SpenceKonde]

That I'm afraid is the something went wrong error. Could be anything from bad wiring to wrong port selected to resistors preinstalled on the CP2102 board (I know CH340's usually have them. What's the wiring on PA0 look like, it should be direct or through a series resistor not larger in value than 470 ohms, and there should be nothing capacitive connected to PA0, like an autoreset circuit (that's why my boards have a solder bridge jumper to enable that after bootloading

[aklassen117]

I have the the ground and 3.3V connected to the CP2102 board. PA0 is directry connected to the RX pin, and the TX pin is connected to PA0 through a 220 resistor. I tried removing the resistor and connecting directly and getting the same result. As far as I could see there is no on board resistor in series with the chip, unless the chip itself has a large input resistance I don't know about.

[SpenceKonde]

aaaaah!! No no, the resistor between tx and rx is 4.7k, or replace with a small signal diode with band towards Tx of the adapter. That sub-470 figure is what's allowable between PA0 of target and RX), between TX and RX must be 4.7k, unless there;s already resistance in series with TX on the board.

[SpenceKonde]

Closing issue as it does not represent a bug in the core.

[aklassen117]

Right, I started with a diode in place of the resistor (in the photo I uploaded above). When that didn't work I switched it to a 4.7k resistor. When that also failed I slowly lowered the resistance to the point were it was essentially shorted.

I also just connected a CH340 and repeated the process, I am getting the same errors. I am still using the same baud rate 57600, as I am having an issue figuring out how to get it to run at higher speeds.

[SpenceKonde]

Well, was the diode a small signal shottky diode? It needs to be for that to work.

One thing I've discovered is that UPDI as a protocol, on the tinyAVRs, is balanced on a knife edge in this sort of configuration.

The UPDI line's transmit function is the gimped 1/10th drive strength you get whenever using the pin that takes the HV reset pulse as I/O (ie, it's a worthless output - that's why they removed that feature from the more recent parts, I suspect.)

So what you need is: When TX is asserted, current can flow freely enough to be registered as a low on the target. When TX is high, since most adapters use totempole outputs, not open drain + pullup, the target is still able to assert a low, despite the shit pin driver.

If the resistance is too high or the drop across the diode between RX and TX is too high, the programmer can't pull the target's line low enough (it's fighting a standard pullup I think, like 35k ohm - the problem here isn't overpowering the pullup, but getting the voltage low enough to be below Vdd * 0.3 to be registered as a LOW.

If the resistance is too low (basically anything under 4k or so) or the diode has horrendous reverse leakage (I've seen only a few diodes with such ghastly reverse leakage that it might be a problem), the target won't be able to pull the UPDI line low.

If you put it on a digital scope you should be able to clearly see what's going on. Do a single trigger on the falling edge of the UPDI line and adjust the horizontal scale as needed to see multiple bytes being sent.

Under normal operation you will see both directions - but the highs and lows, and the shape of the curves will be different depending on whether target or programmer is the one talking, and if one of them looks pathological, that's a big hint.

Some adapters already have a resistor in series with TX - these require a lower resistance, or a diode be used.

A few adapters may have resistors in series with their RX. That's not good, because the impedance of the target's updi pin is so bloody high on tinyAVR it's of the same scale as that, and combined with the internal pullup on the serial adapter, it forms a three way voltage divider:

          serial adptr         Adapter                 target updi pin can be approximately modeled
          pullup                 series res.              as an ideal pin with resistor after it. 
Vcc----/\/\/\/\/\--------/\/\/\/\/\-----------/\/\/\/\/\---------
               ??? k                 ?????                      ~2k @ Vdd = 5V, 3.2k @ Vdd = 3v, 3.6k @ Vdd = 1.8 

Also, are you sure you have TX and RX the right way around? This is very easy to mess up because the standard doesn't make clear the nomenclature: If i have a pin marked TX - is that the TX pin of the device itself? Or the RX pin, marked TX because that's what should be connected to TX in the standard serial port use case.

In the Dx and Ex-series reset and updi were made different pins, and they gave up on making reset an output all together - it's now input only when used as I/~O~ and you put the HV pulse on there for HV programming. That lets them make UPDI into a normal pin with a normal drive strength.