h2zero
Soft reset when closing USB serial connection on micro:bit V2
I'm using n-able-Arduino and NimBLE on a micro:bit v2.
My application allows the user to open and close the USB serial port to communication with the board. With the board connected to the computer via a USB cable, I can connect and communicate with it over the serial port. However, when I close the serial port, the board does a soft reset. (_resetReason, which is read from NRF_POWER->RESETREAS at startup, is 4.)
I'd like it to simply continue running when the serial port is closed, as it does when I use Earle Philhower's Arduino framework.
I don't think it is the watchdog timer. I have that disabled and, anyhow, that would give a different reset reason.
Is some event my application should be handling? Other ideas?
Hi, thank you for bringing this up. I do not have any ideas at the moment as to the cause of this. I suspect the USB lib may need some tweaks somewhere, I would need to be able to reproduce this to find the issue,
Thanks for getting back to me so quickly.
I dug into this more deeply today and discovered that it is not specific to the n-able-Arduino framework; it also happens with Sandeep Mistry's arduinonordicnrf5 framework. It seems plausible -- perhaps even likely -- that this behavior is built into the firmware of the support chip. That chip may be toggling the nRF52 reset pin in response to the serial port being closed for some good reason.
On the micro:bit v2, I don't think the nRF52 interacts directly with the USB bus. I believe that is handled by the support chip.
You can close this issue. But please let me know (e.g. via a comment here) if you have any new insights about this.
Thank you!
isn't the v2 based on the nrf52833? In that case the usb is built into the mcu and there should not be a support chip, but i'm not familiar with that board.
They do use a support chip (see https://tech.microbit.org/hardware/schematic/). That chip provides a virtual USB disk drive as well as serial and it supports programming the chip by drag-and-dropping a hex file on the to MICROBIT virtual drive. Interesting, the V2.0 micro:bit used and NXP chip by the V2.2 version uses a second Nordic chip, an nRF52820. Guessing they made that switch due to shortages of the NXP chip.
Interesting, thanks for that. Lets hope there is a good reason for this behavior.