I am integrating BG95 with Nrf52 and have been able to achieve the a basic serial communication, but for a stable application code to handle all the AT commands, I need a communication interface port like the one that exists here for st, sierra and u-blox.
I was wondering if someone has already done the porting of cellular interface for nordics, and I could get a head start.
I do not understand the issue here, the xQueueReceive is called twice from prvProcessReceivedCommands. At once it return OK as shown in the traces but then the xQueueReceive is called a second time it returns errQUEUE_EMPTY (/* The queue was empty and no block time is specified (or the block time has expired) so leave now. */)
Any help on this would be much appreciated, thanks.
The AT commands of BG95 and BG96 are very similar.
We have tested on the BG95 EVB board with firmware version BG95M1LAR02A02_01.002.01.002.
After applying the patch below, the windows simulator demo project of BG96 can run with this BG95 EVB in our environment.
We suggest updating the BG95 firmware to the latest. In the past we did see more incompatibility between BG96 and BG95. But after updating firmware the difference narrowed, and we were able to make it work by just applying the patch below to the BG96 library.
The prvProcessReceivedCommands function is in the FreeRTOS kernel. It’s hard to root cause the problem by looking at the log you provided above.
We suggest you reuse the BG96 code with the patch first. If that doesn’t work, can you please enable the debug log in the cellular library, reproduce the issue then send us the log? Here is how to enable the log:
15 32014 [Cellular_Thread] [ERROR] recvdMsgType is AT_UNDEFINED for Message: ATE0, cmd NULL
The reason why message ATE0 is regarded as AT_UNDEFINED is previous ATE0 command timeout. The command sending status is cleared after timeout. So the library
will regard the “ATE0” message as AT_UNDEFINED since no command is sending now.
From your log, command response is received but not within command timeout.
We can focus on why the message is not received within timeout.
A brief receive path is listed below.
The reader thread in FreeRTOS-Cellular-Interface registers the RX callback function with the comm interface open API.
/* Open main communication port. */
if( ( pContext->pCommIntf != NULL ) &&
( pContext->pCommIntf->open( _Cellular_PktRxCallBack, ( void * ) pContext,
&pContext->hPktioCommIntf ) == IOT_COMM_INTERFACE_SUCCESS ) )
Once data is received from comm interface. Comm interface should call the callback function passed as soon as possible. The callback function will wake up the reader thread.
The reader thread calls comm interface receive function. The comm interface receive function should return the data as soon as possible.
The reader thread parses the data received and send command response to wake up the thread who is waiting for the command response. The message should be received within command timeout.
Something we can do to help debugging this issue.
Use windows simulator to test with your sara u-blox u270 modem. Windows simulator only need a COM port with the cellular module. It will help to locate the problem.
Add more log to help debugging why the message not received within timeout.
For example, the following log combined with your previous log and timestamp can help to indicate timeout time and message received time. Increase the timeout should have different result.
/* Wait for a response. */
/* This is platform dependent api. */
/* coverity[misra_c_2012_directive_4_6_violation] */
LogError( ( "Waiting for packet response %u.", timeoutMS ) );
qRet = xQueueReceive( pContext->pktRespQueue, &respCode, pdMS_TO_TICKS( timeoutMS ) );
LogError( ( "Packet response received %d.", qRet ) );
if( qRet == pdTRUE )
pktStatus = ( CellularPktStatus_t ) respCode;
The root cause for the reproduced problem is that command timeout is 100ms but the time comm interface notify the cellular modem is longer than 100ms.
Increase the AT command timeout or shorten the comm interface response time can solve this problem.
Hope these information can help to locate the problem.