Hi @uhrheber ,

I can imagine 3 options for this target board,

1. Keep current DFU and provide BLE REPL using a softdevice (very close to pca10056+s140)
2. Keep current DFU and provide UART hooks to CDC ACM (needs quite some work)
3. Wipe the whole chip and treat it as any other target in the port, using an external debugger and external UART-to-USB converter to get REPL over UART towards a PC.

I'm not sure myself what is best for this target, but from what i'm thinking, option 3 would probably be the most generic option as it does not depend on any other external tools than the one used for the external debugger (JLink/DAP) which other targets are already using. Would any of these option be close to how you want to use the dongle?

4. Keep DFU and implement CDC ACM and virtual drive, like circuitpython has done it.

some progress / news?

I guess this requires a USB driver for the nrf port. One option would be to pull in tinyusb https://github.com/hathach/tinyusb (see also @tannewt fork https://github.com/tannewt/tinyusb). @glennrub an ideas on an approach to use?

I'm happy to help integrate TinyUSB if you need.

My fork is a little stale. The best source is hathach's develop branch here: https://github.com/hathach/tinyusb/tree/develop

The best source is hathach's develop branch here

Great, thanks. Does it require any low-level HAL drivers, or does TinyUSB sit right on top of the hardware registers?

It has nrfx as a submodule but writes to the registers directly. The meat of the code is here: https://github.com/hathach/tinyusb/blob/develop/src/portable/nordic/nrf5x/dcd_nrf5x.c

I vote for option 3. The dongle has exposed pins for SWDCLK and SWDIO so it can easily be programmed with OpenOCD and Raspberry Pi (nothing else required). Any chance of getting prebuilt binaries added to the micropython.org download page?

I did some work on this a few weeks back, integrating the tinyusb stack and adding the pca10059.
Current working branch: https://github.com/glennrub/micropython/tree/pca10059_tinyusb

I'll wrap this up and make a PR of this soon. I've got two things i'll need to sort out first.

• Remove my redundant copy a May19 snapshot of tinyusb, migrating over to the lib-submodule version.
• Test the SoftDevice integration of tinyusb with the ble_drv.c when softdevice is enabled/disabled.

@glennrub looks like a good start! You may also want to look at using ports/samd/tusb_* as templates for the nrf version.

Thanks @dpgeorge for the pointer. I have now used your configuration as base. I have some questions around the descriptor values, but we can take those in the review of the PR.

When it comes to a PR, i'm closing in on it. USB CDC with SoftDevice is now functional. I'm having some issues around something i suspect is a volatile bug when optimizing the code with LTO and SoftDevice is present, the power/USB events starts to become missing even before the SoftDevice is enabled. I'll have to investigate this a bit further before i do the PR as my workaround hack only works in LTO=0 DEBUG=1 compilation.

@glennrub I don't know if will help, but here's our power event initialization in nrf CircuitPython, done by @hathach: https://github.com/adafruit/circuitpython/blob/master/ports/nrf/supervisor/usb.c.

Thanks @dhalbert. It is basically the same code as in the nrf5x board sample provided in @hathach's repository which i based it on. The line that seems to be problematic is this one:
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/supervisor/usb.c#L85

When the SoftDevice is present (disabled), it seems that the state of POWER_USBREGSTATUS_OUTPUTRDY is not set. Busy looping over this mask until it is set, then issue the call tusb_hal_nrf_power_event(NRFX_POWER_USB_EVT_READY); makes it work. But only in LTO=0 DEBUG=1. In case of no SoftDevice present, i do not need such busy loop.

Busy loop code

I'm not sure what to suspect here, but i also have very weak light on my LED's, and two of the RGB pins does not trigger any action. So, i hope this correlates in the end.

Edit: Added link to busy loop code.

Ah, very weak light on the LEDs is a voltage setting issue in UICR!
See here: adafruit#1174 and here: https://github.com/adafruit/circuitpython/blob/95d2694bc33eddba991abcff1d9b2aba5675c622/ports/nrf/supervisor/port.c#L60

Also, we have had trouble getting LTO to work on the nrf builds: if we enable it, we get empty output files. It seems to be some issue with chains of reference, maybe from the ISR vector : adafruit#1396. But this may be unrelated to your issue.

Ah, very weak light on the LEDs is a voltage setting issue in UICR!

Awesome @dhalbert, that did the trick! Thank you so much. You saved me quite a few hours debugging this one.

I ended up with a UICR recovery function of UICR->REGOUT0 for pca10059 explicitly, and that worked like a charm.
https://github.com/glennrub/micropython/blob/pca10059_tinyusb/ports/nrf/boards/pca10059/modules/recover_uicr_regout0.c

@glennrub is there any more progress on getting the USB working on the nRF52840? It'd be nice to get this feature merged. I have a Xenon board with this MCU that I can test it with.

@dpgeorge , I have it in working state, but did not do a PR because i have a tiny issue. In case of SD being present, i am forced to enable it to get the USB events. I really wanted to fix that issue before a PR, but it is not really a big blocker to play with the device. I'll do a PR of what i have, and works without SD for now.

The hack i did was to do enable SD before usb_cdc_init() in main.c and it worked with BLE. But i'm not to happy with this solution.

You have my vote for a build without SD, there's a chance we may want to use nimble for bluetooth on nrf's soon instead of the SD for compatibility with stm32 port and to avoid the interrupt / event issues SD often presents!

want to use nimble for bluetooth on nrf's soon instead of the SD

Yeah, that makes sense =)

I also forgot to link the PR #5112 up against this issue.

Closing this issue as PR #5112 adding initial support has been merged.