I'm not sure how to describe this since I don't know the cause but here is what I experienced.
First, a Mini Pro sketch that I have compiled and used for years failed to run properly after flashing. No errors or warnings from the compiler, the code just wasn't running right. Since I had print statements for debugging I opened the serial monitor only to see gibberish (reverse ? marks) scrolling ad infinitum. I commented out my entire Loop, then Setup would run to a point where it called a library function to initialize an Si5351 clock generator (which I've used many times) and by inserting print statements to "divide and conquer" I could identify exactly in the library where it was failing. I deleted all copies of that library and re-installed the latest version fresh, but the behavior was the same. Closing and re-opening the IDE, swapping serial interfaces, etc had no effect.
Finally I copied the same sketch over to a different PC and installed the needed libraries. The same code compiled and ran the hardware perfectly. I compared the build folders as identified by the compiler on each PC and they are definitely not the same. So it seems that something in either one of the libraries I'm using or the IDE (ver. 1.8.13) that I'm using on the first PC has been corrupted and is producing bad code despite the lack of compiler messages. I could envision stack corruption such as might happen if a function was called using the wrong header, but I can't envision how that might have happened. But since the sketch works correctly on a different IDE/PC the cause has to be something specific to the first PC.
The IDE on the 2nd PC where the compilation worked correctly is actually older: 1.8.9.
I'm thinking I should updated the IDE on the first PC, I see 1.8.19 is the current release and v. 2.0 is also available but given my uncertainty I'm not sure it's a good time to try something that is not fully stable.
I just wanted to post this in the even anyone with more experience might have suggestions as to what the cause of this odd problem is and what would be the best course to try to get my development PC/IDE working right again. Thanks!
Bob
It would not be useful to show my code because it compiles and runs fine on a different PC/IDE. But these two screen caps show the problem.
First: On the left is a snippet from the stable Etherkit si5351.cpp library showing the print statements I added for debugging. Note only the "device ready" print is enabled and on the right you can see the correct expected serial monitor screen display:
Next: I made one edit to the source, removing the comments for the first print debug line immediately after the library writes the crystal load data to the device register via I2C. Note that I2C communications has already been tested because the first screen cap above shows that "Device Ready" was displayed. But as the serial monitor screen on the right show, after the call to the library function the display goes nuts, scrolling the reverse-? symbol so fast I couldn't capture the start of it. But this scrolll will continue ad infinitum.
To repeat, the only difference between these two screencaps was the enabling of the Serial.println immediately following the library function call. I would add that the code size (.hex file) is different than the file size created by the 2nd PC which produces good code. And because the hardware has an OLED display I can also visually see that it does not get past this point in execution - whatever is going on takes the CPU off into never-never land.
Just to prove there is nothing wrong with the library function, here is a similar screencap from an example provided by the library author which uses the same exact function, and in fact it executes properly with the expected screen display on the right:
Regarding baud rate, all the Serial.println debugging in my sketch is done at 9600 baud. The last screen from the example was set to 57600 baud by the author and I left it that way, so of course I had to change the serial monitor to match. But this is not as simple as a baud rate problem.
Whatever is going on, it is unique because the same library function will execute properly in a different sketch. That's what makes me suspect that the IDE is perhaps associating the wrong code with the si5351.h header causing stack corruption.
Copying my sketch over to a different PC with an older version of the IDE will compile and flash the sketch perfectly. What I'm trying to figure out is how to fix whatever is wrong on the first PC/IDE, thanks.
Did you always use the same version of the compiler for that?
Is that with compiler warnings set to ALL in file -> preferences?
You're using two different versions of the IDE; what are the versions of the compiler (gcc)? You can determine the versions e.g. by enabling verbose output during compilation and search for avr-g++.
Different compiler versions might very well result in different 'executables'. And different executables might exhibit different behaviour if there are bugs in your code. So posting code is always useful.
One reason for reverse-? can be a baudrate mismatch; do your serial monitor settings match the settings in the sketch. It does look OK though as you have readable text in your screenshot. There is an autoscroll checkbox in the left bottom of your serial monitor; that will stop the scrolling if you remove the tick so you can catch the beginning.
The reason I ask for code is to compile it in different IDE versions, to see if I can replicate the error.
Pictures of code are unusable! It's like taking a picture of your car to a mechanic and asking them to diagnose/fix it.
