Is the peer functionality related to RTC?

Hello Nordic Engineer,

I used nRF52811

nRF5_SDK_17.1.0_ddde560 \ examples \ ble_central_and_peripheral \ experimental \ ble_app_multirole_lesc

After attempting to add NUS, NUS_C, and deleting PEER, and porting to 52811, I encountered an RTC error when running the final RTT.

The following image shows the modifications I made for porting to 52811

<sdk_config.h>
UART_LEGACY_SUPPORT     0
NRF_BLE_LESC_ENABLED    0
NRF_BLE_LESC_GENERATE_NEW_KEYS  0
NRF_CRYPTO_RNG_STATIC_MEMORY_BUFFERS_ENABLED    0
NRF_CRYPTO_RNG_AUTO_INIT_ENABLED    0
PM_LESC_ENABLED 0

<main.c>
delete --->  err_code = nrf_ble_lesc_request_handler()

Since I don't require the LESC functionality, I hope to have the same connection method as the peripheral UART example.

This is probably all the changes I made. How should I solve the RTC issue?

Thanks

Parents
  • Hello,

    The assert is likely unrelated to the RTC. You can try placing breakpoints in main() to determine where the assert was triggered. E.g., if the crash is occuring before or after ble_stack_init().

    Best regards,

    Vidar

  • Hello Berg,

    Thank you for your reply.

    I attempted debugging, not sure if it helped to resolve the issue?

    Normally, after executing line 1147 of code, line 1149 should be executed, but there's an issue.

    Currently, debugging is paused at line 1126 of the code because there is a yellow arrow to the left of the number 1126. When I continue running the program, it should proceed to line 229, but it doesn't. Instead, it enters 'NRF_BREAKPOINT_COND'.

    Another question: why can't I see the value of 'err_code' in 'watch1'?

    Thank you

Reply
  • Hello Berg,

    Thank you for your reply.

    I attempted debugging, not sure if it helped to resolve the issue?

    Normally, after executing line 1147 of code, line 1149 should be executed, but there's an issue.

    Currently, debugging is paused at line 1126 of the code because there is a yellow arrow to the left of the number 1126. When I continue running the program, it should proceed to line 229, but it doesn't. Instead, it enters 'NRF_BREAKPOINT_COND'.

    Another question: why can't I see the value of 'err_code' in 'watch1'?

    Thank you

Children
  • Hello,

    Yes, this helps narrow down the problem. Please post the register values when you reach line 1126. The error_code is not placed on the stack when code optimization is enabled (hence the 'not in scope' message), which I guess you need to have on due to memory constraints.

    Best regards,

    Vidar

  • Hello,

    Yes, thanks. So, the error code is stored to register r0 and is 4. This corresponds to NRF_ERROR_NO_MEM. It's likely returned by the sd_ble_uuid_vs_add() call in ble_nus_c_init() due to NRF_SDH_BLE_VS_UUID_COUNT not matching the number of 128-bit UUIDs used by your application.

    To fix this, you can increase the NRF_SDH_BLE_VS_UUID_COUNT in your sdk_config.h header. Since this increases the size of the UUID buffer in the Softdevice, you will also likely need to increase the APP RAM base address to free more RAM to the Softdevice. Increasing it with 16-20 bytes should be sufficient.

  • Hello Berg,

    Thank you very much, the issue has been resolved.

    As per your suggestion, I've modified the definitions and increased the RAM.

    #define NRF_SDH_BLE_VS_UUID_COUNT 1

    RAM Start address: 0x20002AAC

    RAM Size:  0x3554

    But there's something strange, why does RTT print the information repeatedly?

    Firstly, I connect using my phone and 52811, then I send the first 20-byte array. After that, I send another 20-byte data. At this point, I see RTT printing normally. I then confidently end the app on my phone, including killing it from the background. RTT subsequently prints 'disconnect'. So far, everything is normal, and I haven't used my phone afterward.

    Later, I observed the RTT viewer and found that it keeps outputting the recent events. How should I address this issue?

    Thank you

  • Hello,

    I'm glad to hear that it fixed the problem. Regarding the duplicated log messages, are you initializing the logger at the very beginning of main()? I have seen instances where the log has been duplicated when LOG_INIT() was called too late.

Related