Actions
Forum Thread Details
  • Replies 18 replies
  • Subscribers 410 subscribers
  • Views 592 views
  • Users 0 members are here
Related

Anyone Have stability issues with Arduino Uno Q?

SensoredHacker0

So im at my PC typing away. The Uno Q ran my code on the first try on the first day i got it, a couple days ago.
made some more tests, for 2 days everything was working great. Then, without warning, did not move it, or touch it, it stopped.
ok fine I guess. Then I tried to upload new test code. it compiles, and claims to have been uploaded. but the code doesnt work. 


The hardware which was attached, when it failed:
a Max33041E shield, and the Ethernet R3 shield. these had been working for a couple days straight. 

Not like the code is buggy, but like it doesn't even init the serial print lines. 
bash my head on the wall for a while. 
Press Reset. nothing. Un plug it, wait, re insert usb power.
$dmesg shows it, loading without issue.  

Pull the shields off, load blink. same thing, it compiles, and claims to upload, but the code never runs. 

I haven't reinstalled the boot-loader, by the time I thought to try that, I'd already gone to bed. 
But I've never had such random problems before. Ive got arduino running in projects that have run for 6 years straight not problem.

besides reloading the bootloader and one have some ideas?


Are there stability issues with the Arduino Uno Q I should know about?

Perhaps the most frustrating thing was that the LED matrix was making little hearts and arduino logos the whole time. 
meanwhile blink wont run. 

  • Yes I have had similar problems myself. To get it working again, I ended up Flashing a New Image to the UNO Q: https://docs.arduino.cc/tutorials/uno-q/update-image/ To restore the board, follow the specific procedures detailed in the Download & Install CLI Tool section.

    CRITICAL WARNING! Be aware that performing these instructions will entirely wipe the board. All saved files and configurations will be permanently destroyed.

    It is essential to back up your work to an external location before proceeding with the flash. Remember that this is currently an experimental platform, not yet suitable for production-level development. As early adopters, we are essentially the "guinea pigs" navigating a developing technology from Arduino.

    If that works let me know

  • That's concerning. Q has so much potential, but it's currently let down because of (it feels to me) lack of focus by Arduino. If it's going to stop starting up correctly after some power cycles, then it just won't get used, people will switch to other control boards. They have to take this seriously and eliminate such flakiness from the software/OS build or hardware, this to me is a showstopper, otherwise no-one can trust using it. I bought a Q to try it out, but will wait till it's more mature (hopefully). Also, a few of the other Arduino boards have at least perceived problems, since Mbed is EOL very shortly, and I wonder how long till any replacement Arduino libraries will be reliable. Think Arduino needs to have better messaging at a minimum, so users are not in the dark.

  • The Q can't really be expected to be compared reliability/stability wise with previous Arduinos.  With the new hybird MPU/MCU structure it is going to have a lot more issues than the MCU only boards.  I have found that I encountered different sets of issues depending on the hardware and software configuration and development environment.  You really haven't indicated how you are set up (PC USB host, headless, standalone), how you are powered, and what your development setup is. 

    Based on your description, I assume that you are using AppLab running on a USB host.  How are you determining that it doesn't reach the serial print lines (that would be Monitor rather than Serial in AppLab)?  Your Linux side appears to be running (assume you checked dmesg via ssh).  If you are in AppLab I would guess that the RouterBridge is failing and may be hanging the MCU.  The AppLab Blink example no longer runs only on the MCU.

    I would recommend that you connect a USB to UART adapter (3.3V) between your PC and the MCU.  You could also try one (1.8V) between the PC and the MPU.  That would help with debug.

  • in reply to ralphjy

    I'm glad you guys are investigating the Q and working through the issues. It will help everyone.

    However, got to strongly disagree with this:

    The Q can't really be expected to be compared reliability/stability wise with previous Arduinos.  With the new hybird MPU/MCU structure it is going to have a lot more issues than the MCU only boards.

    That may be the current reality with Q, but is in no way normal. I believe it means that the Arduino people have either (a) treated their creation like a Linux server or desktop PC device, or (b) is simply buggy in their implementation. Either way it's a showstopper as far as I can see.  It's frustrating, I would love to use the Q but not if it cannot be power-cycled with confidence.

    This is not the first device containing a microprocessor and microcontroller, and it needs to start up consistently every single time. I'd be especially concerned if the cause is (a) because then that means there's a complete misunderstanding by them about how people use any typical SBC or any Arduino board for that matter.

  • in reply to shabaz

    Arduino has switched to using Zephyr RTOS: https://github.com/arduino/ArduinoCore-zephyr

    Still a long way to go to get to version 1 - they're at version 0.55.

    My guess is that it'll go version 1 once the next Zephyr LTS version is released next year.

  • in reply to BigG

    I hope they hurry up. That's a long time to be unsure if things will be stable and if the API or subtle behavior will change.

    Sad to say that it appears right now for an amount of networking capability, one might want to simply walk away and consider non-Arduino boards, unless they pull their socks up.

  • in reply to shabaz

    I think by default you still use MBed. You need to manually switch to the Zephyr option. Personally, having persevered with getting to know Zephyr RTOS, I find it really good.

  • in reply to shabaz

    I agree with your comments, but just to clarify what I meant - the Q has much more complexity and many more points of failure, both in hardware and software.  I do think the current implementation is faulty and hopefully that will be fixed in time.   

    You're smart to wait for things to settle down, I expect many of the issues to be resolved in the next couple of quarters.  And the media interface should be available soon.

  • in reply to BigG

    If you are using the Q, the default is using Zephyr - both in AppLab and the standalone Arduino IDE.  Creates problems with legacy hardware because some (many?) third party libraries are not updated.  I ran into problems with the Arducam libraries.  Right now the only option is to port it yourself (a handful of class definition changes).  Hope the manufacturers will update their libraries to Zephyr soon.

    The standalone IDE does work with the Q, but I wouldn't recommend it.  Not sure what the real use case is.  I tried it because it is more familiar to me and I hoped to reuse code, but I don't think that Arduino is really going to support using software external to AppLab for the Q.  Have not investigated if it is possible to remove AppLab to get back the system resources.

  • in reply to ralphjy

    Ah right, I did not know that. Agree, many of the old libraries will simply do not work. It's a case of rethinking our old ways when doing things with Zephyr. Info is there. It needs understanding. That's tricky without tutorials.

    docs.zephyrproject.org/.../README.html