SparkFun Edge failing on "make bootload"

chipace · April 23, 2019, 3:18am

Tried to build the driver in Ubuntu but ran into issues. The github make script is appears to be suited to arch linux.

I took oscilloscope traces of the 4 uart signals while running bootload.

DTR goes low then 250ms later tx sends stream 1, 50ms after that tx sends stream 2. CTS never goes low. If tx stream 1 or stream 2 is out of spec, that could be why apollo3 never drives CTS low. If the tx streams are ok but the apollo3 is not responding for some reason, then that’s on apollo3.

The tx streams look good and sharp edges. I’m thinking something is up on the apollo3 board.

I’m temped to take my two ch340s and have them talk to each other at the different baud rates, using the Ubuntu driver.

chipace · April 23, 2019, 6:02am

Ok, I tested the ch340g and ch340c under Ubuntu with a test program which uses pyserial. I used the oscilloscope to verify that the baud rate was correct. I tested 115200 and 921600.

No issues with sending 10 character strings. I could try more if you want.

Here it is…

#!/usr/bin/python

import time
import serial

# configure the serial connections (the parameters differs on the device you are connecting to)
ser_0 = serial.Serial(
	port='/dev/ttyUSB0',
	baudrate=115200,
	parity=serial.PARITY_ODD,
	stopbits=serial.STOPBITS_TWO,
	bytesize=serial.SEVENBITS
)

ser_1 = serial.Serial(
	port='/dev/ttyUSB1',
	baudrate=115200,
	parity=serial.PARITY_ODD,
	stopbits=serial.STOPBITS_TWO,
	bytesize=serial.SEVENBITS
)

ser_0.isOpen()
ser_1.isOpen()

print 'Enter your commands below.\r\nInsert "exit" to leave the application.'

input=1
while 1 :
    # get keyboard input
    input = raw_input(">> ")
        # Python 3 users
        # input = input(">> ")
    if input == 'exit':
        ser_0.close()
        ser_1.close()
        exit()
    else:
        # send the character to the device
        # (note that I happend a \r\n carriage return and line feed to the characters - this is requested by my device)
        ser_0.write(input + '\r\n')
        out = ''
        # let's wait one second before reading output (let's give device time to answer)
        time.sleep(1)
        while ser_1.inWaiting() > 0:
            out += ser_1.read(1)

        if out != '':
            print "ser_1 rx >>" + out
			
            ser_1.write(input + '\r\n')
            out = ''
            # let's wait one second before reading output (let's give device time to answer)
            time.sleep(1)
            while ser_0.inWaiting() > 0:
                out += ser_0.read(1)

            if out != '':
                print "ser_0 rx >>" + out

Original source from:

https://stackoverflow.com/questions/676 … al-package

Oscilloscope traces

https://imgur.com/a/lDtsiVd?

Here are traces from bootload “Hello”

https://imgur.com/a/8eQDUY9

Not looking good for apollo3.

ballastboy · April 25, 2019, 8:02pm

chipace,

Thanks for all your testing. I have tried 2 boards and I still cannot get either to work through the boot load. Also tried builds from a desktop and a laptop.

chipace · April 27, 2019, 6:30pm

I did the Windows 10 install and the ch340 works just fine. I will capture the uart waveforms tonight. I have no idea what the custom ch340 linux driver is doing different to the kernel driver.

Successful bootload under win10:

https://imgur.com/a/4eWivJV

chipace · April 27, 2019, 8:52pm

The first TX packet is clearly different between Windows and Ubuntu. It doesn’t look inverted or reversed. I may hookup my extra ch340 and see what it thinks is being sent.

https://imgur.com/a/8Ky4I4D

chipace · April 28, 2019, 4:05am

I modified the …/…/…/bsp/tools/uart_wired_update_sparkfun.py script to specify parity, bytesize and stopbits. No change seen. I was thinking that the config defaults between Windows and Linux could be different. It looked like more bits were being sent by Linux.

chipace · April 28, 2019, 4:25am

I looked at the latest ch341 driver in the Linux kernel, and compared it to the WCH one. They are very different. Not just the i2c stuff, but lots of other things. I am think that a manual driver compile for Linux is mandatory.

