1.8.10 ISSUES


Like the title says, sometimes the arduino ide hangs/freezes my rpi when cooking specific sketches.

Most sketches are no problem but some are. I tried to figure out what is causing it but i am not able to get grip on it.

I opened the task manager while compiling and i figured as soon as i compile the sketch a lot of the same processes called “cc1plus” pop up and then the screen freezes and vnc connection is lost.

I have to pull the power plug to reboot the rpi.

Arduino IDE 1.8.8 arm version
Raspbian stretch with desktop and recommended software.

The code giving the trouble is this example sketch

Code to big to place in code tags, the link wil bring you to the raw code in your webbrowser. Ino file will be attached too.

Hopefully anybody knows a solution here

MPU6050_DMP6.ino (16.1 KB)

Connect a monitor to the HDMI port and see if anything useful is shown before the Pi freezes. You might try opening a terminal window and tail -f /var/log/syslog which might show error messages before the freeze.

You might have a bad power supply. Check the power requirements for your Pi. If you see a yellow flashing lightning bolt on the right upper side of the desktop, it means the power supply is not good enough for the Pi.

Thanks for the reply.

I can not connect a monitor since i dont have one.

Will give the terminal command a try later today.

The powersupply is sufficient for sure. 5v up to 5amps

Will report back later

So You are using Arduino IDE on your Raspberry Pi? Interesting. Im fairly new to all of this and im overwhelmed at the possibilities. I have many projects in mind but Im stalled right now using my esp8266 and wemos d1 mini lite. My UNO works fine with the IDE, but when I use the other boards using the standard libraries, I get compilation errors.

Compiling errors are diffrent than hanging a OS.

You can copy your error and create a new topic on your issue. Might sound stupid but have you changed your board to the appropriate one? Won't be the first one trying to compile esp sketch with uno board selected instead of the esp.

Have you had any luck with this?

I'm having the same issue here. I'm using the arduino IDE (1.8.9 for Linux ARM 32bit) downloaded from arduino.cc, when I compile a sketch the status bar goes to 100%, then the processor usage also goes to 100%, and the whole Pi freezes solid. Red and green lights are on solid and CPU use is at 100% only way out is to powercycle.

IDE 1.8.9 works fine on a RPi 3+. If using a slow Pi such as the Pi Zero or old Pi with only 1 CPU, it may take a long time to compile.

I'm not exactly sure what's going on, but reverting to the 1.8.5 version of the ARM arduino IDE resolves it and that's what I've done for this family of chips.

It appears to be a combination of ARM Arduino IDE>1.8.5 and the ESP8266 libs. IDE v1.8.9 works great on ARM for BB uproc and every arduino varient I've thrown at it (nano, pro mini, uno, etc.).

Also, v1.8.9 on either 32 or 64 bit Intel works fine for all including ESP8266.

Running top when I fire off a compile for a D1 mini in IDE >1.8.5 I see it go into an absolute forkfest, spawning cc1plus processes until Virtual Memory is exhausted and the Pi hangs. It's like OOM never has a chance.

I know the rPi is not the optimal place to run the IDE but I have sensors in isolated places and it's nice to be able to hook a wifi enabled pi to a cell phone battery charger, cable it up, and toss IDE's X back to somewhere comfortable while I debug or update a remote sensor in place.

I've duplicated it on Raspian Stretch and Buster, IDE versions 1.8.7-9. Again, ARM only. Intel works fine. To duplicate you can take the blink sketch and simply include th3 8266 libs. Blink compiles fine without the includes, goes nuts with, e.g.:

* Blink
* Turns on the onboard LED on for one second, then off for one second, repeatedly.
* This uses delay() to pause between LED toggles.

#include    // Causes recursive fork during compile

