Second Transmission Fails

Hello All,

I’ve run into a strange problem. My devices join with no problem. The first transmission after joining occurs with no problem as far as I can tell. However, the second transmission call (LoRaWAN_Send()) never completes. Assuming I use the M4_WaitActive wait mode, the program gets stuck at:
while (coreArguments.status.system.isBusy) {} (line 130 in OnethinxCore01.c)…

This behavior is happening consistently with multiple devices.

Any idea what could be happening here? Note that joining and the first transmission are always successful. Things only go wrong on the second transmission. I should also mention that my stack version is BA.


Hi Paul, can you try with M4_WaitDeepSleep and let us know?


Tom, essentially the same happens regardless of the wait mode (other than M4_NoWait). If I specify one of the sleep modes, the code hangs at the statement:
while (_FLD2VAL(CPUSS_CM4_PWR_CTL_PWR_MODE, (*cpussCm4PwrCtlAddr)) == CM4_PWR_STS_RETAINED); (line 3006 of cy_syspm.c).

I also tried using M4_NoWait wait mode. After the first LoRaWAN_Send call, the packet was received by the server and the coreArguments.status.system.isBusy flag eventually became false. After the second call, the coreArguments.status.system.isBusy flag stayed true forever and the packet was never received by the server. Both of these calls returned coreArguments.status.system.errorStatus value of system_ok.

When using M4_NoWait wait mode, the system doesn’t hang, but the third and all subsequent calls to LoRaWAN_Send return coreArguments.status.system.errorStatus value system_BusyError. And of course, only the first packet is received by the server.

At first, I thought there might be a problem with the modules that I am currently using in the lab. However, this problem appears to have surfaced in devices that previously worked fine. While I did update their code, I don’t believe any changes I made had anything to do with the communications.

Just to be sure, I programmed a device with code that was several months old. This new behavior, which never occured before, now occurs even with old code.

I’m dumbfounded and stuck. Any suggestions would be appreciated.


Here’s an update. I can successfully send to TTN V3 if I change the LoRaWAN version (in the TTN V3 console) from MAC V1.0.3 to MAC V1.0.2. I don’t know if the problem is with TTN or if my stack (B4) doesn’t work with MAC V1.0.3. Any information about this would be appreciated.

I consider this a workaround, not a solution, because MAC V1.0.2 (in the US) doesn’t supply a CFList, thereby requiring fixed sub-band in the end device. However, this does give me a path forward.


Hi Paul,

you have done this with B4 version? Did you try with BA version?


Oops. I meant BA.


Onethinx module is made according to 1.0.2 revB regional parameters found here:

This is why you need to select 1.0.2 version

Hi Tom,

Thanks for the information. Do you know if newer stack versions either support 1.0.3 or at least won’t hang up if the server uses 1.0.3?