Not a great first impression.

You want feedback. I’ve got feedback. Buckle up.

I bought two Redboard Nanos. My intention was to use them with Mbed, but since that is very new, and the Nano is barely mentioned on the mbed instructions page, I figured I’d start with Arduino.

I had a very hard time uploading code my code. It seems there was a very short window for me to hit the upload button to get the code to upload. Maybe 1/10 times it would succeed. I try different USB cables, different ports, different serial port rates. No luck. The boards are just flaky. Eventually, both boards stop accepting any code. Checking the forums, I see that some others are having similar problems. Re-burning the bootloader is the recommended fix. I can’t get it to work. I try at least 20 times on one board, a bit less on the second. I try a few more times with the artemis_firmware_uploader_gui.py. No luck. Now I’m regretting this experiment. Time to send the boards back.

Except that I’m stubborn… and too curious for my own good. So I solder a jtag header to board #1, hoping to see if I can figure out what’s going on. My Black Magic Probe can’t connect. Neither can my Segger J-Link. Now I’m angry at SparkFun, but mostly at myself, for not giving up a couple of hours ago.

On a whim, I try to burn the bootloader on board #2 using the gui. SURPRISE! It works. And now the board accepts uploads every time, without me having to hit the upload button at the exact right instant. I compile an mbed example. It works. Now I have mixed feelings, because I’ve verified that there’s a fix, but I’ve wasted half a day on this. The Apollo3 is a particularly good fit for my project, but I’m forced to wonder if SparkFun puts out buggy products.

I return my attention to board #1. I can’t get anything to work. The voltage regulator must have been outside the field of view of my soldering camera, because it has a big mark on it from the side of my iron. The board is dead. To be clear, this is my fault. I’m a coder, not a solderer. I should have had someone with better skills solder the jtag header. But, it’s Friday, and I’m working from home, so… A board has died.

It is possible that there’s something unusual about my system that makes this bootloader bug particularly nasty in my case, but from what I can tell, the bootloader is known to be buggy, at least for some users. There are a handful of posts in the forums from people having problems uploading, but I didn’t see anyone have trouble updating the bootloader (at least not when they selected the right rate for the serial port).

At any rate, the bootloader update fixed the problem (at least on the board I didn’t burn up), so I suspect this isn’t the case of a couple of bad boards. It’s also hard to see how it could be user error… those generally aren’t fixed by a bootloader update.

So what could you have done differently? A prominent notice on the docs page for the nano should say: “We’re very sorry, but some Nanos shipped with a buggy bootloader. This makes uploading code fail. If you have trouble uploading code, please update the bootloader. The bug sometimes makes it hard to update the bootloader, so it may take several tries to succeed. Be persistent, and it will be worth the effort.”

A couple of other things might help: An option for a Redboard Nano with the jtag header already soldered on. Better mbed instructions. It was not clear that the command line upload instructions would work for the Nano. Also, Instructions for getting rid of the bootloader altogether and uploading code via the jtag connector would be nice.

One last thing. This is the second time I’ve typed this. The first time, the page suddenly refreshed and lost all my content. It’s possible that I accidentally hit F5, but just in case this has happened to others…

So there’s your feedback. I’m still not sure if I’ll be back.

These boards are released for people to get to play with Artemis. It’s a relatively new module that is open source and will have bugs. SparkFun has sifted through a lot already and they’re still digging into more. It could be possible that some units could have small errors during upload that aren’t caught by quality control measures or some storefront units could have slightly older firmware. Although, I’m delighted to hear that you’re able to find a work around. That shows that the newest core release is working correctly. Oddly enough for me, I’ve never had any issues uploading with the Arduino IDE after fiddling with some of the upload rates.

I’m writing this not to sound “scoldy” but rather keep in mind the scope of the project and that things will get better with further development. Best of luck.

I’m sorry you’ve had such a rough experience and we are glad to have your detailed feedback. The UART bootloader on the Apollo3 has been a source of frustration for many users. That’s why we created the secondary bootloader (the SVL). This was a reliable improvement for the v1 Arduino core – after finally getting it flashed using the other bootloader as you rightly point out. Unfortunately the SVL is currently not working with the v2 Arduino core (we are working on fixing it right now).

Using a debugger / probe should be a surefire way to interact with the device, though it is up to the user to properly configure their particular interface toolchain. I’ve personally had great success with SEGGER J-Link probes. Keep in mind these facts:

  • SWD interface, not JTAG (commonly conflated)

  • AMA3B1KK-KBR (chip ID)

  • make sure the board is independently powered (most probes do not provide power and will check that it is present on the target)

There is another solution as well - we abandoned the UART bootloader entirely on the latest Artemis board (the Artemis Dev Kit) in favor of the open-source DAPLink debugger. It can be used to drag+drop program the board as well as single-step debug with open source tools like pyOCD

A note on soldering in the 1.27mm pitch JTAG header - it’s not really necessary. Just insert a male fitting in the holes and rather than soldering, put a bit of pressure (less than you think) on it sideways to help all the pins make contact. This has worked reliably for me in many boards.

I suppose what you explain in this thread is similar to what was observed there, right?

https://github.com/sparkfun/Arduino_Apollo3/issues/310

Could you explain how / provide the link to instructions for how to burn the bootloader that worked with the mbed-os core (currently v2.0.3 I think).