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

[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.

[tony55723]

I made a significant discovery. After I extracted SDK 17.1.0 and placed it in a new folder, I believe the examples inside have been thoroughly tested by the official team. However, when I found the peripheral/uart example, compiled it, and downloaded it to the chip, I noticed that the RTT still had the issue of repetitive printing. Should we consider focusing on the hardware or perhaps the debugger?

[Vidar Berg]

I haven't experienced this issue here. I have a board with the nRF52811 and have tested it using the ble_app_uart pca10056e configuration. Please place a breakpoint at the beginning of main() and see if it is reached again after you start execution. This will help us determine whether the device is rebooting.

[tony55723]

The current breakpoint in this main() function has only been reached once.

Something very strange is happening. When I start debugging, I execute 'run', then I click 'stop', but the code window doesn't display the current position where it stopped. Then, I repeatedly click 'run' and 'stop', and only register R7 is changing in the left register window. Eventually, it ends up in NRF_BREAKPOINT_COND error.

I just discovered an issue: after starting debugging, it keeps running continuously without me clicking 'stop'. After about 10 to 15 minutes, it also ends up in NRF_BREAKPOINT_COND.

Additional note: During the 'run' period, my phone can scan and receive broadcast information from the device.

[Vidar Berg]

The Softdevice will raise an assert if you start and stop exection as it will break it's real time requirements. So, this is to be expected. The ble_app_uart will also attempt to enter System OFF mode (deep sleep) when the advertiser times out after 3 minutes. But it is not possible to enter System OFF when the chip is in debug interface mode, so this will also trigger an error. 

I see you are using an old Jlink version. Could you try to update your nRF command line tools package (https://www.nordicsemi.com/Products/Development-tools/nRF-Command-Line-Tools/Download) and see if that changes anything?

[tony55723]

I installed the new nRF command line tools, and it also asked me if I wanted to install J-Link 7.94e, to which I agreed.

The test results are divided into two sections, with the yellow text 'connection lost' in the middle. Above that is when 52811 is running. I connected and then disconnected with my phone, then after a short period of time, an 'app: Fatal error' occurred.

Below the yellow text is when 52811 is running. I didn't do anything, and after a short period of time, an 'app: Fatal error' also occurred.