NRF52832 (PCA10040) hangs in BLE event handler routine or timer callback when printing

[tb4450]

Hello Community

I started with the example "ubluepy_temp.py" (see link below) and wanted to print out the values of the variables "id", "handle" and "data" in the handler "event_handler" (line 30).

https://github.com/micropython/micropython/blob/master/ports/nrf/examples/ubluepy_temp.py

I added print(id, handle, data) below the part with the global variable declarations so that I can see the values whenever an event like "CONNECT" occurs.

But the NRF52832 hangs when it tries to print anything within the event handler. I can see the first character appearing in the REPL and then it freezes.

And when it hangs it needs a hard reset. Although it seems that the BLE stacks is still working in the background for some time.

The same happens when trying to print something in a callback of a timer instance.

The only thing that I changed for building the binary was to set RX und TX to pins 17 and 18 using board PCA10040 configuration. The actual board I use is a minimal commercial beacon from china repurposed.

In general the REPL works fine. BLE works as well. I can connect and read and write to characteristics. That seems to be all fine.

When I try to print in the event handler or in a timer callback on a NRF52840 it seems to work. I am using the SEEED XIAO nRF52840 Sense with the firmware as it can be found in the downloads section of micropython as comparison.

Do I miss anything here? Maybe it's the MICROPY_CONFIG_ROM_LEVEL_BASIC_FEATURES set that has limitations like this?

Thank you

[rkompass]

Did you follow this discussion?
@cwalther mentioned his PRs that might be relevant for your case. Just a guess.

[cwalther]

There is a problem on the nRF52832 where it would get stuck after one character when trying to print from a pin interrupt handler. This is fixed in #13368. Your problem may be related. I’m not familiar (yet) with ubluepy or Bluetooth in general. Do you know whether that event handler runs in an interrupt? If so, the same fix may work.

[tb4450]

Thank you for hinting me in that direction. I will try and see what I can find out and let you know.

[tb4450]

I will look into this interrupt handler issue. But I need to learn more about how this all (interpreter, softdevice, c, nrfx etc.) fits together.

The nRF52840 uses USB CDC so it's a different thing.

Just by looking over the source code (without really understanding how it works) I saw and guessed that the nRF52840 is using an even higher priority of 2. See line 65. Could it be?

micropython/ports/nrf/drivers/usb/usb_cdc.c

Line 65 in 4a2e510

NRFX_IRQ_PRIORITY_SET(USBD_IRQn, 2);

S132 and S140 seem to use the same interrupt levels (0, 1, 4) according to here:

• https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html
• https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html

I will recompile and try what happens when raising priority (lowering number).

[tb4450]

I have set config.interrupt_priority = 5 in ports/nrf/modules/machine/uart.c and printing in that event handler seems to work.

Here is the description of the use of interrupts by the softdevice:

• Level 0 is used for the SoftDevice's timing critical processing.
• Level 1 is used for handling the memory isolation and run time protection, see Memory isolation and runtime protection.
• Level 4 is used by higher-level deferrable tasks and the API functions executed as SVC interrupts.

Also the diagram https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/Images/exception_model_s132.svg suggests that priorities 2, 3, 5, 6 and 7 are available for the application.

I just checked timer.c to see which priority is set there - it's 6 for other than NRF51.

I have no idea what the thinking is about the priorities within Micropython?

[tb4450]

The issue can be fixed by changing the interrupt priority as cwalther pointed out.

But in general, I think, there needs to be more thought about which priorities should be used for what and where.