Issue with Flashing Zephyr OS to Artemis Nano: Last Frame Upload Failure

[AlienSarlak]

I planned to port Artemis Nano to Zephyr OS. After adapting the device tree and some other files, I was able to build the OS. I wanted to flash Artemis Nano with Zephyr OS. After compiling, I found zephyr.bin, then I used the following command to flash it to Artemis Nano:

python3 artemis_uploader/artemis_svl.py -f ./build/zephyr.bin -t 5 -b 115200 -v /dev/ttyUSB0

The size of zephyr.bin is 14,603 bytes and the output of the above command is as follows:

Artemis SVL BootloaderScript version 1.7

Phase:	Setup
	Cleared startup blip
	
 - Version: 5

	Sending 'enter bootloader' command

Phase:	Bootload
	have 14603 bytes to send in 8 frames
	Sending frame #1, length: 2048
	Sending frame #2, length: 2048
	Sending frame #3, length: 2048
	Sending frame #4, length: 2048
	Sending frame #5, length: 2048
	Sending frame #6, length: 2048
	Sending frame #7, length: 2048
	Sending frame #8, length: 267
		Retrying...
	Sending frame #8, length: 267
		Retrying...
	Sending frame #8, length: 267
		Retrying...
	Sending frame #8, length: 267
		Retrying...
	Sending frame #8, length: 267

Upload Failed

If you add up all the bytes, you will see the sum is exactly 14,603, but the artemis_svl is not able to flash the last frame. I don't know why. Could you please help me with that? Also, I tried example/Blink.bin, which can be flashed every time without any problem.

Any guide about the mechanism would also be helpful.

Please note that I am aware of the two boot loaders on Artemis nano.

[AlienSarlak]

After reading the "artemis_svl.py" code, I have a feeling that the CRC16 might not match the one in the bootloader, which is why the bootloader rejects the last frame. Is my understanding correct?

[PaulZC]

Hi Ali (@AlienSarlak ),

The crc16 is the exact same one we have been using for over 4 years with the Artemis SVL... Nothing has changed there.

I've tried uploading a blink binary with python artemis_uploader\artemis_svl.py -f c:\Users\pc235\Documents\Arduino\Artemis_Blink\Artemis_Blink.ino.bin -t 5 -b 115200 -v COM13 and it worked OK for me. The bin was compiled using our normal Arduino toolchain.

I've seen your post on the forum. paulvha is your best bet. He has way more experience with Artemis and Apollo3 than I do.

Please do check the memory locations your bin is using. I'm sure the Uploader is unaware of the target memory locations, and that they are coded into the bin. Here is the input to the Arduino toolchain; the memory location 0x10000 ( 2.2.1/tools/uploaders/svl/0x10000.ld ) is defined in there:

"C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\tools\\arm-none-eabi-gcc\\8-2018-q4-major/bin/arm-none-eabi-gcc" "-TC:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\hardware\\apollo3\\2.2.1/tools/uploaders/svl/0x10000.ld" "-Wl,-Map,C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401/Artemis_Blink.ino.map" -o "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401/Artemis_Blink.ino.axf" "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401\\sketch\\Artemis_Blink.ino.cpp.o" "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401\\core\\config\\pins.cpp.o" "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401\\core\\variant.cpp.o" -Wl,--whole-archive "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_cache_964097\\core\\core_c67b97f5e639e4480126e1bfe26a9a3c.a" -Wl,--no-whole-archive -Wl,--whole-archive "C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\hardware\\apollo3\\2.2.1\\variants\\SFE_ARTEMIS_THING_PLUS/mbed/libmbed-os.a" -Wl,--no-whole-archive -Wl,--whole-archive "C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\hardware\\apollo3\\2.2.1/cores/mbed-os/targets/TARGET_Ambiq_Micro/TARGET_Apollo3/sdk/CMSIS/ARM/Lib/ARM/libarm_cortexM4lf_math.a" -Wl,--no-whole-archive "@C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\hardware\\apollo3\\2.2.1\\variants\\SFE_ARTEMIS_THING_PLUS/mbed/.ld-flags" --specs=nano.specs --specs=nosys.specs -lsupc++ -lstdc++ -lm -DARDUINO=10819 -DARDUINO_APOLLO3_SFE_ARTEMIS_THING_PLUS -DARDUINO_ARCH_MBED -DARDUINO_ARCH_APOLLO3 -DMBED_NO_GLOBAL_USING_DIRECTIVE -DCORDIO_ZERO_COPY_HCI "@C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\hardware\\apollo3\\2.2.1\\variants\\SFE_ARTEMIS_THING_PLUS/mbed/.ld-symbols"

"C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\tools\\arm-none-eabi-gcc\\8-2018-q4-major/bin/arm-none-eabi-objcopy" -O binary "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401/Artemis_Blink.ino.axf" "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401/Artemis_Blink.ino.bin"

"C:\\Users\\pc235\\AppData\\Local\\Arduino15\\packages\\SparkFun\\tools\\arm-none-eabi-gcc\\8-2018-q4-major/bin/arm-none-eabi-size" -A "C:\\Users\\pc235\\AppData\\Local\\Temp\\arduino_build_259401/Artemis_Blink.ino.axf"

Sketch uses 116032 bytes (11%) of program storage space. Maximum is 983040 bytes.

Global variables use 27648 bytes (7%) of dynamic memory, leaving 365568 bytes for local variables. Maximum is 393216 bytes.

C:\Users\pc235\AppData\Local\Arduino15\packages\SparkFun\hardware\apollo3\2.2.1/tools/uploaders/svl/dist/windows/svl.exe COM13 -f C:\Users\pc235\AppData\Local\Temp\arduino_build_259401/Artemis_Blink.ino.bin -b 460800 -v 

Best wishes,
Paul

[AlienSarlak]

Thanks for the information. You are correct; I also think that the uploader is unaware of the target memory locations. The behavior I have seen is that the uploader sends the frames to the bootloader and then waits for its reply.

On the last frame, the reply from the bootloader is "resend the frame" instead of proceeding to the next frame.
According to the SVL code, this means the bootloader thinks the frame it received is incorrect, so it asks for the same frame to be resent.

That's why I believe there might be something in the Zephyr bin file causing the CRC16 to fail, although this is just a guess.
[Note that I used the uploader to upload Blink.bin into the artemis nano without any problem]
Best,
Ali