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)

• Comment
• Close
• Edit
• Delete

Sentry: Water Monitoring & Control Inc.

Sentry: Water Monitoring & Control Inc.

117

| 4 1 2

Asked on 4/15/20, 4:32 PM

0

vote

1226 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

Convert as an answer

Sentry: Water Monitoring & Control Inc.

on 4/15/20, 4:39 PM

Post