About a year ago I was working on a project for which I used this tutorial (following the "minimal circuit" instructions) to bootload and program an ATMega328P as the microcontroller of a PCB using the 8MHz internal clock rather than an external oscillator. In accordance with the instructions I downloaded the "breadboard-1-6-x.zip" hardware configuration necessary to provide the right board setting option in the IDE Tools dropdown. I was using Arduino IDE version 1.6.7 at the time.
Everything worked great.
Then last month I updated my Macbook to Mojave and 1.6.7 stopped working properly. Like I couldn't even upload the "Blink" sketch. So I updated to the newest IDE, 1.8.9. Problem solved for my other projects.
Now that I am trying to make some edits to my barebones Arduino PCB project code, I'm getting really weird errors. Sometimes the code just hangs. When I add some Serial.println("debug x") statements, I can get it to run pretty normally (only problem is that certain Serial.print statements get cut-off before fully printing). This makes me think that there may be a problem with the chip's timing, where making it slow down with added prints somehow helps it overcome whatever is causing it to hang. Once I get it working, if I comment out any one of my added Serial.print statements, it starts to hang again, so the number/time they take seems important.
My assumption is that it is due to my hardware configuration for the 8MHz internal clock board being written for IDE 1.6.x and not knowing how to update it for 1.8.9.
My main questions are:
Does the hardware configuration version mismatch make sense as the cause? Does anyone know how to update that hardware configuration?
Could it be a problem with SDFat and the new IDE? (Hangs and cutoff Serial.prints all occur after file.print() statements)
I assume it is a problem with the code somehow. But I'm confused why without changing anything except for the IDE version it would start acting so differently after running fine for 1 year. Unless it took some time for the memory corruption to happen.
sterretje:
This sounds like memory corruption due to the use of e.g. String (capital S) or writing outside the bounds of arrays.
After messing around with it some more I think this is likely the issue. I only use the String class for two objects in one function in setup, not even the loop, so I don't know how much affect that could have (maybe a lot, I honestly don't know enough to know).
BUT more interesting is that after changing a lot of Serial.println statements to Serial.println(F()) it started behaving MUCH more normally. Stopped hanging as frequently. Like I said before, I don't know enough about how memory works to really understand what this is doing, but I know it is related. For context the sketch uses 23314 bytes (75%) of program storage space. Global variables use 1650 bytes of dynamic memory. I;m currently trying to just make the sketch smaller to see if that keeps helping.
BJHenry:
Or it could be the missing decoupling capacitors, which aren't shown in that Playground example and so are often not put on the breadboard.
Oh! Even if this isn't it, I would love to know where those should go to make sure I've got it wired right
pyfi:
I only use the String class for two objects in one function in setup, not even the loop, so I don't know how much affect that could have (maybe a lot, I honestly don't know enough to know).
Even if it's not causing memory fragmentation, using String can use a lot of memory so it might be worth trying to convert that code to not use String anyway.
pyfi:
I would love to know where those should go to make sure I've got it wired right
Put a 0.1 uF capacitor on each of the power lines as close as possible to the chip, as shown in this picture:
