ATtiny84 running at 1/8th speed - something wrong with my platformio.ini?

PlatformIO IDE
, ,
1

SUMMARY:
My ATtiny84 is running at 1/8th speed, delay(1000); takes about eight seconds, and changing the fuses and other flags in platformio.ini seems to have no affect. Thoughts why?

DETAIL:
I’m uploading to an ATtiny84 using an Arduino Uno as a programmer. Relatively basic setup.

No matter what I do though, I can’t seem to get my clock speed right. I’m guessing it’s something wrong with the fuses or CPU but, I’m at a loss.

It’s running at 1/8th speed, so clearly 1MHz vs 8MHz is at issue here, but changing fuses seems to have no affect. Note that I can’t set f_cpu to 1000000L because the FastLED library requires a higher clock speed and won’t compile.

Here’s my platformio.ini:

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env:attiny84]
platform = atmelavr
board = attiny84
framework = arduino
upload_protocol = custom
upload_speed = 19200
upload_flags = 
	-C
	${platformio.packages_dir}/tool-avrdude/avrdude.conf
	-p
	$BOARD_MCU
	-P
	$UPLOAD_PORT
	-b
	$UPLOAD_SPEED
	-c
	stk500v1
upload_command = avrdude $UPLOAD_FLAGS -U flash:w:$SOURCE:i
	-U lock:w:0xFF:m
board_build.f_cpu = 8000000L
build_unflags = -DCLOCK_SOURCE=6
build_flags = -DCLOCK_SOURCE=0
board_fuses.lfuse = 0xE2
; board_fuses.hfuse = 0xDC
; board_fuses.lfuse = 0x62
board_fuses.hfuse = 0xDF
board_fuses.efuse = 0xFF
lib_deps = 
	fastled/FastLED@^3.6.0
	mathertel/RotaryEncoder@^1.5.3
	fabriziop/EEWL@^0.7.0

The project itself is open source. If you want to look at any other code, here’s the repo. Here’s the src folder commit as of the time of this writing. I do my best, but no promises on legibility :wink:

I’ve tried swapping out the fuses, with the flags commented above, and also played around with a number of other configurations using the AVR Fuse Calculator.

Bonus related issue: running “Set Fuses” directly (either the PIO menu or by command line) doesn’t work either, hitting me with an error message:

avrdude: no programmer has been specified on the command line or the config file
         Specify a programmer using the -c option and try again

Even though under upload flags I clearly have -c set to stk500v1. For giggles I tried moving the -c flag to the top of the listed upload flags, and the error turned into avrdude: ser_open(): can't open device "-b": The system cannot find the file specified.

I’m uh… in over my head here :sweat_smile:

I’ve tested on a handful of fresh ATtiny84 chips, and tried swapping out the cable, to no effect. And besides, the upload itself WORKS, it’s just at the wrong clock speed - which also makes it impossible to use FastLED, as NeoPixel / WS2812B communication requires fairly precise timing. I’m also using rotary encoders that need careful timing too… yeah. It’s been a long day.

Any idea why this isn’t working?

Thanks in advance!

2

Let’s try and folllow the documentation (https://docs.platformio.org/en/latest/platforms/atmelavr.html#fuses-programming) exactly. First of all, I’ll assume you want the “Internal 8MHz RC, no divide by 8” to get 8MHz. Rest at default.

grafik
grafik834×344 23.8 KB

Create a new environment in the platformio.ini as

[env:custom_fuses]
platform = atmelavr
framework = arduino
board = attiny84
upload_protocol = stk500v1
upload_speed = 19200
board_fuses.lfuse = 0xE2
board_fuses.hfuse = 0xDF
board_fuses.efuse = 0xFF
upload_flags =
    -PCOM15
    -b$UPLOAD_SPEED
    -e

Change the “COM15” above to match your programer’s actual serial port (look in the Windows device manager or ls /dev/tty*).

Then open a PlatformIO core CLI and execute

pio run -e custom_fuses -t fuses -v

What does that output?

1 Like
3

Hello! Apologies for the slow reply.

This comment put me on the right track to resolving the problem :slight_smile:

The crux of the issue was that I was using AUTO port detection. Selecting the specific port (in my case, COM6) allowed everything to work perfectly fine, upload, functionality, etc.

Nooooo clue why that’s the case, especially since autodetection of the COM port has worked perfectly fine otherwise. Tbh this is a bit irksome since I swap peripherals on my device a lot and the COM port changes fairly often.

Idk if this is a known issue or if there’s a fix available to prevent auto detection from affecting other values in the .ini, but if so, I’d love to be able to safely use it again.

But hey, at least it works :slight_smile: thank you @maxgerhardt for putting me on the right path!