uart_wired_update.py & Linux woes

Development Boards
1

Hi Everyone,

I’m having some problems with my SparkFun edge when I try to push down an image using uart_wired_update.py.

The following command

python3 tensorflow/lite/micro/tools/make/downloads/AmbiqSuite-Rel2.2.0/tools/apollo3_scripts/uart_wired_update.py -b 921600 /dev/ttyUSB1 -r 1 -f ./main_nonsecure_wire.bin -i 6

Connecting with Corvette over serial port /dev/ttyUSB1…

Sending Hello.

No response for command 0x00000000

received bytes 11

[‘0xdc’, ‘0x68’, ‘0x7’, ‘0x87’, ‘0x84’, ‘0x80’, ‘0x80’, ‘0x83’, ‘0x80’, ‘0x80’, ‘0x80’]

Traceback (most recent call last):

File “tensorflow/lite/micro/tools/make/downloads/AmbiqSuite-Rel2.2.0/tools/apollo3_scripts/uart_wired_update.py”, line 338, in

main()

File “tensorflow/lite/micro/tools/make/downloads/AmbiqSuite-Rel2.2.0/tools/apollo3_scripts/uart_wired_update.py”, line 40, in main

connect_device(ser)

File “tensorflow/lite/micro/tools/make/downloads/AmbiqSuite-Rel2.2.0/tools/apollo3_scripts/uart_wired_update.py”, line 60, in connect_device

response = send_command(hello, 88, ser)

File “tensorflow/lite/micro/tools/make/downloads/AmbiqSuite-Rel2.2.0/tools/apollo3_scripts/uart_wired_update.py”, line 237, in send_command

raise NoResponseError

main.NoResponseError

I did pull down the driver from here : https://github.com/juliagoda/CH341SER which I replaced the current module that my ubuntu (PopOS) had installed by default. I’m on a 5.3 kernel bog standard.

dmesg reports :

[4364003.240193] usb 1-5: new full-speed USB device number 12 using xhci_hcd

[4364003.389251] usb 1-5: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63

[4364003.389256] usb 1-5: New USB device strings: Mfr=0, Product=2, SerialNumber=0

[4364003.389259] usb 1-5: Product: USB2.0-Serial

[4364003.390990] ch341 1-5:1.0: ch341-uart converter detected

[4364003.391746] usb 1-5: ch341-uart converter now attached to ttyUSB1

Any suggestions?

Thanks!

2

Sounds like you already discovered this helpful posting:

viewtopic.php?f=153&t=49965#p204500

It might worthwhile to go through steps 5 though 8 a few more times with some combinations of plugging/unplugging or even not unplugging, while watching the attachments logged in dmesg. The old driver could still be finding its way back into the mix. A successful attachment showing up in dmesg should reference ch34x if the new driver** is in place, I think. In your output, it appears as though the original driver (ch341-uart) might still be in play.

**https://github.com/juliagoda/CH341SER