Attiny1616 Clock / delay() Problem

Projects Programming
1

I've got a custom designed PCB with an Attiny1616 MCU. Since this is my first time using this chip, I've included a test LED to do an initial blink test to verify I can upload code to the chip and it's running as intended.
The code I'm uploadings looks as follows:

void setup() 
{
  pinMode(PIN_PB5, OUTPUT);
}

void loop() 
{
  digitalWrite(PIN_PB5, HIGH);
  delay(1000);
  digitalWrite(PIN_PB5, LOW);
  delay(1000);
}

Here comes the issue: When running this code, the LED noticeably flickers on an off multiple times a second. After playing around with the delay value, I've landed on one that results in the LED switching state about every second: ~64700. This is an odd value, since it is 64.7 times higher than expected.
After testing some more things, I soldered an external 12MHz clock to the board. Now the delay value corresponding to 1 second is ~18800.

As for the setup: I'm using the Arduino IDE to set the fuses using the 'Burn Bootloader' option in the megaTinyCore Library. I've tested burning the bootloader with an Arduino Nano and jtag2updi and a dedicated CH340 USB to Serial converter and serialupdi. Both result in the same outcome. I've also tested multiple different clock speeds, ranging from 1MHz all the way up to 20MHz. No change is noticeable.
I'm flashing the code with VSCode and the PlatformIO extension with this configuration file:

[env:ATtiny1616]
platform = atmelmegaavr
framework = arduino

board = ATtiny1616

board_build.mcu = attiny1616
board_build.f_cpu = 16000000L
board_hardware.oscillator = internal

upload_protocol = serialupdi
upload_speed = 9600
monitor_speed = 9600

I have the feeling I don't understand something about how the Attiny1616 works which results in this error. Does anyone have a clue about why this is happening and how I could fix it?

2

Did you program the fuses?

3

Yes, like I mentioned I'm using the ArduinoIDE's 'Burn Bootloader' option and verified them with avrdude. They are the correct values.

4

For what values, what clock selection, and what clock circuit?

Please post the information required to make sense out of your question. Instructions are given in the "How to get the best out of this forum" post, linked at the head of every forum category.

5

Okay then. All I can tell you is that your sketch loaded into an ATtiny1616 here, blinked at the expected rate. So I still suspect that the fuses aren't programmed correctly. But since you're sure that they are, I have nothing more to offer. Good luck.

6

Try to use different pin than PB5 for the output whether the same issue persist. Looking into datasheet it seems PB5 pin can have alternative CLKOUT function. You might unintentionally activated this function.

7

Here are the fuses for the following settings:

image
image752×689 18.4 KB

PS C:\Users\Oliver> avrdude -v -p t1616 -P COM6 -c serialupdi -U fuses:r:-:b
Avrdude version 8.0
Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

System wide configuration file is C:\Programs\avrdude-v8.0-windows-x64\avrdude.conf

Using port            : COM6
Using programmer      : serialupdi
AVR part              : ATtiny1616
Programming modes     : SPM, UPDI
Programmer type       : serialupdi
Description           : SerialUPDI
NVM type 0: 16-bit, page oriented write
Entering NVM programming mode
Chip silicon revision: 0.1

AVR device initialized and ready to accept instructions
Device signature = 1E 94 21 (ATtiny1616)
Reading fuses memory ...
Writing 10 bytes to output file <stdout>
0b0,0b0,0b1,0b11111111,0b0,0b11000100,0b100,0b0,0b10,0b11111111
Leaving NVM programming mode

Avrdude done.  Thank you.
8

Good catch, I've now tried using pin PA4, which according to the datasheet does not have any special function, however the same thing still happens.

9

I've gone ahead and posted the fuses. I'm with you that it seemed like the fuses were programmed wrong, however to the best of my knowledge they appear to match what was set in the ArduinoIDE and the factor 64.7 also seems rather odd to me.

10

What happens if you burn your blink sketch directly with your Nano and selecting no bootloader instead of Optiboot?

I start to suspect your PlatformIO IDE installation in combination with Megatinycore.

I read here that burn bootloader is not supported for Megatinycore in PlatformIO.

You could try and install a second portable Arduino IDE on your PC and add Megatinycore to that. That last thing is a bit more complicated these days as the security certificate of drazzy.com has expired (again).
See here for a workaround

11

Wow, this actually works. I uploaded it via my dedicated programmer. I've read over that before but my brain must have went "megaTinyCore and PIO work great together..., huh, that's not my issue".
As I'm still relatively unexperienced with external programmers I've got a question:
The programmer just has a dedicated CH340G chip on it that handles the USB->Serial, and with a diode and resistor I'm 'converting' that signal into UPDI for the Attiny. I've got a CH340N connected to UPDI on my board. Why can I not upload code via that chip? What's different to connecting a wire from an external programmer to using the one on my PCB?

12

How is that connected? diode between RX and TX of the CH340 and what value series resistor? And then you need to program with the "no bootloader" option.

Basically you have your tweaked serial adapter then complete on your board.

13

I've tried a couple of configurations. The first one I tried was a 1k resistor between TXD and RXD of the CH340N, as seen here. I have also tried a 4.7k resistor between them and a schottky diode with it's cathode pointing towards the RXD pin and it's anode connected to a 470 ohm resistor, who's other side was connected to the TXD pin of the CH340N and the UPDI pin of the Attiny1616, like here.
None of these configurations worked for me. I did select the Attiny1616 without the Optiboot bootloader in the megaTinyCore when attempting to program the chip.

14

You have your diode direction wired incorrect.

5171b6bece395ff53c000000-1429020409
5171b6bece395ff53c000000-1429020409454×176 2.06 KB

15

Oh, sorry I mixed up the two pins. The cathode is connected to the TXD pin.
Edit / Update: I just tried uploading some code again with the Diode / 470 Ohm configuration and it now worked. I might have been too tired yesterday and did something wrong. Thank you for the quick replies and help!
Edit 2: I just tried uploading again but now it failed. After some more attempts it seems that uploading only works intermittently.

16

I'd check your power circuit if it has all the required decoupling caps. The CH340 seems to have some different requirements if it is fed 5V vs 3.3V. Read about the V3 pin.

See datasheet
CH340 datasheet.PDF (213.6 KB)

maybe uploading with a lower UPDI baudrate works more stable. Though the CH340 should support even the turbo speed option.

17

I checked my power circuit and could verify that I had a .1uF cap connected to VCC. VCC was also connected to 3V3, however the Attiny is being powered by 5V and the datasheet mentions that no circuits connected to the CH340N should exeed 3.3 volts when it is powered by 3.3 volts. I would guess this could be where my issue comes from, but since it is only an intermittent issue I will update it on my next revision and continue working on the circuit.
If you don't think that this is related, please let me know, otherwise I don't have any more issues and I thank you for your help.

18

Both Attiny and CH340 should be powered with the same voltage to have a solid identification of the High and Low levels of the UPDI signal.

19

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.