Artemis Nano upload failed

SPARK-X
21

Oops, I lost the response that I had in-progress. Anyway it was something like this:

I’m curious how the Apollo3 is able to send UART data between the buffer reset and the Hello response check. I expect that the auto-bootload circuit that is activated when the serial port opens (code below) should put the Apollo3 in ASB mode – no UART transmissions. Now I did measure an ~30 to 50 ms latency from sending UART data to it being available to the computer. So potentially enough UART data is queued up that comes in after the ‘reset_input_buffer’ method. However there is already the 100 ms delay - maybe it needs to be increased to 200 ms? However that gets near the maximum timeout of 250 ms that is configured in the bootloader and with som latency from computer->apollo3 it would be cutting it close.

        with serial.Serial(args.port, args.baud, timeout=0.5) as ser:
            #DTR is driven low when serial port open. DTR has now pulled RST low.

            time.sleep(0.005) #3ms and 10ms work well. Not 50, and not 0.

            #Setting RTS/DTR high causes the bootload pin to go high, then fall across 100ms
            ser.setDTR(0) #Set DTR high
            ser.setRTS(0) #Set RTS high - support the CH340E

            #Give bootloader a chance to run and check bootload pin before communication begins. But must initiate com before bootloader timeout of 250ms.
            time.sleep(0.100) #100ms works well

            ser.reset_input_buffer()    # reset the input bufer to discard any UART traffic that the device may have generated

            connect_device(ser, args, verboseprint)

I’m not sure what to suggest next for you… Your idea of skipping the Hello message might work - especially if you find some repeatable and unique pattern that you could scan for in the input stream.

22

I solved the problem by ignoring the response from the HELLO message (not skipping the message). I sent you a message yesterday with the details, please see: viewtopic.php?f=164&t=50481&start=15#p206414

Maybe you have missed the message.

Now I can upload new code without any problems.

Now I’m having the next problem that I can not get readings from a spectral sensor. I have opened another thread for this: viewtopic.php?f=164&t=50525

23

devfacet:
@asprenger : I’m struggling with similar issues ( viewtopic.php?p=206453#p206453 ) Can you explain your solution at viewtopic.php?p=206414#p206414 ? Did you recreate ambiq_bin2board on MacOS with those changes?

@devfacet

I have patched the Python version of ambiq_bin2board because I do not have the source for the MacOS binary. In my case it is located at: ~/Library/Arduino15/packages/SparkFun/hardware/apollo3/1.0.4/tools/ambiq/ambiq_bin2board.py

I guess it is doing the same thing.

My modification is a dirty hack and might only my useful in my specific situation. I’m not recommending this. At one specific point in the upload process ambiq_bin2board.py sends a HELLO message to the board. In my case the response message from the board was corrupted and the script terminated. From ambiq_bin2board.py you can see that the response does not matter, it is only used to verbose output. Therefore I sent the HELLO message but ignored the response. I needed to run the a couple of times but at one point it worked. Hope that helps!