Attiny13 delay function issue

[dev-board-tech]

My setup is:
uC = ATTiny13A
Override clock sources = Internal oscillator 600Khz
Override frequency = Default
Brown out detection = 2.7V
Use Bootloader = No
Processor Speed = 4.8Mhz Internal oscillator
Mills, Tone support = Mills available, No Tone
Link time optimization = LTO Enabled
Mills accurate = Default
Print support = Bin only
Serial support = Half duplex (Read + Write)
Processor support = Attiny13a

I use Arduino IDE 2.3.4

The issue is that at compilation time instead of being consistent compiling the delay routine for 600Khz, sometime compile it as for 4.8Mhz and sometime for 600Khz, is randomly alternating between the two but only when changes are made into the sketch source code.

Maybe F_CPU is defined twice somewhere, once for 600Khz and once for 4.8Mhz, and depending of the order of compilation will use one or the other.

The fuses are written correctly, as Internal oscillator 4.8Mhz and DIV8 enabled that gives a 600Khz core frequency.

Anyway, thank you for your work, is very useful and let me run from using a VM with windows on it.

[sleemanj]

Without two codes, one working and one not, and how you are determining the fault, there is not much to go on, but I do not recall any way in which F_CPU even could be set twice, let alone randomly, or that it would only be "random" at some certain F_CPU It is perhaps misdiagnosis of another fault (eg oom, non-volatile read, interrupt behavior etc). Note that delayMicroseconds will return immediately below a minimum value defined by each clock speed, that is, if the delay requested calculates longer than the overhead for measuring delays, it will give up.

[dev-board-tech]

The application Is very simple:
A bit-bang DHT22 driver, a bit-bang Usart TX and some delays, that's all.

I attach the final code, ehh, not quite final, on what you can see is nothing special, but I have that behavior if I use delay and DelayMicroseconds, of course when the behavior was shown there was no interrupt enabled, was nothing to interfere with the delay routine.

I implemented custom delay into the sketch as of now.

What I observed is that when is compiling for 4.8Mhz the resulted binary is a little bit bigger that if is compiling for the correct frequency 600Khz.

HumTempSensor_Arduino_Attiny13A.zip

[dev-board-tech]

Open an example for Attiny13 and put the below lines into the main file

#define XSTR(x) STR(x)
#define STR(x) #x
#pragma message XSTR(F_CPU)

You can see that at first building after any source code change will show that F_CPU is 4.8Mhz instead of 600Khz, after fist several retry builds, will show the correct F_CPU frequency 600Khz as long as there is no source code changed, but after the build that show the correct frequency will build it correctly till you change the source code.

At last in Arduino 2.3.4...

But if you use Arduino 1.6.x maybe this issue is not showing...

If you have other version of Arduino and you don't have this issue please tell me, maybe is an Arduino issue and not the F_CPU definition.

[sleemanj]

Can not reproduce in 1.8.19, selecting 600 clock source or frequency reliably produces F_CPU 600000L Have never looked at 2.x, will do at some point. Suggest you make sure that your selections for both clock source and frequency make sense, and maybe that you don't have two windows open, perhaps Arduino IDE gets confused if you do.

[sleemanj]

Ok I have confirmed more or less this in 2.x

The reason is no doubt that the Arduino IDE is not respecting the order of the various settings menus, so later ones (as I defined them) are no longer guaranteed to override earlier ones.

As we see, 2.x on the left, 1.x on the right, completely different ordering, only the correct ordering will function correctly

I imagine this might be a known problem with 2.x, but as it's been out for quite some time, you'd think it would have been fixed if it was going to be fixed. Perhaps there is a bug report under Arduino's repositories for it somewhere.

[sleemanj]

This may be the issue...
arduino/arduino-ide#2036

[sleemanj]

Yes I'm fairly certain that is that, or this arduino/arduino-cli#2018 or this arduino/arduino-cli#2209

Whatever the case, this is an Arduino software issue, and I don't see a way to fix it unfortunately. I recommend to use Arduino IDE 1.8.x which behave correctly.

[dev-board-tech]

Yeah, seems to be the Arduino IDE 2.x.x at fault, Is the first time I seen this issue, is good to let it open, will be useful for those that will have the same issue to know that the issue is in Arduino IDE 2.x.x and not current repo.