_Cellular_HandlePacket() > _processUrcPacket() -> urcParseToken() uses the strtok_r() function, and uses its saveptr, which isn't intended to be used by the caller.

The function even seems to use the same variable for both str and saveptr.
The intended end result seems to be a null-terminated pTokenPtr containing the URC keyword, and pSavePtr containing the arguments to be consumed by the URC handler.

It's probably best that such string manipulation be implemented directly.

I use a connectiivitiy module with this cellular lib.
I met a trouble about getting IP address when using SIM card that supports both IPv4 and IPv6.

Cellular_GetIPAddress function only gets IPv4 address when using both IP protocol.
The module returns below IP data. The first one is IPv4, and second one is IPv6.
"111.112.113.114","1111.2222.3333.4444.5555.6666.7777.8888"

However, Cellular_GetIPAddress function only get "111.112.113.114" of IPv4.

The cellular_comm_interface, which handles low level transfers between the modem and the cellular library, has provisions to report errors on receive / transmit (ie. caused by buffer overruns, etc.)

However, the pktio layer currently disregards this status information

It would be beneficial if the errors on the low-level layer could be propagated back to the user API.

Congrats on the v1 release!

I noticed that examples/demos are missing from the documentation. I believe this repo is supposed to be the demo application for this library. It would be nice to link to it in the readme.

The task that is created in cellular_pktio on a Cellular_Init call is never deleted on Cellular_Cleanup/_Cellular_PktioShutdown.

SIM800C has a fun little command called AT+CIFSR

This command does not provide any status information when it succeeds

Which is an issue, since it's mandatory to call as a workaround to make Multi-IP TCP/IP start correctly

And now I'm a bit stuck, because all CellularATCommandType_t options seem to expect some form of status information, otherwise the library reports timeout.

Any way to handle this case?

In cellular_hl7802_api.c on line 1080, the function _parseSignalQuality calls _Cellular_ConvertCsqSignalRssi and passes the second argument as "berValue", whereas the function expects raw RSSI as "pRssiValue".
On line 1066, the first token (which is actually the RSSI value) is deliberately skipped.
In effect, it skips RSSI and miscalculates BER.

Most of the implementations I've seen of this interface are like FreeRTOS-Cellular-Interface-Reference-Quectel-BG96/source/cellular_bg96_urc_handler.c where an array of CellularAtParseTokenMap_t is defined using functions like Cellular_CommonUrcProcessCereg from cellular_common_api.h:

CellularAtParseTokenMap_t CellularUrcHandlerTable[] =
{
    { "CEREG",          Cellular_CommonUrcProcessCereg },
    { "CGREG",          Cellular_CommonUrcProcessCgreg },
    { "CREG",           Cellular_CommonUrcProcessCreg  },
    { "POWERED DOWN",   _Cellular_ProcessPowerDown     },
    { "PSM POWER DOWN", _Cellular_ProcessPsmPowerDown  },
    { "QIND",           _Cellular_ProcessIndication    },
    { "QIOPEN",         _Cellular_ProcessSocketOpen    },
    { "QIURC",          _Cellular_ProcessSocketurc     },
    { "QSIMSTAT",       _Cellular_ProcessSimstat       },
    { "RDY",            _Cellular_ProcessModemRdy      }
};

If you look at CellularAtParseTokenHandler_t, however, you'll see it's defined as a function pointer to a function that does not return a value whereas Cellular_CommonUrcProcessCgreg returns a CellularError_t. Are the implementations wrong to use this function in this manner or is there a flaw in the interface design?

When testing our code we noticed a 96 byte memory leak when initializing/deinitializing the cell library. I tracked it down to the 96 bytes that is malloced when it's creating the queue (pktRespQueue) by calling _Cellular_PktHandlerInit. The function _Cellular_PktHandlerCleanup is written to remove this queue, but it is only called by libOpen if it fails to initialize. I've added _Cellular_PktHandlerCleanup to line 324 in the function libClose to correct the issue.

Problem

By building the library with arm-none-eabi-gcc compiler and setting the flag -Werror, the library is producing the following warnings (errors) due to the use of wrong format specifier in the log traces... We have the goal to deliver a warning-free software for our next firmware release.

PS: Thank for your job and for this library, you are awsome 👍

The correction is very simple, use %lu instead of %u, use %ld instead of %d.

Awaited result

New release of the library implementing the correction above and no more warning generated.

