Arduino YUN Serial Communications problem


I need to use the serial port to communicate between linux YUN and the arduino WITHOUT using the bridge. So I disabled the bridge like so

in /etc/inittab
#ttyATH0::askfirst:/bin/ash --login

Then on Arduino linux, I have my C program which runs automatically after the YUN boots, and it opens a serial port /dev/ttyATH0 like this

fd=open("/dev/ttyATH0", O_RW…)

sets the baud rate to 115200 (not shown)

then starts communicating with the arduino

The arduino program on the yun board is also set to 115200,


However after I flash the arduino program into the arduino Yun board, the YUN board wont boot up any longer.

However, if I simply change the arduino program to start at 300 baud instead of 115200 like so


The yun board boots up and runs fine.

Strange right… So I put arduino back to 115200, then the yun board no longer boots again, then I hook a scope to the serial pin, seems YUN is trying to communicate with the Arduino even though I disabled the bridge above. Seems if it cant communicate at 300 during power up, the whole yun board wont boot up completely, it just freezes there until it hears back from the arduino at 300.

This means even though the bridge is disabled as shown above (by removing the askfirst) , the linux side of yun is always trying to communicate with the arduino at power up even though its supposed to be disabled.

Anybody knows how to completely disable it?


See this demo which is in the Yun section of the Forum.



I'm still having problems accessing the serial port from linux C program running on the yun side.

I think something inside the OS is using the serial port still and interrupting the communications.

Since I don’t want to use the bridge, because I'm using my own serial communications using C language, I want to REMOVE THE BRIDGE COMPLETELY and everything related to it.

Except I still need the serial port dev/ttyATH0

during a build of the openwrt/yun linux OS I notice that its building the following

make[3] -C feeds/packages/arduino/uSDaemon compile make[3] -C feeds/packages/arduino/yun-conf compile make[3] -C feeds/packages/arduino/luci-app-arduino-webpanel compile make[3] -C feeds/packages/arduino/temboo compile make[3] -C feeds/packages/lang/python-json compile make[3] -C feeds/packages/arduino/cpu-mcu-bridge compile make[3] -C feeds/packages/arduino/spacebrew compile make[3] -C feeds/packages/utils/avrdude compile make[3] -C feeds/packages/arduino/yun-scripts compile make[3] -C feeds/packages/utils/triggerhappy compile

does anybody know which one of these I can remove since I dont need to use the bridge or the web bridge interface, I just need dev/ttyATH0?


rouch_neck: I'm still having problems accessing the serial port from linux C program running on the yun side.

I think something inside the OS is using the serial port still and interrupting the communications.

Did you try my Python code for disabling the bridge ?

It would make much more sense to move this Thread to the Yun section where this issue has been discussed in several Threads.


You may be having two issues:

  • serial output from your sketch interrupting the Linux boot process
  • system messages from the Linux side confusing the sketch

Neither of these are related to the Bridge processes or code. As long as you don't call Bridge.begin() in your sketch, there is nothing bridge related happening on the Linux side.

You're hung up on the bridge and losing sight of your goals: you've already disabled the bridge and don't need to remove anything related to the bridge. What you need to do is to prevent the two issues above from causing you problems.

Problem 1: serial output from your sketch is interrupting the Linux boot process. You start out by saying that loading the sketch stops Linux from booting, and setting the sketch to 300 baud lets it boot. What's happening is that even before Linux starts, there are a couple places in uboot and pre-init where you can press any key to interrupt the boot process. If your sketch is sending data at that time, it will stop the boot process, and the Linux side will be dead in the water. By changing the sketch baud rate to 300 baud, even though your sketch is still sending data at this critical time, the Linux side isn't seeing a keypress since the baud rates are so far different.

There is nothing you can do on the Linux side to prevent this (apart from editing and rebuilding the boot code): it's a function of the early boot process code that runs before Linux has started. And it certainly has nothing to do with any Bridge related code.

Read this for some ideas: How to improve reboot/reset stability

I've had good luck by using the (normally disabled) handshake line that is between the two processors. Read this thread, STARTING HERE.

