Not sure if this is just me. When I ran the Firmata examples, Yun stopped working after I typed "reboot" in SSH console.
I uploaded YunSerialTerminal to check the status of AR9331. I found that it was in U-boot mode! I suspect that when Firmata sent data to AR9331 (like version info), if AR9331 happened to be booting up, this may unexpectedly trigger AR9331 into U-boot mode.
I removed all the Firmata code that sends data back to AR9331, everything is back to normal. So, this kind of confirms my findings.
Can anyone give me some help here? One potential solution is to have AVR to check whether AR9331 is in U-boot mode, if yes, send "reset" to get it out of the unexpected status. But I suspect there may be more elegant solutions.
When the AR9331 reboots any traffic on the serial connection will activate the "Hit any key to stop autoboot", so rather than the AR9331 being "stuck", Firmata is stopping the boot process.
Thanks a lot for your reply and help, noblepepper. I did check out the Bridge code and noticed those lines. However, that may not be sufficient in certain cases, especially when Linino reboots. Even the bridge itself is not working for me.
My application requires the AVR to report analog pin readings periodically (<5 seconds). When Linino reboots, it does not reboot AVR. So, all the code at setup() to prevent entering u-boot becomes irrelevant. The AVR, without noticing the Linino reboot, continues to send some characters out to interfere with the boot process.
After quite some research, I strongly suspect this is a bug with the Arduino Yun design. A good fix would be to change the U-boot to reset Arduino in boot time. This ensures when Linino reboots, Arduino reboots together.
Any one shed more lights on the boot-up issue? Thanks a lot in advance.
Did "quite some research" reveal that this is normal behavior for any hardware running openwrt? Or that is there for very good reasons? Arduino Playground - Yun
Why is your AR9331 rebooting except when power is cycled when the 32U4 will also be reset?
You can certainly change the source code for Uboot to eliminate the opportunity to stop uboot and flash to your Yun, but if you can't work around this in your sketch/linino scripts your chance of succeeding at this in very low and you have intentionally eliminated any safety mechanism to recover.
I guess what they do is to toggle the GPIO pin to reset 32U4 at boot-time. That should be sufficient to solve the stuck case I encountered. Again, I don't think this will change how to enter U-boot at all.
On the other hand, I agree with you that it is a bad idea to reset 32U4 on Linino reboots. My current solution is to develop a serial communication scheme on my own, which avoids the issues with Bridge at least. It is pity that Bridge does not work for me though. I would love to share the development as much as possible.
Why is your AR9331 rebooting except when power is cycled when the 32U4 will also be reset?
Your situation is not clear to me, I see these possibilities:
Power is cycled, both AR9331 and 32U4 will boot, the solution of having the 32U4 wait until the AR9331 has gotten past U-Boot takes care of this. Your description led me to think this was what was needed.
The 32U4 reboots for some reason, the AR9331 does not reboot, the same solution works with a delay of about 1 second to make sure U-boot is not running which since Linino is up is not really necessary. This shouldn't happen if the sketch is properly written. You certainly would not be "stuck in U-boot".
The AR9331 reboots, the 32U4 does not reboot. You would need to find some other solution to ensure the 32U4 does not send any data over the serial link until U-boot is done. this shouldn't happen as Linux normally doesn't require any rebooting, so if the scripts/programs you are using in Linino are properly written they shouldn't cause a reboot or a need for reboot.
Your link gives no details of how the Dragino people did this, I have looked at their work for other reasons but find no source for the patched system they use. If you can tell me where to get this code it would be much appreciated.
If you want to reset the 32U4 when Linino has completed bootup you can simply put reset-mcu in rc.local. There is a thread on this forum about doing this.
The bridge has filled my needs but I am not trying to move large amounts of data over it, most posts I see about bridge problems are related to sending large amounts of data or doing things it wasn't designed for. There are quite a few posts on this forum that are examples of how to disable the bridge and implement solutions to particular tasks
3. The AR9331 reboots, the 32U4 does not reboot. You would need to find some other solution to ensure the 32U4 does not send any data over the serial link until U-boot is done. this shouldn't happen as Linux normally doesn't require any rebooting, so if the scripts/programs you are using in Linino are properly written they shouldn't cause a reboot or a need for reboot.
This is exactly the case I am dealing with right now. There are many chances that the Linux may reboot. For example, a Wi-Fi reset through the Wi-Fi reset button would ultimately call into "wifi-reset-and-reboot", causing Linino to reboot. Factory reset would trigger a reboot as well. See "wifi-reset-button-released", which contains
reset-to-factory-anyway && reboot
As far as what I experienced so far, Wi-Fi reset and factory reset cause Linino to hang when either Bridge or Farmata is used to send data back to our system regularly. This is not acceptable in my cases. I have to ensure they don't hang no matter what.
That is why I need to come up with my own serial solution to avoid issues caused by Bridge and Farmata. My protocol ensures that no characters are sent during the boot process (at least, I tried to do so).
Your link gives no details of how the Dragino people did this, I have looked at their work for other reasons but find no source for the patched system they use. If you can tell me where to get this code it would be much appreciated.
I don't find their patch as well. I am contacting them for this matter and will update the forum as soon as I get more information.