SparkFun Edge failing on "make bootload"

I followed the instructions on the page titled “Using SparkFun Edge Board with Ambiq Apollo3 SDK” and everything worked great!

I got to the point in example1 where I do “make bootload”

The board was quickly blinking the “37” blue LED. I held the “14” button and pushed and released the “rst” button. The blue LED stopped blinking and then ran the “make bootload”

Here is a copy/paste of what I saw:

$make bootload

Compiling gcc …/src/main.c

Compiling gcc …/…/…/…/…/devices/am_devices_led.c

Compiling gcc …/…/…/…/…/utils/am_util_delay.c

Compiling gcc …/…/…/…/…/utils/am_util_faultisr.c

Compiling gcc …/…/…/…/…/utils/am_util_stdio.c

Compiling gcc startup_gcc.c

Compiling gcc …/src/tf_adc/tf_adc.c

Compiling gcc …/src/tf_accelerometer/tf_accelerometer.c

…/src/tf_accelerometer/tf_accelerometer.c: In function ‘platform_read’:

…/src/tf_accelerometer/tf_accelerometer.c:336:31: warning: assignment to ‘uint32_t *’ {aka ‘long unsigned int *’} from incompatible pointer type ‘uint8_t *’ {aka ‘unsigned char *’} [-Wincompatible-pointer-types]

iomTransfer.pui32RxBuffer = bufp; // Link in the RX buffer

^

Compiling gcc …/src/tf_accelerometer/lis2dh12_reg.c

Linking gcc bin/example1_edge_test.axf

Copying gcc bin/example1_edge_test.bin…

…/…/…/…/…/tools/apollo3_scripts/create_cust_image_blob.py --bin bin/example1_edge_test.bin --load-address 0xC000 --magic-num 0xCB -o bin/main_nonsecure_ota --version 0x0

Header Size = 0x80

original app_size 0x460c ( 17932 )

load_address 0xc000 ( 49152 )

app_size 0x460c ( 17932 )

w0 = 0xcb00468c

Security Value 0x10

w2 = 0x10008080

addrWord = 0xc000

versionKeyWord = 0x0

child0/feature = 0xffffffff

child1 = 0xffffffff

crc = 0xb13edac3

Writing to file bin/main_nonsecure_ota.bin

…/…/…/…/…/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin bin/main_nonsecure_ota.bin -i 6 -o bin/main_nonsecure_wire --options 0x1

Header Size = 0x60

app_size 0x468c ( 18060 )

Writing to file bin/main_nonsecure_wire.bin

Image from 0x0 to 0x468c will be loaded at 0x20000

…/…/…/bsp/tools/uart_wired_update_sparkfun.py -b 921600 /dev/tty.usbserial-1410 -r 1 -f bin/main_nonsecure_wire.bin -i 6

Connecting with Corvette over serial port /dev/tty.usbserial-1410…

Sending Hello.

No response for command 0x00000000

received bytes 48

[‘0x86’, ‘0xe5’, ‘0xac’, ‘0x80’, ‘0x5’, ‘0x83’, ‘0x80’, ‘0xd0’, ‘0x80’, ‘0x82’, ‘0x80’, ‘0x87’, ‘0x80’, ‘0x81’, ‘0x80’, ‘0xff’, ‘0x5c’, ‘0xf1’, ‘0xff’, ‘0x35’, ‘0x80’, ‘0x0’, ‘0x80’, ‘0x83’, ‘0xf4’, ‘0xb2’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’]

Traceback (most recent call last):

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 341, in

main()

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 42, in main

