The program stopped because of "Logs dropped".

[Chaoyue Ying]

I'm developing my application with nrf52832 and nrf SDK v17.

I'm testing my program.

After running for some time, Jlink output the following.

00> 
00> <debug> app:  AA CC 09 03 19 FF FF 75|.......u
00> 
00> <debug> app:  55                     |U       
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> <debug> app:  AA CC 0A 01 05 FF FF 01|........
00> 
00> <debug> app:  69 55                  |iU      
00> 
00> Logs dropped (640)
00> 

When the "Logs dropped" message was displayed, the program seemed to stop running, and no Bluetooth signal could be detected. The connected devices also showed that the connection had been lost.

[Vidar Berg]

Hello,

I recommend you try to reproduce this while in a debug session (if you are using Keil, segger embedded studio, or similar) and pause the debugger when this happens to check where the program hangs. Also if using the RTT backend, ensure the SEGGER_RTT_CONFIG_DEFAULT_MODE setting is not set to 2=> BLOCK_IF_FIFO_FULL in your sdk_config header.

Best regards,

Vidar

[Chaoyue Ying]

Hi,

I try again without debug session.In this test, I deliberately increased the log output volume so that it would display "Logs dropped".But this time the output look like this:

00> 
00> <warning> app: conn_handle:65535 peer_id:65535 type:0
00> 
00> Logs dropped (1)
00> 
00> <warning> app: conn_handle:65535 peer_id:65535 type:0
00> 
00> Logs dropped (1)
00> 
00> <warning> app: conn_handle:65535 peer_id:65535 type:0
00> 
00> Logs dropped (1)
00> 
00> <warning> app: conn_handle:65535 peer_id:65535 type:0
00> 
00> Logs dropped (2)
00> 
00> <warning> app: conn_handle:65535 peer_id:65535 type:0
00> 
00> Logs dropped (1)
00> 
00> <debug> app:  AA CC 0F 01 01 FF FF 07|........
00> 
00> Logs dropped (1)
00> 
00> <debug> app:  00 00 00 00 00 6E 55   |.....nU 
00> 
00>    |.....nU: PEER_ID:1,type:6
00> 
00> <warning> app: Backends flushed

After the "Backends flushed" message is output, the Bluetooth connection remains active, but the NUS service does not respond to any data transmission and no corresponding logs are generated.

If at this point the chip enters a "hard fault" state, yet the Bluetooth remains in a connected state.

Is this state normal? If not, how should I avoid this situation?(Closing the log module is a good approach, but I need more measures.）

[Vidar Berg]

Chaoyue Ying said:

After the "Backends flushed" message is output, the Bluetooth connection remains active, but the NUS service does not respond to any data transmission and no corresponding logs are generated.

If at this point the chip enters a "hard fault" state, yet the Bluetooth remains in a connected state.

Please pause the debugger when this happens and post a screenshot showing the CPU registers, dissasembly, and the code view. The Bluetooth stack will not be able to maintain a BLE connection if the program has entered the hardfault exception hanlder.