SparkFun Forums 

Where electronics enthusiasts find answers.

#204008
I did a build from Windows 10 (GIT BASH) and it all worked OK. There is something up with the Ubuntu 18.04 build. I tried setting the /dev/ttyUSB0 up as above 8N1 but this made no difference. Just need to get the TensorFlow working now.....
#204019
I'm having a problem with make bootload that doesn't seem to be covered above. Would love to get some help. Below is the log:
Code: Select all
 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
make -C ../../../bsp
make[1]: Entering directory '/Users/andrewjiang/Documents/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp'
make[1]: *** No rule to make target 'config.ini', needed by 'buildproj'.  Stop.
make[1]: Leaving directory '/Users/andrewjiang/Documents/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp'
make: *** [Makefile:186: ../../../bsp/gcc/bin/libam_bsp.a] Error 2
#204036
Hey there, I've seen this problem before when the BSP is not compiled, or the BSP object files can't be found. The files in question are:
SparkFun_edge_BSP/bsp/gcc/bin/am_bsp_pins.o
SparkFun_edge_BSP/bsp/gcc/bin/am_bsp.o
SparkFun_edge_BSP/bsp/gcc/bin/libam_bsp.a

and possibly:
SparkFun_Edge_BSP/bsp/gcc/bin/am_bsp_pins.d
SparkFun_Edge_BSP/bsp/gcc/bin/am_bsp.d

Can you verify that:
1. those files exist at that location
2. the SparkFun_Edge_BSP directory is placed within '{AMBIQ_ROOT}/boards'
3. the makefile for your project has the correct path to 'libam_bsp.a' as part of the ${LIBS} variable. (In 'example1_edge_test' the relative path is used: LIBS = ../../../bsp/gcc/bin/libam_bsp.a, in the SparkFun_Edge_Project_Template the path is specified from ${BOARDPATH} as in LIBS = ${BOARDPATH}/bsp/gcc/bin/libam_bsp.a )

Please let us know if that works for you!
#204069
Hi,
I cannot send hello with both ft2232HL and a cp2102. 37 led is blinking fast, card seems recognize yes and no. then I stay push on 14, do a quick push on reset. led 37 stop blinking I then do make bootload.
For both ft2232HL and cp2102 I optain the following output, seems the card is not listening. As I'm not using 340C chipset I guess it's no use to install the driver. My serial cards are working with esp32, stm32, stm8, orangePI PC. How can I upload binary on the sparkfun edge? Do I have to buy a ch340C from sparkfun?

Here the output :
thierry@grillon:~/projets/iot/sparkfun/dev15170/SDK/AmbiqSuite-Rel2.0.0/boards/make bootload
../../../../../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 = 0xe4e5be6b
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
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
Makefile:193 : la recette pour la cible « bootload » a échouée
make: *** [bootload] Erreur 1
#204070
Want to add, I have follow this tutorial : https://codelabs.developers.google.com/ ... sorflow/#5
then it works. So I have tried again ../../../../../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
And it works too, as you can see below. I think it's a question of timing. press reset, press 14 in same time release reset while keeping 14 then quickly launch make bootload without releasing 14 button. reset command does not work so reset by your self and voilà :
Code: Select all
thierry@grillon:~/projets/iot/sparkfun/dev15170/SDK/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/examples/example1_edge_test/gcc$ ../../../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.
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  0x46ec  from  0x0  to  0x46ec
Sending Data Packet of length  8180
Sending Data Packet of length  8180
Sending Data Packet of length  1796
Sending Reset Command.
No response for command 0x00000006
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 175, in connect_device
    send_ackd_command(resetmsg, ser)
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 194, in send_ackd_command
    response = send_command(command, 20, ser)
  File "../../../bsp/tools/uart_wired_update_sparkfun.py", line 238, in send_command
    raise NoResponseError
__main__.NoResponseError
The strange thing is, to push the code I have to choose a baud rate of 921600 but to watch the console it's 115200.

Ohh and while writing this message I have tried with cp2102 it works fine as well, reset command works too :)
Code: Select all
thierry@grillon:~/projets/iot/sparkfun/dev15170/SDK/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/examples/example1_edge_test/gcc$ ../../../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.
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  0x46ec  from  0x0  to  0x46ec
Sending Data Packet of length  8180
Sending Data Packet of length  8180
Sending Data Packet of length  1796
Sending Reset Command.
Done.
PS : with ft2232HL I use 6 pin but with cp2102 I use only five pin because I was not able to identify CTS PIN but it works better than ft2232HL.

So the answer for me was timing between reset, 14 and make bootload. Some times it does not work make a normal reset then tried again.

Hope it helps. I was ready to by CH340C, I have tried with archlinux instead of my beloved devuan. I have tried on ubuntu 18.04 and the problem was between the chair and the keyboard :p
User avatar
By eca
#204209
I am having the same problem with a board purchased from Sparkfun, so with 921600bps bootloader.

I am using Ubuntu 18.04 and replaced the default ch341 driver with the one in https://github.com/juliagoda/CH341SER as sugested in https://github.com/sparkfun/SparkFun_Edge_BSP/issues/3

After the driver update the upload is successfully from time to time, but succeeds significantly more frequently if I follow the following procedure:
1) Disconnect board from PC's USB port, wait a while and reconnect (There is no battery in the board, so this step is actually a power-off/power-on for the board)
2) Press and hold button 14
3) Press and release reset button while still holding button 14
4) Run "make bootload" while still holding button 14
5) When finished, release button 14

Still I don't have 100% success, but around 60% vs. less than 10% if not disconnecting and reconnecting the board from USB port.
This brings me to think of two posible issues:
a) Something might go wrong in the reset sequence of the Edge board if not powered off and on
b) 921600bps seems to be critical, maybe lowering the baud rate would be helpful.

Being successful in a acceptable number of uploads, is there a way to reprogram the board so as to lower the baud rate used during upload, say to 115200bps, without the SWD programmer/debugger but only making a new binary and uploading it into the board?

Thanks
#204408
Hello everyone,

It seems like the bootloader issue is getting fewer and fewer responses, which I take as a good thing. I also just got some additional insights (thanks to people who know Linux much better than I do) about how to properly apply the driver patch.

If this is the first post that you're reading: there have been a handful of cases where bootloading fails on Linux (specifically Arch Linux) with the cause appearing to be outdated CH340 drivers. The [Patched Drivers by juliagoda](https://github.com/juliagoda/CH341SER) are hosted on GitHub. You can follow those instructions to install the drivers, however in some cases that does not fix the problem. If this applies to you keep reading:

If installing the patched drivers (module) does not seem to work you can take these steps:
- unplug then re-plug in your CH340C USB-Serial bridge, then use ```dmesg``` to see what has happened (we want a CH34X device to be detected, indicating the patched drivers being used, but you might see a CH341 driver being used insteead)
- ```lsmod ch34*``` to see what modules are currently installed - verify that a CH34X module is installed, and take note if a CH341 module is installed
- If there is a CH341 module then it may be taking priority over the patched CH34X module. Use ```rmmod ch341``` to uninstall the broken driver
- Try unplugging and replugging in again, along with ```dmesg``` to hopefully see that a CH34X device has been detected.

If you can get the system to identify a CH34X device then the bootload should succeed. As always keep us up to date on how this information does/does not help!