List of reported errors:

• cellular_common.c:602:20 error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'}
• cellular_common.c:655:25: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_common_api.c:110:25: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_common_api.c:126:25: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_common.c:919:25: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_3gpp_api.c:492:21: error: format '%d' expects argument of type 'int', but argument 2 has type 'int32_t' {aka 'long int'} [-Werror=format=]
• cellular_pktio.c:145:17: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pkthandler.c:823:29: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:177:17: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pkthandler.c:823:29: error: format '%d' expects argument of type 'int', but argument 3 has type 'int32_t' {aka 'long int'} [-Werror=format=]
• cellular_pktio.c:186:17: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
• cellular_pkthandler.c:839:25: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:549:17: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:620:25: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:673:21: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:673:21: error: format '%d' expects argument of type 'int', but argument 5 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:673:21: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:888:25: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:888:25: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:1029:21: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
• cellular_pktio.c:1430:17: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]

Hi, I am using this cellular interface lib, but I faced an issue of below.

The log message showed No empty space from comm if to handle incoming data, reset all parameter for next incoming data.

After I changed PKTIO_READ_BUFFER_SIZE of definition value to 4096, it was solved.

• Question

  • Is the size of PKTIO_READ_BUFFER_SIZE TCP window size?

  It has comment of This should be larger than TCP packet size., but I think it is window size of TCP. Is my understanding correct?

