• State Not Answered
  • Replies 2 replies
  • Subscribers 94 subscribers
  • Views 537 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 295051
Options

Softdevice raise error SD_RPC_LOG_FATAL during long term test

Jason MP

Hi Everyone,

I am developing a PC App. with nrf52840 usb dongle (central) to communicate with nrf52840 BLE device (peripheral) on long term and transport data.
Everything looks normal at first, but the SD_RPC_LOG_FATAL error will occur above 24 to 48 hours suddenly.
The usb dongle gets stuck and can no longer be manipulated. I must restart the program completely. Or re-insert the dongle to recover.
It seems like SoftDevice crashed. It can't not recover by itself.
Is there any posible way can avoid it? Or any way to recover the usb dongle programmatically?

In addition, does sd_rpc_conn_reset equivalent to hardware reset programmatically?


- Note:
1. We have tried to not use sd_ble_gap_data_length_update, but it still happens.
2. We tried on both NORDIC PCA10059 and RAYTAC MDBT50Q-RX, but it still happens.
3. We tried v5 softdevice, but it still happens.
4. We also tried on different PC, but it still happens.

- About Conditions:
PC OS: Win 10
PC App.: .Net
pc ble driver: nrf-ble-driver-sd_api_v3-mt-4_1_4.dll
usb dongle code: connectivity_4.1.4_1m_with_s132_3.1.0.hex
usb device softdevice version: sd_api_v6

- And Error log is following:
1. Failure
[21:39:57.687] [BLE(None)] BleDongle Log::SD_RPC_LOG_INFO Info: Successfully opened COM22. Baud rate: 1000000. Flow control: none. Parity: none.
[21:39:57.687] [BLE(None)] Status: 6, message: Target Reset performed
[21:39:58.292] [BLE(None)] Status: 7, message: Connection active
.
.
.
[21:40:03.072] [BLE(COM22)] GAP Stop Scan, error info: 0x08
[21:40:03.075] [BLE(COM22)] MTU exchange request reply successfully, client_rx_mtu: 247
[21:40:03.081] [BLE(COM22)] Received an BLE_EVT_DATA_LENGTH_CHANGED event
[21:40:03.202] [BLE(COM22)] BleDongle Log::SD_RPC_LOG_FATAL Info: Error in SerializationTransport::eventHandlingRunner, bad allocation
...  ( get stuck )


2. Success
[21:15:52.946] [BLE(None)] BleDongle Log::SD_RPC_LOG_INFO Info: Successfully opened COM22. Baud rate: 1000000. Flow control: none. Parity: none.
[21:15:52.946] [BLE(None)] Status: 6, message: Target Reset performed
[21:15:53.550] [BLE(None)] Status: 7, message: Connection active
.
.
.
[21:16:02.070] [BLE(COM22)] GAP Stop Scan, error info: 0x08
[21:16:02.072] [BLE(COM22)] MTU exchange request reply successfully, client_rx_mtu: 247
[21:16:02.078] [BLE(COM22)] Received an BLE_EVT_DATA_LENGTH_CHANGED event
[21:16:02.184] <DEBUG> EventType: EVENT_TYPE_REGISTE, client_id: [00000005], Device MAC: C8:B9:14:D4:A3:FB
...

Parents
  • 0

    Hi,

    In addition, does sd_rpc_conn_reset equivalent to hardware reset programmatically?

    Yes, you can use sd_rpc_conn_reset() to trigger a soft reset of the nRF device. That is, sd_nvic__SystemReset() will be called. (See the reset behavior table for details on what that entails).

    Is there any posible way can avoid it? Or any way to recover the usb dongle programmatically?

    It is difficult to say without knowing what actually happened, and you would have to debug the nRF in order to (hopefully) find out about that. However, you wrote that re-starting your program si a way to recover, so that way I would think you could do the same also without restarting the program (that might involve doing a full reinitialization of the pc-ble-driver etc).

Reply
  • 0

    Hi,

    In addition, does sd_rpc_conn_reset equivalent to hardware reset programmatically?

    Yes, you can use sd_rpc_conn_reset() to trigger a soft reset of the nRF device. That is, sd_nvic__SystemReset() will be called. (See the reset behavior table for details on what that entails).

    Is there any posible way can avoid it? Or any way to recover the usb dongle programmatically?

    It is difficult to say without knowing what actually happened, and you would have to debug the nRF in order to (hopefully) find out about that. However, you wrote that re-starting your program si a way to recover, so that way I would think you could do the same also without restarting the program (that might involve doing a full reinitialization of the pc-ble-driver etc).

Children
Related
Terms of service