I’ve implemented the DFU functionality, following the Updating ESP32 Host Firmware tutorial.
Based on the log messages it seemed that things were progressing as expected:
Until the following error was shown in the serial monitor:
{"req":"dfu.get","offset":405504,"length":4096}
{"err":"not currently in the DFU operating mode (see hub.set)"}
dfu: error on read: not currently in the DFU operating mode (see hub.set)
dfu: reading chunk (offset:405504 length:4096 try:2)
...
dfu: reading chunk (offset:405504 length:4096 try:5)
{"req":"dfu.get","offset":405504,"length":4096}
{"err":"not currently in the DFU operating mode (see hub.set)"}
dfu: error on read: not currently in the DFU operating mode (see hub.set)
dfu: unrecoverable error on read
Where do I go from here?
I’d appreciate if someone could point me in the right direction.
The Notecard DFU mode times out after 15 minutes (to prevent the risk of a Notecard left in DFU mode no longer communicating to Notehub) - is there a chance that 15 minutes had elapsed since the {"req":"hub.set","mode":dfu"}` ?
@seant Thanks for your quick reply.
Unfortunately I didn’t monitor the entire process, so I don’t have a time record.
As I saw that the update was successfully initiated I turned away from the monitor and when I came back later I noticed the error.
@seant I see that the data transfer started again and this time I was able to roughly time the beginning.
I’ll see how and when the process ends and I’ll get back to you with the results.
@LBBD If the binary transfer is taking more than 15 minutes to complete you may be able to restart the 15 minute timeout by issuing further {"req":"hub.set","mode":dfu"} requests periodically during the repeated {"req":"dfu.get"} requests. We are aware of the possibility of timeout of long transfers and in future Notecard firmware we restart the 15 minute timer on each dfu.get request.