Hi,
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.
Kind regards,
I don’t think so, but it would be nice to have. There is a porting guide here Cellular Library Porting Guide - FreeRTOS but probably not what you are looking for. Note these instructions tell you how to grab the latest from the FreeRTOS Labs repo.
Hi,
Thanks for responding back.
I’m trying implement the port. I get a timeout on the _Cellular_TimeoutAtcmdRequestWithCallbackRaw, could you suggest what might be going wrong here. Here is the log
> <info> app: UART SEND, length:5
> <info> app: 41 54 45 30 0D |ATE0.
> [ERROR] [CELLULAR] [_handleMsgType:726] recvdMsgType is AT_UNDEFINED for Message: ATE0
> <info> app: Buffer Length 1600
> <info> app: RX RECEIVE, length:6.
> <info> app: 0D 0A 4F 4B 0D 0A |..OK..
> <info> app: Buffer Length 1600I 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.
Hi Ukhan717,
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.
You can run the BG96 demo (Lab-Project-FreeRTOS-Cellular-Demo/projects/bg96_mqtt_mutual_auth_demo at main · FreeRTOS/Lab-Project-FreeRTOS-Cellular-Demo · GitHub) after applying this patch:
$ git diff modules/bg96/cellular_bg96.c
diff --git a/modules/bg96/cellular_bg96.c b/modules/bg96/cellular_bg96.c
index 718d88a..b6b3e8e 100644
--- a/modules/bg96/cellular_bg96.c
+++ b/modules/bg96/cellular_bg96.c
@@ -233,6 +233,7 @@ CellularError_t Cellular_ModuleEnableUE( CellularContext_t * pContext )
cellularStatus = sendAtCommandWithRetryTimeout( pContext, &atReqGetNoResult );
}
+#if 0
if( cellularStatus == CELLULAR_SUCCESS )
{
/* Configure Band configuration to all bands. */
@@ -275,6 +276,7 @@ CellularError_t Cellular_ModuleEnableUE( CellularContext_t * pContext )
}
cellularStatus = sendAtCommandWithRetryTimeout( pContext, &atReqGetNoResult );
}
+#endif
if( cellularStatus == CELLULAR_SUCCESS )
{
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:
Change LOG_INFO to LOG_DEBUG.
I am having the exact same issue but with the stm32F205 & sara u-blox u270, was the issue resolved or is it still persistent ?
This is what im receiving back from my log
12 32008 [Tmr Svc] [ERROR] pkt_recv status=1, AT cmd ATE0 timed out
13 32008 [Tmr Svc] [DEBUG] <<<<<Exit sending [ATE0] status[1]<<<<<
14 32014 [Cellular_Thread] [DEBUG] AT Read 11 bytes, data[0x2000519d]
15 32014 [Cellular_Thread] [ERROR] recvdMsgType is AT_UNDEFINED for Message: ATE0, cmd NULL
16 32014 [Cellular_Thread] [DEBUG] _handleMsgType failed 6
Hi Adam,
From your log,
12 32008 [Tmr Svc] [ERROR] pkt_recv status=1, AT cmd ATE0 timed out
13 32008 [Tmr Svc] [DEBUG] <<<<<Exit sending [ATE0] status[1]<<<<<
The ATE0 command timeout.
14 32014 [Cellular_Thread] [DEBUG] AT Read 11 bytes, data[0x2000519d]
15 32014 [Cellular_Thread] [ERROR] recvdMsgType is AT_UNDEFINED for Message: ATE0, cmd NULL
16 32014 [Cellular_Thread] [DEBUG] _handleMsgType failed 6
After 6 ticks, the ATE0 command response is received.
Assuming your are use the sara-r4 module code as base code.
Usually modem responses to ATE0 pretty fast. The default timeout value for ATE0 is 2000 ms ,which is long enough.
It looks like the comm interface is working, but receive function doesn’t return data not fast enough.
You can try to increase the timeout to see if the response can be received.
https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface/blob/main/modules/sara_r4/cellular_r4.c#L40
If this is the problem, you may update the comm interface receive function to return data as soon as possible instead of waiting for the timeout or buffer full.
Even after increasing the delay, it still returns the same message, should the recvdMsgType be AT_UNDEFINED for ATE0
Hi Adam,
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.
/* 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.
( void ) pContext->pCommIntf->recv( pContext->hPktioCommIntf, ( uint8_t * ) pRead,
bufferEmptyLength,
CELLULAR_COMM_IF_RECV_TIMEOUT_MS, &bytesRead );
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.
cellular_pkthandler.c#L239
/* 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 timeout setting in my previous reply is not correct.
This is the correct config to change the first ATE0 command timeout.
Previous setting is used to reboot the device and waiting for device ready.
This is my mistake.
I also try to reproduce your problem with FreeRTOS windows simulator with the following patch.
FreeRTOS-Cellular-Interface
diff --git a/modules/sara_r4/cellular_r4.c b/modules/sara_r4/cellular_r4.c
index f0778d5..3e5d07f 100644
--- a/modules/sara_r4/cellular_r4.c
+++ b/modules/sara_r4/cellular_r4.c
@@ -356,7 +356,9 @@ CellularError_t Cellular_ModuleEnableUE( CellularContext_t * pContext )
{
/* Disable echo. */
atReqGetWithResult.pAtCmd = "ATE0";
- cellularStatus = sendAtCommandWithRetryTimeout( pContext, &atReqGetWithResult );
+ _Cellular_TimeoutAtcmdRequestWithCallback( pContext, atReqGetWithResult, 100U );
+ vTaskDelay( pdMS_TO_TICKS( 5000 ) );
+ // cellularStatus = sendAtCommandWithRetryTimeout( pContext, &atReqGetWithResult );
if( cellularStatus == CELLULAR_SUCCESS )
{
FreeRTOS
diff --git a/FreeRTOS-Plus/Demo/FreeRTOS_Cellular_Interface_Windows_Simulator/Common/comm_if_windows.c b/FreeRTOS-Plus/Demo/FreeRTOS_Cellular_Interface_Windows_Simulator/Common/comm_if_windows.c
index 748a68af2..663b2dbfa 100644
--- a/FreeRTOS-Plus/Demo/FreeRTOS_Cellular_Interface_Windows_Simulator/Common/comm_if_windows.c
+++ b/FreeRTOS-Plus/Demo/FreeRTOS_Cellular_Interface_Windows_Simulator/Common/comm_if_windows.c
@@ -75,7 +75,7 @@
( COMMTASK_EVT_MASK_STARTED \
| COMMTASK_EVT_MASK_ABORT \
| COMMTASK_EVT_MASK_ABORTED )
-#define COMMTASK_POLLING_TIME_MS ( 1UL )
+#define COMMTASK_POLLING_TIME_MS ( 1000UL )
/* Platform thread stack size and priority. */
#define COMM_IF_THREAD_DEFAULT_STACK_SIZE ( 2048U )
I can observe similar log.
12 11 [CellularDemo] [DEBUG] [Cellular] [_Cellular_AtcmdRequestTimeoutWithCallbackRaw:224] >>>>>Start sending [ATE0]<<<<<
13 111 [CellularDemo] [ERROR] [Cellular] [_Cellular_AtcmdRequestTimeoutWithCallbackRaw:254] pkt_recv status=1, AT cmd ATE0 timed out
14 111 [CellularDemo] [DEBUG] [Cellular] [_Cellular_AtcmdRequestTimeoutWithCallbackRaw:262] <<<<<Exit sending [ATE0] status[1]<<<<<
15 1011 [Cellular_Threa] [DEBUG] [Cellular] [_Cellular_ReadLine:583] AT Read 11 bytes, data[00659EE1]
16 1011 [Cellular_Threa] [ERROR] [Cellular] [_handleMsgType:724] recvdMsgType is AT_UNDEFINED for Message: ATE0, cmd NULL
17 1011 [Cellular_Threa] [DEBUG] [Cellular] [_handleAllReceived:971] _handleMsgType failed 6
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.