• Request

  • Is it possible to add (#ifndef PKTIO_READ_BUFFER_SIZE) to be possible the configuration by the config.h file?

When testing with Arm Compiler 6.16 I see the following compile error:

Error: L6218E: Undefined symbol strnlen (referred from cellular_at_core.o)

Unless I'm mistaken, I don't believe AC6 supports strnlen. I've temporarily resolved the compile issue by defining strnlen in the cellular_platform.h file like so:

#if defined(__ARMCC_VERSION)           /* AC6 compiler */
inline size_t strnlen (const char * s, size_t maxlen)
{
    const char * p;

    p = memchr(s, '\0', maxlen);
    if (p == NULL)
    {
        return maxlen;
    }

    return (size_t) (p - s);
}

#endif

These are pretty complex, so a high-level diagram of all interacting components would be beneficial.

In cellular_types.h the CellularPdnConfig structure has three const char fields making it impossible to use this structure without violating constness.

typedef struct CellularPdnConfig
{
    CellularPdnContextType_t pdnContextType;                   /**< PDN Context type. */
    CellularPdnAuthType_t pdnAuthType;                         /**< PDN Authentication type. */
    const char apnName[ CELLULAR_APN_MAX_SIZE + 1 ];           /**< APN name. */
    const char username[ CELLULAR_PDN_USERNAME_MAX_SIZE + 1 ]; /**< Username. */
    const char password[ CELLULAR_PDN_PASSWORD_MAX_SIZE + 1 ]; /**< Password. */
} CellularPdnConfig_t;

apnName, username, and password all need to be changed to char.

Hello!

I'm trying to implement MQTT-related AT commands for BG95 and have encountered one issue related to receiving multi-line response with AT+QMTRECV command.

I registered URC handler for "QMTRECV" and can handle incoming MQTT publications.
But if I send MQTT publication with payload that include <LF> symbols inside (formatted JSON with line feed):

thereafter the first <LF> symbol in payload interpreted as the end of line so in the URC handler for "QMTRECV" I can only see part of the payload up to the <LF> symbol. Next parts are come as AT_UNDEFINED messages.

Looks like an issue while processing responses in _handleAllReceived because the responses must include <CR><LF><response><CR><LF> according to AT Commands Manual

I can register _Cellular_RegisterUndefinedRespCallback to proceed all the rest of "QMTRECV" but it looks like workaround. What can you suggest to do in this situation?
Thank you!

Are there plans to allow localPort in CellularSocketContext_t to be set via an API (maybe via Cellular_SocketSetSockOpt)? Currently we are setting it directly through the CellularSocketHandle_t.

Hi,
I got these errors when my code include cellular library headers only.

Incude:

#include <cellular_config.h>
#include <cellular_config_defaults.h>
#include <cellular_comm_interface.h>

Error:

../Lib/FreeRTOS-Cellular-Interface/source/include/cellular_types.h:416:5: error: 'uint8_t' does not name a type

I think it would be better to include stdint.h here.
https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface/blob/main/source/include/cellular_types.h#L39

There are memory access fault when call Cellular_Init() at no SIM.

https://github.com/FreeRTOS/Lab-Project-FreeRTOS-Cellular-Library/blob/main/common/src/cellular_pktio.c#L346

pRespPrefix was NULL.

A common idiom across all modem ports seems to be that receiving raw data via

_Cellular_TimeoutAtcmdDataRecvRequestWithCallback(), currently mostly used in Cellular_SocketRecv()

requires duplication of the prefix parsing in the actual prefix handler, example from BG96

https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface-Reference-Quectel-BG96/blob/c33a3628e015f88df24b21160ba9dbdabc781da1/source/cellular_bg96_api.c#L1690-L1774

and then in the callback itself, since the callback usually refers to information and / or performs checks based on info found in prefix

https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface-Reference-Quectel-BG96/blob/c33a3628e015f88df24b21160ba9dbdabc781da1/source/cellular_bg96_api.c#L1277-L1342

The prefix handler context is set by caller via pCallbackContext argument, but most ports don't make use of it.

Hi! I'm porting the library to a Nordic nrf52 chip. I've some issues with these lines, where the log command has more arguments than permitted by the SDK log function (the maximum number is 6). Is it possible to divide it in two or more calls ?

Hi. I am using Sara R4 module with the FreeRTOS library I noticed that when I am opening the socket using Cellular_SocketConnect then I got URC callback registered by the Cellular_SocketRegisterSocketOpenCallback before exiting Cellular_SocketConnect which leads to race condition on the socket state socketHandle->socketState since it is set to SOCKETSTATE_CONNECTING despite the fact that socket is already connected. I am not able to send any data on the socket because send function has a check against socket state.

I checked that it happens when cellular module return URC(+UUSOCO: 0,0) just right after response to the AT+USOCO= and the calling thread has lower priorioty then the cellular library receive thread then the URC handler is executed before exiting Cellular_SocketConnect and socket state is invalid.

The temporary workaround seems to be increasing the priority of thread calling Cellular_SocketConnect and setting it back after this function execution.

Could you take a look into this issue ?

Hi, I called the Cellular_CommonGetRegisteredNetwork API to test MCC when disconnecting the PDN of the network of cellular.

Then I found the API got the undefined value of MCC.

The reason is that the below pOperatorInfo value is not zero clear after getting Malloc.

cellularOperatorInfo_t * pOperatorInfo = ( cellularOperatorInfo_t * ) Platform_Malloc( sizeof( cellularOperatorInfo_t ) );

The *pOperatorInfo value is copied undefined value below the lines.

source/cellular_pkthandler.c: In function '_atParseGetHandler':
source/cellular_pkthandler.c:447:60: warning: passing argument 5 of 'bsearch' from incompatible pointer type [-Wincompatible-pointer-types]
447 | _searchCompareFunc );
| ^~~~~~~~~~~~~~~~~~
| |
| int32_t (*)(const void *, const void ) {aka long int ()(const void *, const void )}
In file included from source/cellular_pkthandler.c:32:
/opt/armgcc/arm-none-eabi/include/stdlib.h:89:24: note: expected '__compar_fn_t' {aka 'int ()(const void *, const void )'} but argument is of type 'int32_t ()(const void *, const void )' {aka 'long int ()(const void *, const void *)'}
89 | __compar_fn_t _compar);
| ~~~~~~~~~~~~~~^~~~~~

I'm using the same implementation of the comm interface as the comm_st_uart.c.

Everything works fine, I setup the modem and then open the socket. Once it's open I use Cellular_SocketSend to send a packet on the socket, but it hangs until timeout and does not send the data. The UART interface does catch the "\r\n> " sent by the modem, but the library doesn't seem to catch it. Any idea ? My modem is the BG96

Hi, I wonder the system would be locked or not work properly if PlatformMutex_Lock API cannot get Mutex or happened the timeout of Mutex.

    PlatformMutex_Lock( &pContext->PktRespMutex );    // It gets the Mutex however, the API doesn't have return value. So, the code cannot check timeout.
    pContext->cbEvents.networkRegistrationCallback = networkRegistrationCallback;
    pContext->cbEvents.pNetworkRegistrationCallbackContext = pCallbackContext;
    PlatformMutex_Unlock( &pContext->PktRespMutex );

Does it nerver happnened?

Minor nuisance, but still

The annoying thing about it is that correcting it might break modem implementations.