https://github.com/torvalds/linux/blob/ … al/ch341.c

https://github.com/juliagoda/CH341SER/b … er/ch34x.c

I am curious if I can just use my RPi’s uart to send the bin file using the Sparkfun python script.

liquid.soulder · April 29, 2019, 3:02pm

Neat idea, definitely let us know how it turns out!

wtoconnor · April 30, 2019, 6:59pm

Purchased 2 of these and neither works on Ubuntu 18. Able to program with OSX on Mac. After programming with Mac I can use screen to read the output from test1 example on Ubuntu so the serial port on Ubuntu is configured correctly will at least read. My guess is the boot loader has a specific configuration for the serial that is incompatible with default serial config on Ubuntu. The Sparkfun only uploader specifies the baud rate.

I have and idea - maybe someone at Sparkfun can publish the specific serial configuration for the boot loader so that we can specify them exactly and leave nothing to doubt.

liquid.soulder · April 30, 2019, 7:32pm

sparky:
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.

oclyke:
The Edge boards handed out at the conference have a bootloader set for 115200 baud, however the Edge boards that have come out in the second batch are upgraded to flash at 921600 baud, greatly reducing flashing time. Try changing the baud rate in your serial upload script.

And in either case the specification is 8N1, or 8 data bits, No parity bit, and 1 stop bit.

ballastboy · May 4, 2019, 10:40am

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…

andrewjiang · May 5, 2019, 10:20pm

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:

 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

liquid.soulder · May 6, 2019, 5:01pm

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:

those files exist at that location
the SparkFun_Edge_BSP directory is placed within ‘{AMBIQ_ROOT}/boards’
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!

grillon · May 7, 2019, 9:55am

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

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

grillon · May 7, 2019, 12:31pm

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à :

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

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

liquid.soulder · May 7, 2019, 3:34pm

Hi grillon, I’m glad you got it sorted out. Thanks a bunch for taking the time to share with everyone here!

eca · May 11, 2019, 8:53am

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:

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)
Press and hold button 14
Press and release reset button while still holding button 14
Run “make bootload” while still holding button 14
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

liquid.soulder · May 20, 2019, 7:41pm

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 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!

rev0 · January 18, 2020, 4:18am

Ok, I’ve tried many solutions and combinations after reading all the make issues in this forum, and still having no luck. The closest I’ve gotten is this, by holding down button 14 and running the command (letting the serial board do the reset with DTR):

$ python uart_wired_update_sparkfun.py -b 921600 COM13 -r 1 -f example1_edge_test.bin -i 6
Connecting with Corvette over serial port COM13...
Sending Hello.
Received response for Hello
Received Status
length =  0x58
version =  0x5
Max Storage =  0x4ffa0
Status =  0x2
State =  0x7
AMInfo =
0x1
0xff2da3ff
0x55fff
0x1
0x4cd00005
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  0x4a60  from  0x0  to  0x4a60
Sending Data Packet of length  8180
Sending Data Packet of length  8180
Sending Data Packet of length  2680
Received NACK
msgType =  0x8
error =  0x4
seqNo =  0x0
!!!Wired Upgrade Unsuccessful!!!....Terminating the script

I’m using an FTDI board set to 2.75V. Power is 2.75V.

make bootload gives the following error, no matter what button combos are tried (seems to error before any serial attempt is made):

 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
process_begin: CreateProcess(NULL, ../../../../../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, ...) failed.
make (e=193): Error 193
make: *** [wired_update] Error 193

I guess maybe I was supposed to make the nonsecure_ota? I tried the command that failed in make manually and tried flashing the nonsecure_ota file also, no luck:

$ python create_cust_image_blob.py --bin example1_edge_test.bin --load-address 0xC000 --magic-num 0xCB -o main_nonsecure_ota --version 0x0
Header Size =  0x80
original app_size  0x4a60 ( 19040 )
load_address  0xc000 ( 49152 )
app_size  0x4a60 ( 19040 )
w0 = 0xcb004ae0
Security Value  0x10
w2 =  0x10008080
addrWord =  0xc000
versionKeyWord =  0x0
child0/feature =  0xffffffff
child1 =  0xffffffff
crc =   0x26059ccb
Writing to file  main_nonsecure_ota.bin

