Difference between version 1.5.2 and 2.0.0-dev in Proteus

[AlessGhitHub]

Hello, I made this simple program with the ATiny85 option (in the bootloader) 8MHz internal. I tested it on proteus because I don't have the physical hardware here. Worked perfectly.
I'm using Arduino IDE 2.1.1 and ATtinyCore 1.5.2.

Then only I changed ATtiny core from version 1.5.2 to 2.0.0-dev. It compiled normally and I simulated it in proteus and it doesn't work. You receive the following message from the image.

I saw that in version 1.5.2 the OSCCAL register was at 0x80 and with version 2.0.0-dev it is at 0x00.

Another thing that occurred to me, but I solved it manually by compiling it, is that after complicating the code and when I go to export the hex file, the Arduino IDE does not copy it to the project folder.

`
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
delay(100);
}

void loop() {
// put your main code here, to run repeatedly:
if (Serial.available()) {
String receivedString = Serial.readString();

if (receivedString == "Hello") {
Serial.println("World!!!");
}
}
}
`

[AlessGhitHub]

Is this difference between these two kernel versions using the same program code something in the kernel or is it something in proteus causing it?

[SpenceKonde]

While there may very well be bugs in the core, any behavior with this or any of my cores will set the "difficulty of simulating" dial to the maximum

The IDE in it's stock form with the stock core gets you .hex in sketch folder only upon export compiled binary. If using one of my cores, you also get a .map and .lst (memory map, assembly listing) file there, and the filenames of the exported files should all have a string appended to the sketch name uniquely identifying all menu options which are expected to alter the compiled binary (I think this is almost every option here, except BOD stuff? But on modern AVRs (DxC/mTC), there are like 3-4 menus that only control fuses, and the compiler output is unchanged, these options arent included in the filenames (modern AVRs have 7-8 fusebytes and only 2 of them are ever dangerous - the one that disables UPDI (since HV UPDI programmers are rare) and the one that controls BOD (which could be set to a voltage higher than the maximum voltage for other parts soldered to the same board; this as I understand is unrecoverable without desoldering parts, and a bunch of settings handled in fuses that may not change the compiler output. In contrast, on a classic AVR, a wrong value on any fu

Anyway what's happening in proteus is that it doesn't simulate some of the more obscure functionality (I'm not even sure if what I;'m doing is documented for the t85, but it's reading a value that was set during factory testing. Proteus has no idea what that value is, because it;'s a simulation and not a physical chip that has been calibrated. It's assumptions are bad. That piece of code is present on the tiny85 because so many of them use the digispark bootloader, which will leave the osccal set to 8.25 MHz with PLL clock for 16.5 which allows reliable vUSB (if we stretch what we mean by reliable). If a non-digispark-related speed is used, we load the factory calibration (this is not simulated correctly and alwatys initially reads as zero. Then we read the factory calibration from the sigrow using the may-or-may-not-be-documented (it seems to work everywhere, but only about 50% of parts document it, and many of the headers don't define SIGRD or a few other relevant constants). Proteus also has no idea what this is but returns 0x80. This is a drastic difference between normal/correct behavior - unless the bootloader changed it, the startup OSCCAL will be the factory programmed cal. But proteus gives one as 0x00 and the other as 0x80, but you're not supposed to make abrupt changes to OSCCAL, because it can crash the chip. That is what leads to the warning about the sharp change in frequency. But this worry is not a concern because extensive tests particularly by the micronucleus people who pioneered this technique as well as my own work, there is in fact a simple way to prevent the glitches from changing the OSCCAL. Which we use:

Just follow each write to the OSCCAL register immediately with a NOP, and the problems don't manifest. AVR fetches one instruction while executing another (this is why anything that changes flow control will always take an extra cycle to jump!). The problem happens when, while executing one instruction, and you give a great big shove to OSCCAL, will, for that clock cycle, violate the clock variation cycle-to-cycle spec.

The selfpgmen error also seems to be spurious because it doesn't understand the command we use to read the factory cal value, and hence we already used the selfprgmen bit.