Failure in TFTP bootloader requiring USB upload

Question: Following a failed TFTP upload (see image below) I am forced to use a USB connection to flash with. Is there a way to avoid this?

Essentially what appears to happen is I have a failed load on and I end up in the "double tap" bootloader. From what I have gleaned in this mode it only accepts USB/USART connection.

Can this be changed to allow for TFTP?

My confusion:

1. I can ping the ethernet module

2. Whenever I use TFTP I have to issue a reset to the control to enter the bootloader so i don't understand why this state of double tap is functionally different

The scenario is that i'm trying to update systems that exist at a distance

 

Aside:

I'm not sure why the TFTP fails - by looking at the code below it appears sometimes there must be a delay in the communication as we start to see the blocks sending twice and the acks happening twice (apparently a common behaviour of tftp)

. It would appear that the TFTP server code is possibly written poorly but it is what I have to work with in OPENWRT. It appears that the problem is the checksum is bad on the controller side.

This is an intermittent problem and unpredictable. I control the TFTP server from afar but the TFTP server and controller are physically <30 cm apart and connected via ethernet.

So either solving why the TFTP fails or being able to still access the TFTP component after a failed upload enters the "breathing LCD" mode would be a fix.

The picture wasn't included but the response is as such from tftp
sent DATA <block: 132, size:512>
received ACK <block:131>
sent DATA <block 132: size:512>
received ACK <block:132>
sent DATA <block 133, size:512>
received ACK <block:132>
..... And so on (what you see is each block sent twice and ACKS returned twice but sometimes a block behind) ie. block 133 send but ack 132 response

at the end there is no ACK to the final block

sent DATA <block: 138, size : 346.
received Ack <block: 137>
sent DATA <block: 138, size : 346>
tftp: error received from server <Image check>
(code suggests a CRC fail)

Colin Ragush
Colin Ragush
87
| 0 0 0
Asked on 4/15/20, 4:32 PM
0
vote
160 Views

The picture wasn't included but the response is as such from tftp sent DATA received ACK sent DATA received ACK sent DATA received ACK ..... And so on (what you see is each block sent twice and ACKS returned twice but sometimes a block behind) ie. block 133 send but ack 132 response at the end there is no ACK to the final block sent DATA sent DATA tftp: error received from server

Colin Ragush
on 4/15/20, 4:39 PM

Your answer

Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!

Ask a Question

Keep Informed

About This Forum

This community is for professionals and enthusiasts of our products and services.

Read Guidelines

Question tools

61 follower(s)

Stats

Asked: 4/15/20, 4:32 PM
Seen: 160 times
Last updated: 4/15/20, 4:42 PM