void setup() {
 pinMode(BUILTIN_LED, OUTPUT);  // initialize onboard LED as output

void loop() {
 digitalWrite(BUILTIN_LED, HIGH);  // turn on LED with voltage HIGH
 delay(1000);                      // wait one second
 digitalWrite(BUILTIN_LED, LOW);   // turn off LED with voltage LOW
 delay(1000);                      // wait one second

If I'm running top in another window, I see:

  46 root      20   0       0      0      0 R  15.7   0.0   0:00.69 kswapd0
 816 leem      20   0  444416 115748   5524 S  12.5  12.2   0:47.06 java
1196 leem      20   0   35672  25336   5412 R  12.5   2.7   0:01.04 cc1plus
1089 leem      20   0   33624  24836   5348 R  10.2   2.6   0:01.08 cc1plus
1104 leem      20   0   33504  24472   5264 R  10.2   2.6   0:01.04 cc1plus
1062 leem      20   0   35608  25500   5348 R   9.9   2.7   0:01.15 cc1plus

If any devs are reading thank you so much for this GREAT product! I'm a financial contributor and use the heck out of it. While I edit code remotely I love the simplicity of board, library and option management the IDE provides. It so beats Makefiles and scripted up avrdude calls. Awesome work.



Awesome I will try to go back to 1.8.5 and see if this solves the problem for me. Indeed the problem occurred when I had the ESP library’s installed. Thank you for troubleshooting this and reporting back!

My sensor source code is shared to all systems over NFS and I use that as my 'Sketchbook location' and install diff versions of the IDE from tarball then call as needed based on node type on the table.

leem@pi4:~ $ ls /opt
arduino-1.8.5  arduino-1.8.9  pigpio  vc
leem@pi4:~ $  alias | grep ard
alias arduino='/opt/arduino-1.8.9/arduino >/tmp/ard.out 2>&1 &'
alias arduino-wifi='/opt/arduino-1.8.5/arduino >/tmp/ard.out 2>&1 &'
leem@pi4:~ $

This issue has been bugging me for a bit. I assumed I was doing something stupid/unexpected. I finally googled it today and found your post. I hope 1.8.5 works for you too!



RPi 3B+, Linux 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l, Arduino IDE 1.8.9

Parallel builds started in release 1.8.6. Parallel builds use lots of CPU AND lots of RAM. The freeze may be due to lack of swap space. Expanding the swap file size may help. I made this change to build another project. But it should help with all parallel builds including the Arduino IDE > 1.8.5.


The Blink example for ESP8266 builds on my Pi3B+ stretch with a 2GB swap. The Pi appears to freeze for about 1 minute but it regains conciousness and the build finishes. It would be nice to have a switch to limit the number parallel builds or have the IDE scale to the number CPUs. I have seen the load average go as high as 35!

It might be faster to build using 1.8.5 (no parallel builds and no swapping) versus 1.8.9 (parallel builds and swapping). An RPi4 with 4GB of RAM might be better at parallel builds.

Also to rule out CPU throttling, run the following in a terminal window. If the throttled result is ever non-zero, there is an under voltage or over heating problem. If the temp > 60 degrees C, the CPU speed will be throttled back to reduce heat and current. In older CPUs, the throttling does not occur until the temp > 80 deg C. The CPU will also be throttled if the power supply voltage drops too low.

while true
   vcgencmd measure_clock arm
   vcgencmd measure_temp
   vcgencmd get_throttled
   sleep 1

Thank you gbafamily!

That explains a LOT. And yes swapping to SDRAM card will appear hung for sure! I even exacerbated the issue during testing with swapoff -a to see if OOM killer got invoked. It did but chose poorly. Heh..

I get it now. Ideally there is an option to to the arduino IDE to single-thread that stage or a LEAST limit number of parallel builds to number cores available., Wall time is not an issue for me in this environment. Perhaps it's a simple as exporting a the same ENV var to the C compiler. I'll have to look.

Thank you again.


Followups here: https://forum.arduino.cc/index.php?topic=625007.0

IDE 1.8.10 fixes the Raspberry Pi freezing problem at least in my testing.

My Arduino clones have been fine with my WinXp machine using Arduino IDE 1.6.11. And now it just started acting up, not compiling sketches that I know compile fine.

So...Is there any reason not to upgrade to the latest IDE version (1.8.10)? It has been a while since I used Arduino, so I don't remember if I had 1.6.11 for a reason or if I just never upgraded.

There can be a multitude of reasons something will not compile.
Given you machines OS is obsolete you could possibly run some minor issues.
Recently retired my last XP machine so cannot help much there.
However you have not given us any clues that could help you fix it.

Most of us hold off on brand spanking new releases until we get a few reports in.
Given how recently 1.8.10 was put out my own view is to wait a week or two.

I have had no issues myself with 1.8.5 which seemed quite stable under win 7, 8, 10.


Not sure what clues I can provide. It was working just fine until a couple hours ago, and now I can't compile/upload anything. I've not rebooted yet, which will likely fix it.

But here's a weird observation: I installed the Optiboot onto one of these Nano clones via my Linux Mint machine. When I then connect the Nano directly to the USB port the onboard LED blinks a little. But when I connect this same Nano to the USB port of my WinXP machine the LED will do a much longer LED blink sequence.

And I don't need the latest Arduino, I can install 1.8.5. My question was more about whether there is a reason to have 1.6 vs. 1.8.

There is usually some sort of error in the lower console.
Those provide the best clues to people who want to help.

Not sure why the blink frequency would change without actually changing the sketch itself unless there was some difference in the voltage the USB ports provide and even then I would not really expect it to be so noticable.

You could of course just download 1.8.10 as the ZIP and run it in portable mode to see if it is any better.

Also when was the last time you did a decent clean up of the XP box.
Seen crud cause odd issues on win 98 to XP
May or may not help !


Rebooting the XP machine fixed it. I bet there's some issue with the USB serial driver. The long LED blink sequence seems to be the OS doing some USB com stuff. If I just press the reset button on the Nano it will only do the same short blink sequence as on the Linux machine.

Always worth a restart before worrying about issues. You may still want to have a go at a portable install to get some of the newer features.

Glad you are running.