Problem 2: system messages from the Linux side confusing the sketch. During the bootup process (and later when certain things happen like an SD card is inserted or removed) the Linux system sends diagnostic messages to the serial port that happens to go to the other processor. This is independent of the login prompt that you disabled. Any code you write on the sketch side needs to be robust enough so that it is not confused by these messages. I recommend you come up with a well-defined communications protocol between your two processes that include some sort of error detection capability, so that these unexpected messages can be ignored and don't confuse your code. Again, this has nothing to do with the Bridge.

You can reduce some (but not all) of these messages by using the ideas IN THIS THREAD, paying particular attention to the line about printk, which controls the level of system messages sent out on the serial port. But this won't stop the boot-up messages that come out before Linux is running.

Note that the link I posted above about using the handshake line can also help here: until the line is active, the sketch doesn't send anything to the Linux side that can confuse it, and the sketch also ignores everything coming from the Linux side so it doesn't get confused.

So, at this point, forget about the bridge, you've already disabled it and it is not affecting you one bit. Concentrate on the other things that Linux (not the bridge!) does with this serial port.

Hello shape shifter,

That was a great answer thanks. I fixed the problem by writing code in the sketch, so that it doesnt send anything until it hears a certain pattern from the linux side (when my linux C code starts running it sends this).

Now I have a new problem... everything works fine for a while. What I do is start communication at 300, then send a signal from my linux C code to the sketch to crank up the baud to 115200, this works too, for a few minutes.

After a few minutes, all communication stop, nothing can be sent from the linux to the sketch until I remove power and reboot the whole board.

Im using the command line linux shell via ssh. I have no idea whats wrong. Even if I stop my linux code by hitting control C getting back the shell prompt, then hitting the reset button to reset the Atmel processor only, then run my code again from command line, there is still no communication.

So I try the reverse, I keep the atmel processor running, and reboot the linux only, by typing reboot at the command line, then it comes back up, and I run my program, it still dont work.

Only if I remove power from the whole board it works again for a few minutes, then stops again.

I think there is something in the linux OS, or maybe some script, that's maybe polling using the serial port, so takes it over the serial port after a few minutes, preventing communication by my running C code.

Maybe I have remove all traces of the bridge from the openwrt build, including all scripts and packages related to bridge and serial communication?

Does anybody have any ideas?

Thanks Im so desperate!!

The output of


Your C code?

Hello Sonny Yu,

Thanks for asking, I no longer think its the linux code, I think maybe there is some problem with the arduino or the hardware.

I hooked up a scope to the RX/TX port of the YUN to arduino serial port. When the serial communication stops, I can see the YUN sending serial data to arduino, but arduino sends nothing back.

So, I put some debug code to toggle an LED in the arduino code in the loop() see below, I can see LED toggling when everything is running normally. As soon as the communication stops the led also stops toggling, meaning that the arduino code is no longer running.

Even if I press the reset button on the YUN to reset arduino multiple times, nothing happens, the code never starts running again unless I remove power from the entire board, and plug it back in, then it starts running again.

What I notice is that when the problem happens, the TX LED on the board is constantly flashing, even if I press reset, it stops flashing only while reset is held down, but when I release reset button, it starts flashing again, but the arduino code never starts running again until I unplug the power and plug it back in because the LED being toggled in loop never blinks.

Maybe its some kind of boot loader problem, or hardware? I tried two YUN boards and the same thing happens on both.

I have code on the arduino that resets the board using watch dog, or if it stops getting data from the linux side. Here is the arduino code....

define RESET_PIN 12 // output pin 12 is shorted to the arduino reset pin

define DEBUG_PIN 3

void (*resetFunc) (void)=0;

void setup() { digitalWrite(RESET_PIN,HIGH); delay(200); pinMode(RESET_PIN,OUTPUT);


wdt_enable(WDTO_1S); // enable watch dog Serial1.begin(300); .... }

void loop() { digitalWrite(DEBUG_PIN,flip); flip=!flip;

// other code here

if (no communication for 15 seconds) { // reset arduino while(1) { digitalWrite(DEBUG_PIN,1); digitalWrite(RESET_PIN,LOW); // hardware reset (pin 12 shorted to reset line) delay(1000); digitalWrite(DEBUG_PIN,0); resetFunc(); // software reset in case hardware reset doesnt work delay(1000); } } wdt_reset(); // if code goes crazy use watch dog to automatically reset }

This is so strange, does anybody have any ideas?


I had similar problems in the past. Were you able to resolve this? If not, then I can try to simulate this condition and help in getting to some solution.