Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending Hello. No response for command 0x00000000 #3

Closed
karma0 opened this issue Apr 15, 2019 · 10 comments

Comments

Projects
None yet
5 participants
@karma0
Copy link

commented Apr 15, 2019

Following the instructions on the SparkFun Apollo3 SDK page leads me to the following failure on image upload to the device:

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 =   0xf79d8bc
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', '0xd5', '0xa4', '0x80', '0x5', '0x83', '0x80', '0xd0', '0x84', '0x82', '0x80', '0x87', '0x80', '0x81', '0x80', '0xff', '0x5c', '0xf5', '0xff', '0x35', '0x80', '0x20', '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: *** [Makefile:195: bootload] Error 1

This is after a long pause at the Sending Hello message. Prior to doing a global sed -i -e 's/115200/921600/g' on all of the files, I was getting:

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

@karma0 karma0 changed the title Not receiving Hello (0x00000000) Not receiving Hello (0x00000000) response Apr 15, 2019

@PaulTR

This comment has been minimized.

Copy link

commented Apr 15, 2019

I actually ran into this issue, too, with Google's code lab and Sparkfuns. I've been able to install the pre-compiled examples, but nothing custom.

@karma0

This comment has been minimized.

Copy link
Author

commented Apr 15, 2019

This failed me from two different computers with two different Edge boards. I'm running on Arch Linux on both machines. The only other commonality between these setups is that I'm using the same FTDI board.

Additionally, following the instructions here yield the same result: https://codelabs.developers.google.com/codelabs/sparkfun-tensorflow/#5

According to the troubleshooting section on the next page of the codelabs instructions, this is happening because I need to follow the "hold down the button marked 14 while running the script. Hold down button 14, hit the RST button, then run the script, while holding the button marked 14 the whole time."

Just to confirm: this is exactly what I'm doing.

@karma0 karma0 changed the title Not receiving Hello (0x00000000) response Sending Hello. No response for command 0x00000000 Apr 15, 2019

@karma0

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

@PaulTR there are no pre-compiled examples. The script tries to install bin/main_nonsecure_wire.bin on the device, and that is where this is failing. That file doesn't exist in the repository unless you build it using make bootload.

@oclyke

This comment has been minimized.

Copy link
Collaborator

commented Apr 16, 2019

Hi @karma0, @PaulTR,

@karma0 - since you're using a unix-like OS I wanted to double check that you've seen this: https://stackoverflow.com/questions/55463159/sparkfun-edge-bootloader-problems

Additionally I have found that if the executing code has a lot of serial communication that it can cause the bootloader to miss the initial reset request. To avoid this problem my upload sequence is:

  • press and hold button 14
  • press and release reset
  • start the uploader script (automatically toggles reset again)
  • let go of button 14
  • press reset again (gets the board into application mode)

Here's a simplified makefile that I wrote to simply upload a bin, and avoid any compilation (requires a binary file to upload)

SDKPATH	=# note: you need to fill this absolute path out for your system. 
BOARDPATH = ${SDKPATH}/boards/SparkFun_Edge_BSP#if this doesn't match your system please modify it
COM_PORT =#this too
BAUD_RATE = 921600#note: 921600 for Edge boards from SparkFun, 115200 for Edge boards received at the TensorFlow dev summit

BINUPLOADTARGET=SparkFun_Edge_Project_Template.bin

all: binupload
binupload:
	${SDKPATH}/tools/apollo3_scripts/create_cust_image_blob.py --bin $(BINUPLOADTARGET) --load-address 0xC000 --magic-num 0xCB -o main_nonsecure_ota --version 0x0
	${SDKPATH}/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin main_nonsecure_ota.bin -i 6 -o main_nonsecure_wire --options 0x1
	${BOARDPATH}/bsp/tools/uart_wired_update_sparkfun.py -b 921600 $(COM_PORT) -r 1 -f main_nonsecure_wire.bin -i 6

And here's a binary to try with it:
SparkFun Edge Project Template Binary

Please let me know how this turns out for you - we'd like to be able to solve this problem for everyone else too. And thank you a lot for taking the time to report this to us!

@genivia-inc

This comment has been minimized.

Copy link

commented Apr 16, 2019

I had the same problem and changed the Makefile to correct the baud rate that is by default 115200 but is set too high at 921600 in the Makefile:

