SparkFun RedBoard Artemis Nano - Upload fails from Linux

[nigelb]

Subject of the issue

I have a SparkFun RedBoard Artemis Nano. I followed the instillation instructions from the README on both Windows and Linux. Everything works fine from windows but when I use Linux the uploader fails.

Your workbench

• What platform are you using?

Linux (Ubuntu 18.04.3 LTS): ardunio-1.8.10
Windows 10 Pro: ardunio-1.8.10

• What version of the device are you using? Is there a firmware version?

SparkFun RedBoard Artemis Nano

• How is the device wired to your platform?

USB-C Cable from PC to device.

• How is everything being powered?

USB-C Cable from PC to device.

• Are there any additional details that may help us help you?

Steps to reproduce

1. Install Arduino
2. Add SparkFun boards to Arduino as per instillation instructions.
3. Select Board: SparkFun RedBoard Artemis Nano
4. Select Bootloader: SparkFun Variable Bootloader
5. Select SVL Baud Rate: 921600
6. Select port: Appropriate Port for Machine
7. Create Sketch:

#include "Arduino.h"

void setup()
{
    Serial.begin(115200);

};

void loop()
{
    Serial.println("Hello World!");
};

8. Press the Compile and Upload Buttons.

Expected behaviour

When I compile and upload from windows:

.
.
.
Sketch uses 6712 bytes (0%) of program storage space. Maximum is 960000 bytes.
C:\Users\user\AppData\Local\Arduino15\packages\SparkFun\hardware\apollo3\1.0.20/tools/artemis/windows/artemis_svl.exe COM12 -f C:\Users\iser\AppData\Local\Temp\arduino_build_484232/helloworld.ino.bin -b 921600 -v 


Artemis SVL Bootloader

phase:	setup
	cleared startup blip
	Got SVL Bootloader Version: 3
	Sending 'enter bootloader' command

phase:	bootload
	have 6744 bytes to send in 4 frames
	sending frame #1, length: 2048
	sending frame #2, length: 2048
	sending frame #3, length: 2048
	sending frame #4, length: 600

	 Upload complete

Actual behaviour

When I compile and upload from Linux:

.
.
.
Sketch uses 6712 bytes (0%) of program storage space. Maximum is 960000 bytes.
/home/user/.arduino15/packages/SparkFun/hardware/apollo3/1.0.20/tools/artemis/linux/artemis_svl /dev/ttyUSB0 -f /tmp/arduino_build_176074/apollo3_hello_world.ino.bin -b 921600 -v 


Artemis SVL Bootloader

phase:	setup
	cleared startup blip

phase:	bootload
	have 6744 bytes to send in 4 frames

	error receiving packet
{'len': 0, 'cmd': 0, 'data': 0, 'crc': 1, 'timeout': 1}


unknown error
	sending frame #0, length: 0

	 Upload failed

phase:	setup
	cleared startup blip

phase:	bootload
	have 6744 bytes to send in 4 frames

	error receiving packet
{'len': 0, 'cmd': 0, 'data': 0, 'crc': 1, 'timeout': 1}


unknown error
	sending frame #0, length: 0

	 Upload failed

phase:	setup
	cleared startup blip

phase:	bootload
	have 6744 bytes to send in 4 frames

	error receiving packet
{'len': 0, 'cmd': 0, 'data': 0, 'crc': 1, 'timeout': 1}


unknown error
	sending frame #0, length: 0

	 Upload failed

When I compile and upload from Linux, after I have uploaded the same sketch from Windows I get this different error:

.
.
.
Sketch uses 6712 bytes (0%) of program storage space. Maximum is 960000 bytes.
/home/user/.arduino15/packages/SparkFun/hardware/apollo3/1.0.20/tools/artemis/linux/artemis_svl /dev/ttyUSB0 -f /tmp/arduino_build_176074/apollo3_hello_world.ino.bin -b 921600 -v 

[32220] Failed to execute script artemis_svl

Traceback (most recent call last):
Artemis SVL Bootloader

  File "artemis_svl.py", line 393, in <module>
phase:	setup
	cleared startup blip
  File "artemis_svl.py", line 333, in main

phase:	bootload
  File "artemis_svl.py", line 224, in phase_bootload
	have 6744 bytes to send in 4 frames
  File "artemis_svl.py", line 132, in wait_for_packet
IndexError: index out of range
IndexError: index out of range

[oclyke]

@nigelb Thnks for the detailed report. It is surprising to see an IndexError: index out of range error. I will make it a point to look into that further.

As for the other case (simply uploading from Linux) we've had many other reports about UART bootloader instability on Linux platforms in the past. That is actually why we created the SVL. So first I'd recommend trying a few other baud rate options (460800, 230400, 115200). If that doesn't work then please try checking / patching your CH340 drivers as described in these links:
https://stackoverflow.com/questions/55463159/sparkfun-edge-bootloader-problems
https://github.com/juliagoda/CH341SER
https://forum.sparkfun.com/viewtopic.php?f=153&t=49585&start=30

