Is the peer functionality related to RTC?

[tony55723]

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

[Vidar Berg]

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

[tony55723]

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

[Vidar Berg]

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.

[tony55723]

Hello Berg,

In the main() function, LOG_INIT() is the first to be called.

I originally intended to count the interval time for repeated printing, but it was irregular. Sometimes it repeats printing after 10 seconds, and sometimes it takes over a minute before repeating.

This time, I won't use my phone to send data. After the device is powered on, I'll start RTT, and then I won't do anything else

The repetitive issue still occurred. Could you please assist me again? Thank you.

[Vidar Berg]

Hello,

Thanks for confirming. Can you also show your implementation of log_init()?

[tony55723]

Hello Berg,

I haven't modified log_init(), so I'm also puzzled why such an issue would occur.

[Vidar Berg]

Strange. You are also sure that the device is not rebooting? 

[tony55723]

I don't know if it executed a reboot or not.

data[1]" is a data I defined myself. The mobile app will send different data based on the UI button. But what I want to say is, this RTT seems to only record the last 4 sets of commands.

The left and right sides of the image respectively show the results of two tests. I clicked the UI button on the app several times, and there must be a lot of data in the RTT. However, I cleared the RTT view, then waited for it to repeat printing before capturing the effect.

[tony55723]

I'm really sorry, but it seems that there is no pattern in the RTT. I just thought it would output a maximum of four commands.

[Vidar Berg]

Sorry, I'm not sure I understand what you mean. Are you saying that you are not seeing duplicated log messages anymore?

[tony55723]

I can still see repeated logs. I just want to find a pattern (if there is one) to see if it can help with the issue.

Perhaps I should focus on addressing the issue from the warnings in the RTT logs?

<warning> ble_nus_c: Connection handle invalid.

[Vidar Berg]

It's a bit difficult for me to understand what the log is supposed to look like, as I'm not familiar with your application. However, I agree it could make sense to attempt to address the "Connection handle invalid" warning first.