FreeRTOS Cellular Interface Custom Prefix Character

Hello Everyone,

I am using Cinterion PLS63 Modem from Thales.
Some of the custom commands of the modem use ‘^’ character for responses and URCs.
This character is not present on the check CELLULAR_CHECK_IS_PREFIX_CHAR macro.
This creates issues using the library (Responses marked as not having a prefix when they actually do).
I edited the core.c file to add that character to the check but is there a better way to add a custom prefix character through cellular_config.h file without modifying source files?

Thank you,
Tuna Bicim

Hi Tuna,

Sorry for late reply.

CELLULAR_CHECK_IS_PREFIX_CHAR is used to to allow modem specific characters before “:” separator and can be redefined in cellular_config.h. You can reference the community supported sim70x0 porting for the usage.

I also checked the AT command document for Cinterion PLS63 Modem. PLS63 uses “^” is used instead of “+” in some AT commands.

For example, the “AT^SMSO” config:

^SMSO:(list of supported<fso>s)

If you’re having trouble porting the PLS63, please share your issue with us.

Hello Ching-Hsin,

I didn’t realize I could setup that macro on the config.h file.
I performed the change however, I still was not getting any URC handler matches.
I realized the function urcParseToken under cellular_pkthandler.c also uses ‘+’ character to break off the code that comes after ‘:’. The function then calls _atParseGetHandler which does a binary search on the URC table to find matches but if the response does not start with ‘+’ since it never gets broken up the match is not found.
+CPIN: Ready → CPIN
^SISR: 0, 1 → ^SISR: 0,1
Won’t match ^SISR or SISR entry on URC handler.

I am not sure if I am missing something but adding the ‘^’ to the checked values have fixed the problem of URC handlers not being found. I think a more generic way to code this function would be to check if the first character is alphanumeric and skipping if it is or just not skipping the character and changing the urc tables to do a full match. I understand why the skipping happens (to make the binary search faster) however this code makes assumptions that might not be correct for all the chips.
Any ideas/suggestions for the issue I am having?

Thank you,

Hi Tuna,

After pktio decides the message type, it passes the input line to pkthandler. urcParseToken is the logic in pkthandler to handle URC token. The implementation assume URC with prefix starts with “+” and split the input line into the following tokens.

pInputLine = "+" pTokenPtr + ":" + pSavePtr.

We can test the following patch with PLS63 first:

diff --git a/source/cellular_pkthandler.c b/source/cellular_pkthandler.c
index c5712fb..a52dcea 100644
--- a/source/cellular_pkthandler.c
+++ b/source/cellular_pkthandler.c
@@ -144,7 +144,7 @@ static CellularPktStatus_t urcParseToken( CellularContext_t * pContext,
      * byte. Use that string to pass to strtok and retrieve the token. Once the
      * token use is retrieved, get the function handler map and call that
      * function. */
-    if( *pSavePtr == '+' )
+    if( ( *pSavePtr == '+' ) || ( *pSavePtr == '^' ) )
         pTokenPtr = strtok_r( pSavePtr, ":", &pSavePtr );

We would like to update the cellular interface to support different modem requirements.
If you are able to test the patch, please share the test results with us as well.

Hi Ching-Hsin,

That is exactly how I have been running the code and it works fine and my URC handlers are found properly.
One question I had while debugging was why do we check and discard ‘+’? Is this to increase the performance of the bsearch that is performed after?
In that case the library could actually use ispunct to check the character is a punctuation character which eliminates the need to check for specific cases.
I think my biggest problem is the documentation is lacking and I had to debug deep into the library to find out about all these things. I have been basing my assumptions on BG96 but that also uses the generic ‘+’ character so that makes you miss edge cases.
This part of the porting guide doesn’t mention anything about how to handle special characters for example:

Thank you again for looking into the issue. I appreciate the help.

Thank you,