Please let us know how those efforts work out!

[nigelb]

Thanks for the hints @oclyke, I tried different baud rates with no success. I will have a look at updating my CH341SER driver when I am back in the office. I suspect that the IndexError: index out of range error may be due to the active firmware continuously printing "Hello World!", because it only happened after I loaded the test code from above, and went away after I removed the print statement from the loop function.

[oclyke]

@nigelb I just ran into the IndexError: index out of range error problem myself. In my case it was because I previously uploaded a sketch using the Ambiq Secure Bootloader (ASB) which overwrites the SparkFun Variable Loader (SVL). So to fix the error I burned the SVL back onto the board using Arduino. That goes like this:

• Select Ambiq Secure Bootloader as the programmer from Tools -> Programmer
• Burn the SVL to the board using the ASB by clicking on Tools -> Burn Bootloader

I wonder - have you uploaded code using the ASB? That might explain some of this behavior. Perhaps one of your development computers has remembered some changes or old settings that causes it to try the ASB. I'd recommend checking Arduino's Tools options on any computer you are using.

Please let me know what you discover!

[nigelb]

Hey @oclyke, pretty sure the bootloader is correct, see below:

I installed the updated driver from: https://github.com/juliagoda/CH341SER:

$> git clone https://github.com/juliagoda/CH341SER.git
$> cd CH341SER/
$> make
$> sudo make load

Then in dmesg after I plugged in my board:

[135293.825061] usb 5-1: new full-speed USB device number 4 using uhci_hcd
[135294.006329] usb 5-1: New USB device found, idVendor=1a86, idProduct=7523
[135294.006333] usb 5-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[135294.006335] usb 5-1: Product: USB2.0-Serial
[135294.008405] ch34x 5-1:1.0: ch34x converter detected
[135294.013480] usb 5-1: ch34x converter now attached to ttyUSB0

Then I can, with some trouble, upload the sketch:

Sketch uses 6884 bytes (0%) of program storage space. Maximum is 960000 bytes.
/home/user/.arduino15/packages/SparkFun/hardware/apollo3/1.0.20/tools/artemis/linux/artemis_svl /dev/ttyUSB0 -f /tmp/arduino_build_426802/Hello_World.ino.bin -b 921600 -v 


Artemis SVL Bootloader

phase:	setup
	cleared startup blip

phase:	bootload
	have 6744 bytes to send in 4 frames

	error receiving packet
{'len': 27756, 'cmd': 0, 'data': 0, 'crc': 1, 'timeout': 1}


unknown error
	sending frame #0, length: 0

	 Upload failed

phase:	setup
	cleared startup blip
	Got SVL Bootloader Version: 3
	Sending 'enter bootloader' command

phase:	bootload
	have 6744 bytes to send in 4 frames
	sending frame #1, length: 2048
	sending frame #2, length: 2048
	sending frame #3, length: 2048
	sending frame #4, length: 600

	 Upload complete

Now by some trouble I mean I sometimes have to do the "spam the reset button" or "unplug and plug it back in at exactly the right time" tricks mentioned in the links you provided.

However decreasing the SVL baud rate make the firmware upload a lot more reliable (which was also mentioned in the links).

I will also note that the test sketch above, that is continuously writing to the Serial Port, is particularly problematic once it is on the device.

[oclyke]

@nigelb I'm glad it is sort of working for you. Thanks for the report on your troubles too - we are definitely keeping an eye on this and trying to come up with improvements for the future. It has been surprisingly difficult to make this work reliably across all combinations of host systems and USB-serial bridges.

Until we can get back to the bootloader issues You might consider simply using the Ambiq Secure Bootloader option - it is slow (115200) but pretty reliable. The exception being that it is not great when there is a lot of UART data being transmitted.

We built the SVL to address the fixed-speed and poor UART hammering tolerance of the ASB but obviously we still have some work to do on it. In fact if you are interested you could check out the code and maybe make some improvements! The SVL is available as an example in the BSPs repo. You can build it for your board of choice like this:

BOARD=redboard_artemis_nano
cd $BSP_ROOT/$BOARD/examples/artemis_svl/gcc
make asb

This, of course, requires some prerequisites to be installed on your machine. Perhaps the easiest way to get started is to use the artemis_dev_platform

[nigelb]

Thanks @oclyke, I will check it out.

[oclyke]

@nigelb How has this issue progressed for you? We've recently updated the SVL bootloader to v5 which offers speed and reliability improvements. (In v1.0.23 of the core)

You should upgrade the bootloader on the board using the Ambiq Secure Bootloader as your Programmer option and then clicking Burn Bootloader from the Arduino Tools menu

[oclyke]

Closing stale issue. Can re-open if issue persists