connect_device(ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 61, in connect_device

response = send_command(hello, 88, ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 238, in send_command

raise NoResponseError

main.NoResponseError

make: *** [bootload] Error 1

I can verify that the tty that I specified in the makefile is the correct one. /dev/tty.usbserial-1410. If i unplug the edge board, the device file is no longer there. When I plug it back in, it comes back.

Sounds like you’re really close.

To be clear there are two version of the Edge in the wild; if you purchased the Edge board from us, the board has the faster 921600bps bootloader and should be working with the script you posted above (thanks for that!). If you got your board from Google at their TensorFlow conference it has the slower 115200bps. You’d need to change the make file at this line:

…/…/…/bsp/tools/uart_wired_update_sparkfun.py -b 921600 /dev/tty.usbserial-1410 -r 1 -f bin/main_nonsecure_wire.bin -i 6

to

…/…/…/bsp/tools/uart_wired_update_sparkfun.py -b 115200 /dev/tty.usbserial-1410 -r 1 -f bin/main_nonsecure_wire.bin -i 6

Hope that makes sense.

I can confirm that I am using a board ordered from SparkFun. I was a pre-order customer.

I ordered two edge boards and both behave this way.

For completeness, I’m using a 3.6.5 python on MacOs Mojave Beta

Other than the baud rate, are there any other knobs that you recommend turning?

I appear to be having a problem at what is effectively the same step, although I’m actually following the instructions from here: https://codelabs.developers.google.com/ … sorflow/#3

The section where I get the problem is also when it waits for a response from the Edge, sends the hello but gets nothing in response. There is also another person who logged the same problem on Stack Overflow here: https://stackoverflow.com/questions/554 … r-problems

I have the version of the Egde direct from Sparkfun.

My output is:

python tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py -b 921600 /dev/ttyUSB0 -r 1 -f main_nonsecure_wire.bin -i 6
Connecting with Corvette over serial port /dev/ttyUSB0...
Sending Hello.
No response for command 0x00000000
received bytes  11
['0xd4', '0x68', '0x7', '0x83', '0x88', '0x80', '0x80', '0x83', '0x80', '0x80', '0x80']
Traceback (most recent call last):
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 338, in <module>
    main()
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 40, in main
    connect_device(ser)
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 60, in connect_device
    response = send_command(hello, 88, ser)
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 237, in send_command
    raise NoResponseError
__main__.NoResponseError

I did try it with the other baud rate but that doesn’t make any differnce. Also, I’ve tested my serial connection with the jumper (to prove I’m getting text echoed back). Am using the USB-C Serial Basic Breakout and have tried it with two cables. Also as I have two Edges I’ve been able to test with both and they both do it. And finally I tried with and without the battery present (again no difference)

My computer is on Arch Linux, with Python 3.7 and everything’s up to date.

Anything else I should try or info I could provide to help diagnose?

Holding down 14, pressing Reset, releasing both, and running “make bootload” is not right.

Something worked but I am not sure what because of fat fingering. I think I was holding 14 down and pressed Reset when

“Connecting with Corvette over serial port COM10…” appeared.

When I tried to reproduce it, I got to a “Wired Upgrade Unsuccessful” state. Pressing 14 interrupts it but “make bootload” puts me right back. Red, blue, and yellow ar lit. Reset also puts it back.

Does anyone know how to get out of “Wired Upgrade…?”

Holding down 14, run “make bootload,” and press Reset when “Connecting with Corvette over serial port COM10…” appears has worked reppeatedly for me.

The Google tutorial got repaginated, so this is the link now: https://codelabs.developers.google.com/ … sorflow/#5

The board never responds properly to the “hello”, despite trying various combinations and sequences of pressing 14 and RST. I either see the “received 11 bytes” response I pasted or none at all:

Connecting with Corvette over serial port /dev/ttyUSB0...
Sending Hello.
No response for command 0x00000000
Traceback (most recent call last):
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 338, in <module>
    main()
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 40, in main
    connect_device(ser)
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 60, in connect_device
    response = send_command(hello, 88, ser)
  File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 237, in send_command
    raise NoResponseError
__main__.NoResponseError

Are there any other diagnostic steps I could try to gather more info / figure this out? Seems like this isn’t a one-off just for me.

Hi nmstoker.

I’ve attached example output from a successful ‘make bootload’ command. There are a few things that I think you can look into.

  1. I see that you’re using the wireupdate python script from Ambiq, you should try using the one that is included in our BSP (SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py) which is how the example makefiles should be set up.

  2. To reiterate the proper way to use the buttons is to hold button 14, press and release reset, then while still holding button 14 press upload. The first reset press is precautionary b/c/ sometimes with a lot of UART traffic the upload will fail - hitting reset first puts it into bootloader mode manually. Then when you upload with the script the FTDI will automatically reset the board again - but if you aren’t holding button 14 it will leave bootloader mode and no longer be able to receive new code.

  3. There is a chance that the UART timing is too far out-of-spec with the CH340C and Mac OSX Mojave. Check out this Stack Overflow question: [Sparkfun Edge bootloader problems. If that is the case you may need to modify the bootloader, which requires using a SWD programmer/debugger connection and the ‘AmbiqSuite-Rel2.0.0\tools\apollo3_scripts\create_info0.py’ script to generate the bootloader with the desired settings. For example the options we used to generate the current bootloader are show below. The -u0 switch sets the baud rate. In the example 0xE1000 corresponds to 921600 baud and the trailing ‘c0’ is required. So for 460800 baud the -u0 flag should be 0x70800c0.

python create_info0.py --valid 1 info0 --pl 1 --u0 0x**E1000**c0 --u1 0xFFFF3031 --u2 0x2 --u3 0x0 --u4 0x0 --u5 0x0 --main 0xC000 --gpio 0x0E --version 0 --wTO 5000

That would generate a binary file called ‘info0.bin’ which needs to be uploaded to the correct place in the Apollo3. The way we did it was with the ‘jlink-prog-info0.txt’ script for J-Link programmers which is also in the Apollo3 tools folder. Note: it had to be fixed to make the device an Apollo3 instead of Apollo2. Below is the modified script. This should give an idea of how/where to put the new bootloader (info0.bin) into the microcontroller. Again, you will need an SWD programmer/debugger to do this.

//connect to device
device AMA3B1KK-KBR
si SWD
speed 1000
r
sleep 10

//set C runtime environment
wreg MSP, 0x10000100

// erase info0
w4 0x10000000 0             // flash info instance
w4 0x10000004 0xd894e09e    // info 0 key
w4 0x10000008 0xFFFFFFFF    // clear return value
setPC 0x08000085            // call the ROM helper function flash_info_erase_from_sram
g
sleep 50
mem32 0x10000008 1          // dump return value for check

// program info0
w4 0x10000000 0             // flash info instance
w4 0x10000004 0             // offset
w4 0x10000008 0x800         // length in words
w4 0x1000000C 0xd894e09e    // info 0 key
w4 0x10000010 0xFFFFFFFF    // clear return value
loadbin info0.bin 0x10001000     //load the info0 binary into sram
setPC 0x08000061            // call the ROM helper function flash_program_info_area_from_sram
g
sleep 50
mem32 0x10000010 1          // dump return value for check

// perform software POI
w4 0x40000004 0x1B

// quit
qc

Here’s a successful log for reference

make bootload
C:/Users/me/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_image_blob.py --bin bin/SparkFun_Edge_Project_Template.bin --load-address 0xC000 --magic-num 0xCB -o bin/main_nonsecure_ota --version 0x0
Header Size =  0x80
original app_size  0x26dc ( 9948 )
load_address  0xc000 ( 49152 )
app_size  0x26dc ( 9948 )
w0 = 0xcb00275c
Security Value  0x10
w2 =  0x10008080
addrWord =  0xc000
versionKeyWord =  0x0
child0/feature =  0xffffffff
child1 =  0xffffffff
crc =   0x662dec13
Writing to file  bin/main_nonsecure_ota.bin
C:/Users/me/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin bin/main_nonsecure_ota.bin -i 6 -o bin/main_nonsecure_wire --options 0x1
Header Size =  0x60
app_size  0x275c ( 10076 )
Writing to file  bin/main_nonsecure_wire.bin
Image from  0x0  to  0x275c  will be loaded at 0x20000
C:/Users/me/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py -b 921600 COM4  -r 1 -f bin/main_nonsecure_wire.bin -i 6
Connecting with Corvette over serial port COM4...
Sending Hello.
Received response for Hello
Received Status
length =  0x58
version =  0x3
Max Storage =  0x4ffa0
Status =  0x2
State =  0x7
AMInfo =
0x1
0xff2da3ff
0x55fff
0x1
0x49f40003
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
0xffffffff
Sending OTA Descriptor =  0xfe000
Sending Update Command.
number of updates needed =  1
Sending block of size  0x27bc  from  0x0  to  0x27bc
Sending Data Packet of length  8180
Sending Data Packet of length  1992
Sending Reset Command.
Done.
[\code]

](tensorflow lite - Sparkfun Edge bootloader problems - Stack Overflow)

Hi again all, Having just looked back on that Stack Overflow question I realized that he was able to solve his uploading problems by updating his CH340 drivers.

The original problem was that at high baud rates the timing was inaccurate and caused corrupted data to be transferred, failing bootload. In his case it occurred on Mac OSX Mojave.

Here’s a quote about his solution

I tried measuring the actual baudrate with a scope on rx/tx pins, and saw that the bit timing using default OSX serial driver is rather imprecise, app 10% off, causing faulty readings, and ultimately missing bytes, when the baudrate are high.

After updating to the ch340 serial driver, timing improved, and the bit timings were correct. At 921600bps, a single byte 8N1 is supposed to be10.9uS

Driver install https://github.com/adrianmihalko/ch340g … s-x-driver

I had the same problem but I got a program to load by trying ‘make bootload’ multiple times. Previously I was cleaning between makes. I tried holding button 14, then not holding it. I’m not sure yet if pressing button 14 while programming is necessary. The connection and loading seemed to happen randomly but I’m going to try and nail down a standard method.

I’m using Ubuntu 18 with the latest GNU compiler, a FT232R cable (3 wires coming from it), and a coil cell battery as the programming voltage source.

liquid.soulder:
2. To reiterate the proper way to use the buttons is to hold button 14, press and release reset, then while still holding button 14 press upload. The first reset press is precautionary b/c/ sometimes with a lot of UART traffic the upload will fail - hitting reset first puts it into bootloader mode manually. Then when you upload with the script the FTDI will automatically reset the board again - but if you aren’t holding button 14 it will leave bootloader mode and no longer be able to receive new code.

Following up on my original problem. I got my board to work.

As mentioned in previous responses, I had to update the CH340C driver on my MacOS Mojave. I did so by visiting this GitHub:

https://github.com/adrianmihalko/ch340g … s-x-driver

When I rebooted, I ended up with two tty devices:

tty.usbserial-1410

tty.wchusbserial1410

I updated my Makefile to use the tty.wchusbserial1410 instead of the tty.usbserial-1410

For me, simply holding the button 14 for the duration of my “make bootload” without touching the reset button allows the update. I press reset after the upload is complete to restart the board.

This is working for me. Once you get the “wired upgrade unsuccessful” error. Keep holding the button 14 and run make bootload again.

Don’t know why that works though!

I am having the same issue. I have opened an issue on GitHub for the example projects here: https://github.com/sparkfun/SparkFun_Edge_BSP/issues/3

Nothing that seems to be working for others seems to be working for me. Here’s my output:

make bootload
 Compiling gcc ../src/main.c
 Compiling gcc ../../../../../devices/am_devices_led.c
 Compiling gcc ../../../../../utils/am_util_delay.c
 Compiling gcc ../../../../../utils/am_util_faultisr.c
 Compiling gcc ../../../../../utils/am_util_stdio.c
 Compiling gcc startup_gcc.c
 Compiling gcc ../src/tf_adc/tf_adc.c
 Compiling gcc ../src/tf_accelerometer/tf_accelerometer.c
../src/tf_accelerometer/tf_accelerometer.c: In function 'platform_read':
../src/tf_accelerometer/tf_accelerometer.c:336:31: warning: assignment to 'uint32_t *' {aka 'long unsigned int *'} from incompatible pointer type 'uint8_t *' {aka 'unsigned char *'} [-Wincompatible-pointer-types]
     iomTransfer.pui32RxBuffer = bufp;       // Link in the RX buffer
                               ^
 Compiling gcc ../src/tf_accelerometer/lis2dh12_reg.c
 Linking gcc bin/example1_edge_test.axf
 Copying gcc bin/example1_edge_test.bin...
../../../../../tools/apollo3_scripts/create_cust_image_blob.py --bin bin/example1_edge_test.bin --load-address 0xC000 --magic-num 0xCB -o bin/main_nonsecure_ota --version 0x0
Header Size =  0x80
original app_size  0x461c ( 17948 )
load_address  0xc000 ( 49152 )
app_size  0x461c ( 17948 )
w0 = 0xcb00469c
Security Value  0x10
w2 =  0x10008080
addrWord =  0xc000
versionKeyWord =  0x0
child0/feature =  0xffffffff
child1 =  0xffffffff
crc =   0x7454f38
Writing to file  bin/main_nonsecure_ota.bin
../../../../../tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin bin/main_nonsecure_ota.bin -i 6 -o bin/main_nonsecure_wire --options 0x1
Header Size =  0x60
app_size  0x469c ( 18076 )
Writing to file  bin/main_nonsecure_wire.bin
Image from  0x0  to  0x469c  will be loaded at 0x20000
../../../bsp/tools/uart_wired_update_sparkfun.py -b 921600 /dev/ttyUSB0 -r 1 -f bin/main_nonsecure_wire.bin -i 6
Connecting with Corvette over serial port /dev/ttyUSB0...
Sending Hello.
No response for command 0x00000000
received bytes  48
['0x86', '0xe5', '0xac', '0x80', '0x5', '0x83', '0x80', '0xd0', '0x84', '0x82', '0x80', '0x87', '0x80', '0x81', '0x80', '0xff', '0x5c', '0xe9', '0xff', '0x35', '0x80', '0x20', '0x80', '0x83', '0xfc', '0x92', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff', '0xff']
Traceback (most recent call last):
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 341, in <module>
    main()
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 42, in main
    connect_device(ser)
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 61, in connect_device
    response = send_command(hello, 88, ser)
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 238, in send_command
    raise NoResponseError
__main__.NoResponseError
make: *** [Makefile:195: bootload] Error 1

It seems like I’m not able to communicate at all with the Edge through the FTDI. Running screen /dev/ttyUSB0 921600 yields nothing. Looking into the CH341 drivers reveals that they’re included in the Linux Kernel. I can confirm this with dmesg output:

[24981.496525] usb 3-1: new full-speed USB device number 2 using xhci_hcd
[24981.637487] usb 3-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[24981.637488] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[24981.637490] usb 3-1: Product: USB2.0-Serial
[24989.168645] usbcore: registered new interface driver ch341
[24989.168655] usbserial: USB Serial support registered for ch341-uart
[24989.168667] ch341 3-1:1.0: ch341-uart converter detected
[24989.169037] usb 3-1: ch341-uart converter now attached to ttyUSB0

I was able to get this working under Arch Linux using the updated kernel drivers and instructions at https://github.com/juliagoda/CH341SER

Awesome! Thanks for figuring that out.

I have been having the same issue but on Ubuntu.

I have tried changing the baud rate to 115200 but this made no difference.

I never get a successful response to the Hello.

I hold button 14 and reset the module, all the lights go off, but when the bootload is attempted the lights go through a sequence and then I have flashing blue light and a fail - this suggests that the board is seeing something during the bootload to trigger the lights coming back on.

Any ideas?

Connecting with Corvette over serial port /dev/ttyUSB0…

Sending Hello.

No response for command 0x00000000

received bytes 48

[‘0x86’, ‘0xd1’, ‘0xac’, ‘0x80’, ‘0x5’, ‘0x83’, ‘0x80’, ‘0xd0’, ‘0x84’, ‘0x82’, ‘0x80’, ‘0x87’, ‘0x80’, ‘0x81’, ‘0x80’, ‘0xff’, ‘0x5c’, ‘0xe9’, ‘0xff’, ‘0x2d’, ‘0x80’, ‘0x20’, ‘0x80’, ‘0x83’, ‘0xf8’, ‘0xb2’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’, ‘0xff’]

Traceback (most recent call last):

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 341, in

main()

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 42, in main

connect_device(ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 61, in connect_device

response = send_command(hello, 88, ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 238, in send_command

raise NoResponseError

main.NoResponseError

Makefile:192: recipe for target ‘bootload’ failed

make: *** [bootload] Error 1

Ubuntu 18.04 and same issue. Tried both CH340G and CH340C adapters. Tried with coin cell and without. Tried without coin cell and uart vcc connected to battery +. Board is from Sparkfun.

Checked usb uart and vcc is 3.3V. I never see any voltage on board VDD with coin cell or uart connection. Coin cell boots board and gives blue flashing light (with no uart connection).

Here is what I see when I run bootload. I get a different CRC for the bin file, and I will only get 11 bytes from the board when I Send Hello. I would expect the bin file CRC to be the same for everyone, regardless of OS or computer… maybe this is a clue that the toolchain is setup incorrectly?

…/…/…/…/…/tools/apollo3_scripts/create_cust_image_blob.py --bin bin/example1_edge_test.bin --load-address 0xC000 --magic-num 0xCB -o bin/main_nonsecure_ota --version 0x0

Header Size = 0x80

original app_size 0x460c ( 17932 )

load_address 0xc000 ( 49152 )

app_size 0x460c ( 17932 )

w0 = 0xcb00468c

Security Value 0x10

w2 = 0x10008080

addrWord = 0xc000

versionKeyWord = 0x0

child0/feature = 0xffffffff

child1 = 0xffffffff

crc = 0x991a334c

Writing to file bin/main_nonsecure_ota.bin

…/…/…/…/…/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin bin/main_nonsecure_ota.bin -i 6 -o bin/main_nonsecure_wire --options 0x1

Header Size = 0x60

app_size 0x468c ( 18060 )

Writing to file bin/main_nonsecure_wire.bin

Image from 0x0 to 0x468c will be loaded at 0x20000

…/…/…/bsp/tools/uart_wired_update_sparkfun.py -b 921600 /dev/ttyUSB0 -r 1 -f bin/main_nonsecure_wire.bin -i 6

Connecting with Corvette over serial port /dev/ttyUSB0…

Sending Hello.

No response for command 0x00000000

received bytes 11

[‘0xd4’, ‘0x70’, ‘0x7’, ‘0x87’, ‘0x94’, ‘0x80’, ‘0x80’, ‘0x83’, ‘0x80’, ‘0x80’, ‘0x80’]

Traceback (most recent call last):

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 341, in

main()

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 42, in main

connect_device(ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 61, in connect_device

response = send_command(hello, 88, ser)

File “…/…/…/bsp/tools/uart_wired_update_sparkfun.py”, line 238, in send_command

raise NoResponseError

main.NoResponseError

Makefile:193: recipe for target ‘bootload’ failed

make: *** [bootload] Error 1

Chipace and Ballastboy - since you are both on Ubuntu have you tried updating your serial drivers? It seems to me like this could be related to the Arch Linux problem seen above. It would also be useful, if you can, to take a look at the timing of the UART output from the USB-serial converter. Is it in-spec for a 921600 baud connection? Let us know how it goes!