Coder Social home page Coder Social logo

freertos-cellular-interface's Introduction

FreeRTOS Cellular Interface

On this page:

Introduction

The Cellular Interface library implement a simple unified Application Programming Interfaces (APIs) that hide the complexity of AT commands. The cellular modems to be interchangeable with the popular options built upon TCP stack and exposes a socket-like interface to C programmers.

Most cellular modems implement more or less the AT commands defined by the 3GPP TS v27.007 standard. This project provides an implementation of such standard AT commands in a reusable common component. The three Cellular libraries in this project all take advantage of that common code. The library for each modem only implements the vendor-specific AT commands, then exposes the complete Cellular API.

The common component that implements the 3GPP TS v27.007 standard has been written in compliance of the following code quality criteria:

  • GNU Complexity scores are not over 8.
  • MISRA coding standard. Any deviations from the MISRA C:2012 guidelines are documented in source code comments marked by "coverity".

FreeRTOS Cellular Interface v1.3.0 Source Code is part of the FreeRTOS 202210.00 LTS release.

Getting Started

Download the source code

To clone using HTTPS:

git clone https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface.git

Using SSH:

git clone [email protected]/FreeRTOS/FreeRTOS-Cellular-Interface.git

Folder structure

At the root of this repository are these folders:

  • source : reusable common code that implements the standard AT commands defined by 3GPP TS v27.007.
  • docs : documentations.
  • test : unit test and cbmc.
  • tools : tools for Coverity static analysis and CMock.

Implement Comm Interface with MCU platforms

The FreeRTOS Cellular Interface runs on MCUs. It uses an abstracted interface - the Comm Interface, to communicate with cellular modems. A Comm Interface must be implemented as well on the MCU platform. The most common implementations of the Comm Interface are over UART hardware, but it can be implemented over other physical interfaces such as SPI as well. The documentation of the Comm Interface is found within the Cellular API References. These are example implementations of the Comm Interface:

The FreeRTOS Cellular Interface uses kernel APIs for task synchronization and memory management.

Adding Support for New Cellular Modems

FreeRTOS Cellular Interface now supports AT commands, TCP offloaded Cellular abstraction Layer. In order to add support for a new cellular modem, the developer can use the common component that has already implemented the 3GPP standard AT commands.

In order to port the common component:

  1. Implement the cellular modem porting interface defined in cellular_common_portable.h (Document).
  2. Implement the subset of Cellular Library APIs that use vendor-specific (non-3GPP) AT commands. The APIs to be implemented are the ones not marked with an "o" in this table.
  3. Implement Cellular Library callback functions that handle vendor-specific (non-3GPP) Unsolicited Result Code (URC). The URC handlers to be implemented are the ones not marked with an "o" in this table.

The Cellular Common APIs document provides detail information required in each steps. It is recommended that you start by cloning the implementation of one of the existing modems, then make modifications where your modem's vendor-specific (non-3GPP) AT commands are different.

Current Example Implementations:

Integrate FreeRTOS Cellular Interface with Application

Once comm interface and cellular module implementation are ready, we can start to integrate FreeRTOS Cellular Interface. The following diagram depicts the relationship of these software components:


Follow these steps to integrate FreeRTOS Cellular Interface into your project:

  1. Clone this repository into your project.
  2. Clone one of the reference cellular module implementations ( BG96 / HL7802 / SARA-R4 ) or create your own cellular module implementation in your project.
  3. Implement comm interface.
  4. Build these software components with your application and execute.

We also provide Demos for FreeRTOS-Cellular-Interface on Windows Simulator as references for these three cellular modems example implementations.

Building Unit Tests

Checkout CMock Submodule

By default, the submodules in this repository are configured with update=none in .gitmodules to avoid increasing clone time and disk space usage of other repositories (like FreeRTOS that submodules this repository).

To build unit tests, the submodule dependency of CMock is required. Use the following command to clone the submodule:

git submodule update --checkout --init --recursive test/unit-test/CMock

Platform Prerequisites

  • For building the unit tests, CMake 3.13.0 or later and a C90 compiler.
  • For running unit tests, Ruby 2.0.0 or later is additionally required for the CMock test framework (that we use).
  • For running the coverage target, gcov and lcov are additionally required.

Steps to build unit tests

  1. Go to the root directory of this repository. (Make sure that the CMock submodule is cloned as described above.)

  2. Run the cmake command: cmake -S test -B build

  3. Run this command to build the library and unit tests: make -C build all

  4. The generated test executables will be present in build/bin/tests folder.

  5. Run cd build && ctest to execute all tests and view the test run summary.

CBMC

To learn more about CBMC and proofs specifically, review the training material here.

The test/cbmc/proofs directory contains CBMC proofs.

In order to run these proofs you will need to install CBMC and other tools by following the instructions here.

Reference examples

Please refer to the demos of the Cellular Interface library here using FreeRTOS on the Windows simulator platform. These can be used as reference examples for the library API.

Generating documentation

The Doxygen references were created using Doxygen version 1.9.6. To generate the Doxygen pages, please run the following command from the root of this repository:

doxygen docs/doxygen/config.doxyfile

Contributing

See CONTRIBUTING.md for information on contributing.

freertos-cellular-interface's People

Contributors

actoryou avatar amazon-auto avatar andysun2015 avatar angelonakos avatar aniruddhakanhere avatar awsblake avatar chinglee-iot avatar karkhaz avatar liennguyen2910 avatar markrtuttle avatar matsujirushi avatar muneebahmed10 avatar skptak avatar tautschnig avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