$ python uart_wired_update_sparkfun.py -b 921600 COM13 -r 1 -f main_nonsecure_ota.bin -i 6
Connecting with Corvette over serial port COM13...
Sending Hello.
Received response for Hello
Received Status
length =  0x58
version =  0x5
Max Storage =  0x4ffa0
Status =  0x2
State =  0x7
AMInfo =
0x1
0xff2da3ff
0x55fff
0x1
0x4cd00005
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  0x4ae0  from  0x0  to  0x4ae0
Sending Data Packet of length  8180
Sending Data Packet of length  8180
Sending Data Packet of length  2808
Received NACK
msgType =  0x8
error =  0x4
seqNo =  0x0
!!!Wired Upgrade Unsuccessful!!!....Terminating the script

duttasantanu · February 9, 2020, 5:11pm

Hi All

Followed all the steps in Windows 10 machine : facing the follwoing error: Please help me in resolving it.

$ 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

…/src/tf_adc/tf_adc.c: In function ‘am_adc_isr’:

…/src/tf_adc/tf_adc.c:62:58: warning: passing argument 2 of ‘am_hal_adc_samples_read’ makes pointer from integer without a cast [-Wint-conversion]

62 | true,

| ^~~~

| |

| int

In file included from …/…/…/…/…/mcu/apollo3/am_mcu_apollo.h:132,

from …/src/tf_adc/tf_adc.c:1:

…/…/…/…/…/mcu/apollo3/hal/am_hal_adc.h:618:53: note: expected ‘uint32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘int’

618 | uint32_t *pui32InSampleBuffer,

| ^~~~~~~~~

…/src/tf_adc/tf_adc.c:64:58: warning: passing argument 4 of ‘am_hal_adc_samples_read’ from incompatible pointer type [-Wincompatible-pointer-types]

64 | &ui32NumSamples,

| ^~~~~~~~~~~~~~~

| |

| uint32_t * {aka long unsigned int *}

In file included from …/…/…/…/…/mcu/apollo3/am_mcu_apollo.h:132,

from …/src/tf_adc/tf_adc.c:1:

…/…/…/…/…/mcu/apollo3/hal/am_hal_adc.h:620:64: note: expected ‘am_hal_adc_sample_t *’ {aka ‘struct *’} but argument is of type ‘uint32_t *’ {aka ‘long unsigned int *’}

620 | am_hal_adc_sample_t *pui32OutBuffer);

| ~~~~~~~~~^~

…/src/tf_adc/tf_adc.c:61:38: error: too many arguments to function ‘am_hal_adc_samples_read’

61 | if (AM_HAL_STATUS_SUCCESS != am_hal_adc_samples_read(g_ADCHandle,

| ^~~~~~~~~~~~~~~~~~~~~~~

In file included from …/…/…/…/…/mcu/apollo3/am_mcu_apollo.h:132,

from …/src/tf_adc/tf_adc.c:1:

…/…/…/…/…/mcu/apollo3/hal/am_hal_adc.h:617:19: note: declared here

617 | extern uint32_t am_hal_adc_samples_read(void *pHandle,

| ^~~~~~~~~~~~~~~~~~~~~~~

make: *** [Makefile:162: bin/tf_adc.o] Error 1

Thanks and Regard

Topic		Replies	Views
SparkFun Edge failing on "make bootload" on ubuntu Development Boards edge	17	4372	July 6, 2019
SparkFun Edge Development Board - Diagnosis Development Boards edge	7	2640	September 4, 2019
Sparkfun Edge 2 board flashing - button 14 does not exist, how to flash? Development Boards edge	7	3521	November 8, 2019
Sparkfun Edge bootloader problems Development Boards edge	1	1414	June 15, 2021
Sparkfun Edge bootloader problems Artemis	0	1411	February 19, 2021

SparkFun Edge failing on "make bootload"

Related topics