../../../bsp/tools/uart_wired_update_sparkfun.py -b 921600  $(SERIAL_PORT) -r 1 -f $(CONFIG)/main_nonsecure_wire.bin -i 6

to:

../../../bsp/tools/uart_wired_update_sparkfun.py -b 115200  $(SERIAL_PORT) -r 1 -f $(CONFIG)/main_nonsecure_wire.bin -i 6
@karma0

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

Thanks for the help! Here's the output, seems identical:

make
AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_image_blob.py --bin SparkFun_Edge_Project_Template.bin --load-address 0xC000 --magic-num 0xCB -o 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 =   0xe53594b1
Writing to file  main_nonsecure_ota.bin
AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin main_nonsecure_ota.bin -i 6 -o main_nonsecure_wire --options 0x1
Header Size =  0x60
app_size  0x275c ( 10076 )
Writing to file  main_nonsecure_wire.bin
Image from  0x0  to  0x275c  will be loaded at 0x20000
AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.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  48
['0x82', '0xc5', '0xac', '0x80', '0x5', '0x83', '0x80', '0xd0', '0x84', '0x82', '0x80', '0x83', '0x80', '0x81', '0x80', '0xff', '0x5c', '0xf1', '0xff', '0x15', '0x80', '0x0', '0x80', '0x83', '0xf4', '0xaa', '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 "AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py", line 341, in <module>
    main()
  File "AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py", line 42, in main
    connect_device(ser)
  File "AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py", line 61, in connect_device
    response = send_command(hello, 88, ser)
  File "AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py", line 238, in send_command
    raise NoResponseError
__main__.NoResponseError
make: *** [Makefile:12: binupload] Error 1
@karma0

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

@genivia-inc thanks for the feedback. That is also something that I've tried. Running uart_wired_update_sparkfun.py by hand and passing the correct baud rate yields the 48 bytes response (and occasionally 11 bytes) no matter which bin file I try.

@oclyke

This comment has been minimized.

Copy link
Collaborator

commented Apr 16, 2019

I just ran that modified makefile to get some example output that you can target... I notice that after 'Sending Hello' I get 'Received Response' and 'length = 0x58' where in your output we're seeing 'received bytes 48'

That mismatch in length makes me think that the UART communication is off -- either by using the incorrect baud setting ( but you've tried both 115200 and 921600 if I recall correctly ) or the USB-serial bridge is misbehaving (possibly due to the same kind of driver issues as in the Stack Overflow post?).

Can you verify the accuracy of your UART output from the FTDI converter?

(p.s. the above makefile text is in MakeUpload.mk in the same directory as SparkFun_Edge_Project_Template.bin)

$ make -f MakeUpload.mk
C:/Users/owen.lyke/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_image_blob.py --bin SparkFun_Edge_Project_Template.bin --load-address 0xC000 --magic-num 0xCB -o main_nonsecure_ota --version 0x0
Header Size =  0x80original 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 =   0xe53594b1
Writing to file  main_nonsecure_ota.bin
C:/Users/owen.lyke/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/create_cust_wireupdate_blob.py --load-address 0x20000 --bin
main_nonsecure_ota.bin -i 6 -o main_nonsecure_wire --options 0x1
Header Size =  0x60
app_size  0x275c ( 10076 )
Writing to file  main_nonsecure_wire.bin
Image from  0x0  to  0x275c  will be loaded at 0x20000
C:/Users/owen.lyke/AppData/Roaming/AmbiqSDK/AmbiqSuite-Rel2.0.0/boards/SparkFun_Edge_BSP/bsp/tools/uart_wired_update_sparkfun.py -b 921600 COM4 -r 1 -f 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.
@karma0

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

FIXED!

Following the suspicion that there may be driver issues with Arch Linux, I was able to find some other people having similar issues with the Linux kernel built-in drivers with various knock-off Arduinos coming from China. That eventually led me to this project that overrides the Linux ch34x drivers and based on the vendor's drivers (which doesn't compile against kernels beyond 3.13.x ... Arch is currently at 5.0.7!!)

That being said, if you are getting the 48 bytes response, it's probably safe to say that the ch341 drivers are outdated and you need to find an alternative for your platform/distribution.

Thanks for the help! I'll leave it up to you if you want to close out this issue or leave it open for others to post their solutions.

@nseidle

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

Thanks karma0! This will be very helpful for many folks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.