# Hub.log prevents Notecard from entering DFU mode

**URL:** <https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589>\
**Category:** Troubleshooting\
**Created:** [January 2, 2022, 10:28pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589 "2022-01-02T22:28:31Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![JordanAbacus](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@JordanAbacus](https://discuss.blues.com/u/JordanAbacus)\
**Post date:** [January 2, 2022, 10:28pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/1 "2022-01-02T22:28:31Z")

</div>

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](https://dev.blues.io/notecard/notecard-walkthrough/host-firmware-update-requests/#ensuring-dfu-mode-is-active), 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.

---

<div class="post-metadata">

**Author:** ![JordanAbacus](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@JordanAbacus](https://discuss.blues.com/u/JordanAbacus)\
**Post date:** [January 6, 2022, 10:39pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/2 "2022-01-06T22:39:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bsatrom](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.blues.com/bsatrom/32/3_2.png) [@bsatrom](https://discuss.blues.com/u/bsatrom)\
**Post date:** [January 7, 2022, 8:19pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/3 "2022-01-07T20:19:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![JordanAbacus](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@JordanAbacus](https://discuss.blues.com/u/JordanAbacus)\
**Post date:** [January 7, 2022, 8:26pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/4 "2022-01-07T20:26:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![seant](https://avatars.discourse-cdn.com/v4/letter/s/df788c/32.png) [@seant](https://discuss.blues.com/u/seant)\
**Post date:** [January 7, 2022, 8:33pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/5 "2022-01-07T20:33:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![JordanAbacus](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@JordanAbacus](https://discuss.blues.com/u/JordanAbacus)\
**Post date:** [January 7, 2022, 8:44pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/6 "2022-01-07T20:44:38Z")

</div>

@seant The latest LTU version 2.1.1.2013839

---

<div class="post-metadata">

**Author:** ![seant](https://avatars.discourse-cdn.com/v4/letter/s/df788c/32.png) [@seant](https://discuss.blues.com/u/seant)\
**Post date:** [January 10, 2022, 8:34pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/7 "2022-01-10T20:34:43Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![seant](https://avatars.discourse-cdn.com/v4/letter/s/df788c/32.png) [@seant](https://discuss.blues.com/u/seant)\
**Post date:** [January 10, 2022, 11:32pm UTC](https://discuss.blues.com/t/hub-log-prevents-notecard-from-entering-dfu-mode/589/8 "2022-01-10T23:32:10Z")

</div>

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

```auto
{"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:

> [@How do I capture a trace information from Notecard?](https://discuss.blues.com/t/how-do-i-capture-a-trace-information-from-notecard/152?_ga=2.184720873.1759128715.1641836748-1490415665.1620405868):
>
> Trace information is a stream of messages that can be useful when looking to understand Notecard behavior. Blues Support often requests trace information when assisting customers with network connectivity questions. Network Sync Trace - Easy Mode Requires USB connection to Notecard Recent Chrome or Chrome-based browser Steps: Visit [In-Browser Terminal - Blues Developers](https://dev.blues.io/notecard-playground/) Follow the connection guide [here](https://dev.blues.io/build/quickstart/#connect-to-the-notecard) until you verify connection to Notecard Perform the trace by entering the follo…

Thanks  
Sean
