Open rickou opened 1 month ago
It looks like the SRING: x
is being treated as an undefined message rather than a unsolicited message. What does your pCellularUrcTokenWoPrefixTable
look like?
@rickou We would like to use the issue only for bug or feature tracking and move the question to the FreeRTOS forum. I saw you have another thread in the forum. I would suggest we keep a single source of discussion in the FreeRTOS forum and close the issue here.
@chinglee-iot , you're right ! in fact i 1st post here because in my mind, the lib should not take care about the leading char of frames... that's could make it more generic.. but after this i remembered there is a forum, and i asked there because maybe it was only a misunderstood of the lib api at my side.. Again, for me, maybe it could be good to make enhancements to the lib to be more generic. if there is no way for this, please be free to close this ticket ! i will not be offended.. 😉
Hi there,
I started to port the driver to ME310G1 modem inspired from SARA-R4 driver. Connexion is now working and I'm currently porting the socket layer. I'm facing the lib do not handle URC correctly.
Once socket is opened, the ME310 send URC "SRING: x" (with x=socket ID) to inform data are available. but this URC is not handled by the lib. instead i get
DEBUG [ME310 ] 12 bytes received (..SRING: 1..) DEBUG [CELLULAR ] AT Read 12 bytes, data[200080c6] INFO [CELLULAR ] AT_UNDEFINED message received SRING: 1 ERROR [CELLULAR ] No undefined callback for AT_UNDEFINED type message SRING: 1 received. ERROR [CELLULAR ] recvdMsgType is AT_UNDEFINED for Message: SRING: 1, cmd NULL DEBUG [CELLULAR ] _handleMsgType failed 11
If i right understood the lib source, URC message can't be without prefix.. but it is the case here..