In a C11 context (and not compaining in earlier versions unless -pedantic is used) it might be possible to make the transition via anonymous union

struct CellularContext
{
    /* ... */

    /* Module Context. */
    union {
        void * pModueContext __attribute__((deprecated));
        void * pModuleContext;
    };
};

However, the above example should be reworked if MSVC support is required.

https://github.com/FreeRTOS/Lab-Project-FreeRTOS-Cellular-Library/blob/4681d3998d6bcbd333d6b605dd83eb21d2c979f3/common/src/cellular_pktio.c#L379

I noticed in the amazon-freertos repo(line 381 in that repo's version of cellular_pktio.c) that there is a null pointer check before dereferencing "pContext->pCurrentCmd"
( ( pContext->pCurrentCmd == NULL ) ? "NULL" : pContext->pCurrentCmd ),

Diving through the history, that repo updated the check in commit 1fdb31c2f94af2bc3cde30cd14901f04db866d10 on November 18th, 2020 1:07am. A little bit after this repo was created. There were additional null pointer dereference checks added in that commit.

All subsequent commits in the other repo seem to be targeted at adding support for more devices.

Currently, the Amazon copyright is in the LICENSE file, causing Github to not recognize it at MIT license. We want to ensure Github recognizes it as MIT License.

Hello all,

How do I set custom timeouts for common functions like Cellular_CommonGetModemInfo?
I see that the send functions use PACKET_REQ_TIMEOUT_MS as the default value.
My modem documentation recommends a longer timeout for some of the common AT commands.
Since this define doesn't have #ifndef block around it there is no way to redefine it without modifying the Cellular Interface Files.
I wanted to ask if setting a custom timeout is possible before asking for a feature request.

Thank you,
Tuna Bicim

I got below errors:

../Lib/cellular/modules/sara_r4/cellular_r4.h:117:5: error: unknown type name 'BOOL'
../Lib/cellular/modules/sara_r4/cellular_r4.h:128:5: error: unknown type name 'BOOL'
../Lib/cellular/modules/sara_r4/cellular_r4.h:129:5: error: unknown type name 'BOOL'
../Lib/cellular/modules/sara_r4/cellular_r4_api.c:1053:72: error: 'TRUE' undeclared (first use in this function)
../Lib/cellular/modules/sara_r4/cellular_r4_api.c:1260:97: error: 'TRUE' undeclared (first use in this function)
../Lib/cellular/modules/sara_r4/cellular_r4_api.c:1419:68: error: 'FALSE' undeclared (first use in this function)
../Lib/cellular/modules/sara_r4/cellular_r4_api.c:2435:94: error: 'TRUE' undeclared (first use in this function)

Hi,
I try to use USECMNG command but this command after sending parameters respond with \r\n> sentence which indicates a byte stream mode after that data can be send to the cellular module and final response to the AT comment is received. I try to send this command and data using this library but I cannot find any way how to do this. My cellular module is the SARA R4
Do you think that something like that would be possible using some kind of hack with current library implementation ?

While porting FreeRTOS-Cellular library to SIMCom SIM800C, I've noticed that the cellular_pktio.c : _getMsgType() doesn't discern between a solicited response (that we're currently sending / waiting on) and unsolicited response of the same command.

Currently (at commit dda105f) the unsolicited response will be detected as solicited, thereby invoking the wrong callback.

In my case this happens with AT+CREG? when

• the module is configured to emit URCs with AT+CREG=2 (Cellular_ModuleEnableUrc(), this was brought over from sim70x0 module support)
• the module is disconnected with AT+CFUN=4, within Cellular_RfOff()
• the module is connected with AT+CFUN=1, within Cellular_RfOn()
• the registration status is manually probed with AT+CREG?, within Cellular_CommonGetServiceStatus() -> atcmdQueryRegStatus(), the command waits for response with prefix +CREG

In this scenario, the modem first responds with +CREG: 2 URC, for which _getMsgType() erronously returns AT_SOLICITED and thus the wrong parser is called.

While the most obvious workaround would be to simply disable URC for this command and rely on manual probing (which the library already seems to do, at least for network registration status), it would be beneficial if we are able to handle such situations.

It would be useful to offer a secure Secure Sockets Transport Implementation. Quetel, UBlox and Sierra Wireless support TLS sockets, thereby allowing the use of certificates stored within the modem and reducing the MCU resources needed.