peripheral uart sample: connecting causes permanent halting on background threads

When adding a low priority and delayed background thread to the peripheral uart sample, have issues where pairing with the device causes that background thread to halt and never run again.

In addition, whatever the advertising light is (LED1) never toggles again.

However, the system is still able to be paired with the nrf connect app, and still operates correctly. (UART to BLE, and BLE to UART)

It also still shows up as a connectable device after disconnecting when in this state, and can still be connected to and interfaced with.

When I attempted to debug by using the ncs debugger, the behavior is not replicable. (The system operates as intended)

Threads never get halted while attached to debugger. So I can't replicate the issue while attached to the debugger.

Logs in RTT didn't indicate anything was wrong either.

Unfortunately, I need some background threads to be able to run on top of this sample application.

Here is my thread insantiation and definintion

(500ms start delay, 1024 stack size, priority of 9.)

K_THREAD_DEFINE(some_thread_id, 1024, some_thread, NULL, NULL, NULL, 9, 0, 500);
The thread is simply
void some_thread(void)
{
  while(1)
  {
    toggle_led(LED4);
    uart_poll_out(uart1, 'e');
    k_msleep(K_1000_MS);
  }
}
using SDK 2.1.2 (also tried 2.1.0), and latest ncs.
  • Hi Johnny,

    Thank you for contacting DevZone at NordicSemi.

    So basically, you wanted to add a thread to peripheral uart sample.

    I started with peripheral uart example in NCS 2.1.2, 2.1.1, and 2.1.0 and it did not work properly on 52833DK (DK was rebooting).

    However, the same example in NCS 2.1.2, 2.1.1, and 2.1.0 worked properly on 52840DK without any modification. 

    Also, the same example in NCS 2.0.2 and 2.0.0 worked well on 52833DK. (There could be several reasons of a sample not working properly in a SDK for certain DK. I might not be aware about those.)

    So as a first thing, can you start with peripheral uart in 2.0.2 on 52833DK?

    Or if you have 52840DK then build and flash the same example using the latest (2.1.2) nCS.

    I continued with 52840DK, and was able to incorporate the thread and see all of the functionality.

    In the snapshot below, you can see that the thread is functional, and I am able to connect and disconnect and reconnect with the device. All of the LEDS were functioning properly as desired.

    So, can you try your project with nCS 2.0.2, or on 52840DK?

    Let me know accordingly.

    (P.S: I have limited 52833 availability)

    Regards,

    Naeem

  • Thank you for reaching out Naeem,

    My application no longer has this issue on SDK2.0.2

    I do not have access to an nRF52840.

    Our organization is pushing a product with nRF52833 and it is table stakes to use the 52833, so that is the platform the development needs to go on.

    If it is any insight, when the bug was occurring, I noticed that immediately within the entry of the background thread, context switching would occur, which makes me wonder if in the new SDK some IRQ is throttling things.

    Would be somewhere in ncs/version/zephyr/arch/arm/core/aarch32/swap.c/arch_swap(unsigned int) function.

Related