SDK code is getting hanged in do-while loop with NRF_ERROR_NO_MEM

[Durgesh Tanuku]

Hi, I am beginner for nRF51822. We are using SDK v10 and S120.

We have an IOT Gateway with it's processor interfaced with nRF51822 radio through UART. We have flashed nRF51822 radio with ble_central application with our changes. The radio on Gateway connects to sensors and reads required data.

If there is a single sensor, the flow is working as expected as only single connection is established. If there are multiple sensors, the processor on GW is establing simultaneous connections (Maximum of 8) by sending ble_gap_connect request to the radio. Then multiple ble_gattc_read requests are being sent to read corresponding data from different sensors. In this scenario we have observed that radio code is getting hanged occassionally and not responding to further gattc_read commands.

I have tried to debug the issue by enabling RTT logs. Found that the code is getting blocked in do-while loop which is calling ser_hal_transport_tx_pkt_alloc().

do
{
err_code = ser_hal_transport_tx_pkt_alloc(&p_tx_buf, (uint16_t *)&tx_buf_len);
}
while (NRF_ERROR_NO_MEM == err_code);

ser_hal_transport_tx_pkt_alloc() was returning NRF_ERROR_NO_MEM as m_tx_state was set to HAL_TRANSP_TX_STATE_TX_TRANSMITTING. I have tried to understing state machine of m_tx_state. But couldn't figure out what was causing m_tx_state to stuck is single state.

What could cause this issue and had anyone faced similar issue ?

[Edvin]

Hello,

It looks like there are no free buffer space in the packet processing. It will probably return this from time to time. Are you sure that it is always stuck there, and that it doesn't eventually return NRF_SUCCESS, and then the next packet is returning NRF_ERROR_NO_MEM? 

It may also be that there simply are too many packets coming in. Can you, just for testing purposes, try to increase the connection interval from your application chip?

Best regards,

Edvin

[Durgesh Tanuku]

Hi Edvin,

Yes, It is always stuck there and not returning forever. 

I have increased the connection interval from 40ms to 128ms. Still no luck. Facing the same issue. 

Regards,

Durgesh

[Edvin]

Ok. Thank you for confirming.

What serial transport platform do you use for your serialization? Are the nRF and other µcontroller connected via SPI, UART or TWI?

If it is UART, is flow control enabled?

Best regards,

Edvin

[Durgesh Tanuku]

Hi Edvin,

Thanks for your suggestion. 

We are using UART and flow control was not enabled. I have enabled Hardware flow control in both application and host chips. But still facing the issue.

[Edvin]

Durgesh Tanuku said:

We are using UART and flow control was not enabled.

 

Ok. That was what I wanted to check, because if for some reason flow control was enabled, and the other chip doesn't allow the nRF to send the message. That doesn't seem to be the case.

I am looking a bit in the serialization project now. m_tx_state is only set to HAL_TRANSP_TX_STATE_TRANSMITTING on line 443 in ser_hal_transport.c.

Are you able to get any information on what message that is the last one that is set?

The two other places that HAL_TRANSP_TX_STATE_TRANSMITTING is used is in ser_hal_transport.c on line 115 and 260. in phy_events_handler(). Can you see if phy_events_handler is called after it is stuck in NRF_ERROR_NO_MEM? And if so, what type of event is it?

Best regards,

Edvin