SparkFun Forums 

Where electronics enthusiasts find answers.

#203517
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 <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:192: recipe for target 'bootload' failed
make: *** [bootload] Error 1
#203548
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 <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: recipe for target 'bootload' failed
make: *** [bootload] Error 1
#203557
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!
#203603
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.
User avatar
By chipace
#203606
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...
Code: Select all
#!/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.
#203770
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.
#203771
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.
#203866
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.
#203871
sparky wrote: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 wrote: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.