Hub.log prevents Notecard from entering DFU mode

Troubleshooting
1

Sometimes I have significant issues getting the Notecard to go into DFU mode after an update file has completed downloading to the Notecard and is ready to be read by the host MCU.

The conditions that cause this to happen are as follows:

  1. Notecard is set to continuous mode for normal operation
  2. Request dfu.status from the Notecard and determine that mode is ready
  3. Call hub.log with a message indicating that an OTA update is about to begin
  4. Call hub.sync to sync the log message to Notehub
  5. Set the Notecard to DFU mode using {"req": "hub.set", "mode": "dfu"}
  6. Check if the Notecard is in DFU mode by calling {"req": "dfu.get", "length": 0} and determine whether or not the err key is present in the JSON response.

Steps (5) and (6) are repeated for a very long timeout period (15 minutes), and I constantly receive the following error message:

{'err': 'DFU mode is not yet fully active: connected (session open) {connected}'}

However, if I remove the hub.log call, DFU mode appears to enter relatively quickly (within 30 seconds).

Am I doing something wrong here? I designed a custom OTA update approach and would like to be able to send up log messages to help debug it, but it seems like there’s an issue where a queued log message prevents an open session from closing when calling {"req": "hub.set", "mode": "dfu"}.

EDIT: according to your documentation, DFU mode should be activated within 30 seconds of calling hub.set with "mode": "dfu":

Depending on in-progress communications on the Notecard, it may take up to 30 seconds after setting the device to dfu mode before it is ready to retrieve firmware. To ensure that the Notecard is in DFU mode, issue a dfu.get request and set the length argument to 0 . This will verify that the device is in DFU mode without attempting to retrieve firmware.

This does not seem to be true. How can I force quit a session and force the Notecard into DFU mode? If this happens in the field, I will be unable to perform OTA updates.

2

After some extensive testing, I’m 99% sure the issue occurs when hub.log is called, but does not sync before calling hub.set with mode: dfu. It seems that Notecard gets stuck trying to log the health message and keeps the session alive, but is for some reason unable to send the log message after mode: dfu is invoked.

I believe this is a bug that needs to be fixed, or at a minimum documented in your developer guide.

3

Hey @JordanAbacus welcome to the community and thanks for posting. Sorry for not responding sooner as well! One thing I would suggest adding between steps 4 and 5 is a hub.sync.status request and repeat this until you see a status message that includes {sync-end}. In addition, does your application require operating in continuous mode for any reason, or is that just the default you’d been working with, thus far. If you can switch to periodic, I would also do that to ensure that your sessions explicitly close after sync and before switching to DFU mode.

4

Thanks @bsatrom. Your workaround is in fact exactly what I decided to do. From initial testing, this seems to have done the trick–although I’m still a bit worried that in some scenarios (e.g., very poor cell service) that this bug might rear its ugly head in the field.

I’m using continuous mode primarily to minimize latency during the development process. We don’t have any challenging power requirements, so continuous mode seemed to be the right choice.

These devices will be placed in elevator shafts, so poor cell connectivity will be the norm. Do you recommend periodic mode in this case?

5

Hi @JordanAbacus
Thanks for reporting the issue - could you tell me what Notecard firmware version you are running so that I can try reproducing the issue ?
Thanks
Sean

6

@seant The latest LTU version 2.1.1.2013839

7

Thanks - I will try to recreate and then root cause.

8

Hi @JordanAbacus
I was unable to recreate the issue, despite numerous attempts.

{"req":"card.version"}
{"body":{"org":"Blues Wireless","product":"Notecard","version":"notecard-2.1.1","ver_major":2,"ver_minor":1,"ver_patch":1,"ver_build":2013839,"built":"Nov 11 2021 12:51:56"},"version":"notecard-2.1.1.2013839","device":"dev:864622040042752","name":"Blues Wireless Notecard","sku":"NOTE-NBNA500","board":"1.8","api":2}
{"req":"hub.get"}
{"mode":"continuous","host":"api.notefile.net","product":"xxxxx","device":"dev:864622040042752"}
{"req":"hub.log","text":"hello"}
{}
{"req":"hub.sync"}
{}
{"req":"hub.set","mode":"dfu"}
{}
<wait 30 seconds>
{"req":"hub.get"}
{"mode":"dfu"}

How big is the DFU file you’re transferring (not that this should have an effect, but just making sure my test case is representative) ?

It may be helpful if you can capture a trace from the Notecard when it fails to enter DFU mode. There are instructions here:

Thanks
Sean