SparkFun Forums 

Where electronics enthusiasts find answers.

User avatar
By rl337
#203020
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 <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: *** [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.
User avatar
By sparky
#203042
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.
User avatar
By rl337
#203082
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?
#203110
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:
Code: Select all
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?
#203148
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...?"
#203223
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:
Code: Select 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.
#203229
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.
Code: Select all
python create_info0.py --valid 1 info0 --pl 1 --u0 0x[b]E1000[/b]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.
Code: Select all
//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
Code: Select all
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]
#203234
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
User avatar
By shane_
#203255
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.
#203258
liquid.soulder wrote: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.
User avatar
By rl337
#203287
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.
User avatar
By karma0
#203378
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:
Code: Select all
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
User avatar
By karma0
#203389
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:
Code: Select all
[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