freertos-cellular-interface's Issues

_searchCompareFunc incompatible to bsearch

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);
| ~~~~~~~~~~~~~~^~~~~~

_parseSignalQuality function does not compute RSSI

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.

[Feature Request] Support for byte stream

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 ?

Handling commands that report no status information

SIM800C has a fun little command called AT+CIFSR

image

This command does not provide any status information when it succeeds

image

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

image
image

image

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?

[Enhancement] Raw data receive prefix parser should pass info to command callback

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.

_Cellular_AtcmdDataSend never catches the "> " message

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

image

Wrong formatting / argument type in log traces generate warnings

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=]

_Cellular_HandlePacket() depends on undefined behaviour

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

static CellularPktStatus_t urcParseToken( CellularContext_t * pContext,
char * pInputLine )
{
CellularPktStatus_t pktStatus = CELLULAR_PKT_STATUS_OK;
bool inputWithPrefix = false;
/* pInputLine = "+" pTokenPtr + ":" + pSavePtr.
* if string not start with "+", then pTokenPtr = pSavePtr = pInputPtr. */
char * pSavePtr = pInputLine, * pTokenPtr = pInputLine;
LogDebug( ( "Next URC token to parse [%s]", pInputLine ) );
/* Check if prefix exist in the input string. The pInputLine is checked in _processUrcPacket. */
( void ) Cellular_ATIsPrefixPresent( pInputLine, &inputWithPrefix );
if( inputWithPrefix == true )
{
/* Cellular_ATIsPrefixPresent check the prefix string is valid and start with
* leading char. ":" is also checked in Cellular_ATIsPrefixPresent. Remove
* the leading char and split the string. */
pSavePtr++;
pTokenPtr = strtok_r( pSavePtr, ":", &pSavePtr );
if( pTokenPtr == NULL )
{
LogError( ( "_Cellular_AtParse : input string error, start with \"+\" but no token %s", pInputLine ) );
pktStatus = CELLULAR_PKT_STATUS_BAD_REQUEST;
}
}
else
{
/* This is the input without prefix case. Nothing need to be done for this case.
* There are some special cases. For example, "+URC" the string without ":" should
* be regarded as URC without prefix. */
}
if( pktStatus == CELLULAR_PKT_STATUS_OK )
{
/* Now get the handler function based on the token. */
pktStatus = _atParseGetHandler( pContext, pTokenPtr, pSavePtr );
}
return pktStatus;
}

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.

Cellular_CommonGetRegisteredNetwork API return undefined value

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 ) );

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

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

( void ) memcpy( pNetworkInfo->mcc, pOperatorInfo->plmnInfo.mcc, CELLULAR_MCC_MAX_SIZE );

Incompatible pointer types between CellularAtParseTokenHandler_t and functions in cellular_common_api.h

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?

strnlen compile error with Arm Compiler 6.16

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

unknown type name 'BOOL'

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)

Link to demo missing in readme

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.

error: unknown type name 'CellularTokenTable_t'

In file included from ../Lib/FreeRTOS-Cellular-Interface/modules/sara_r4/cellular_r4_api.c:37:
../Lib/FreeRTOS-Cellular-Interface/source/include/common/cellular_common_api.h:50:44: error: unknown type name 'CellularTokenTable_t'
   50 |                                      const CellularTokenTable_t * pTokenTable );
      |                                            ^~~~~~~~~~~~~~~~~~~~

Queue created by _Cellular_PktHandlerInit is not deleted during cleanup.

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.

image

[Feature Request] In-band handling of cellular_comm_interface errors

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

( void ) pContext->pCommIntf->recv( pContext->hPktioCommIntf, ( uint8_t * ) pRead,
bufferEmptyLength,
CELLULAR_COMM_IF_RECV_TIMEOUT_MS, &bytesRead );

( void ) pContext->pCommIntf->send( pContext->hPktioCommIntf,
( const uint8_t * ) &pContext->pktioSendBuf, newCmdLen,
CELLULAR_COMM_IF_SEND_TIMEOUT_MS, &sentLen );

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

Typo in CellularContext data structure

Minor nuisance, but still

/* Module Context. */
void * pModueContext;

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.

[Feature Request] Setting UDP Local Port

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.

CellularPdnConfig_t has const data members.

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.

[BUG] Sara R4 socket opening race condition

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 ?

[Feature Request] Secure Sockets Transport Implementation

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.

[Bug] Improper handling of unsolicited and solicited codes of the same command

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.

Receiving a multi-line payload response from MQTT-related BG95 AT commands

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):
image
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!

Cannot get both IP address of IPv4 and IPv6 when calls Cellular_GetIPAddress function

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.

It seems that System would be locked or doesn't work properly when Mutex cannot get due to PlatformMutex_Lock doesn't have return value

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 );

    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?

Possible Null Pointer Dereference

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.

Configuration of PKTIO_READ_BUFFER_SIZE

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.

image

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

#define PKTIO_READ_BUFFER_SIZE ( 1600U ) /* This should be larger than TCP packet size. */

  • 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?

Many arguments in LogDebug lines

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 ?

LogDebug( ( "\n TimeZoneInfo: Timezone %d Year %d Month %d day %d Hour %d Minute %d Second %d ",

LogDebug( ( "SrvStatus: rat %d cs %d, ps %d, mode %d, csRejType %d, csRej %d, psRejType %d, psRej %d, plmn %s%s",

How to set custom timeout for common AT Command functions?

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.