cancel
Showing results for 
Search instead for 
Did you mean: 

Why the tx is running persistly (the gateway works fine), using P-NUCLEO-LRWAN3 development suit and STM32CubeExpansion_LRWAN_V1.3.1software package.

WLin.1
Associate

Hi,

I'm currently trying to run End_Node project on my P-NUCLEO-LRWAN3 sensor board, I loaded the workspace to my EWARM IDE from STM32CubeExpansion_LRWAN_V1.3.1\Projects\STM32L073RZ-Nucleo\Applications\LoRa\End_Node\EWARM.

 0693W000000UAl7QAG.png

Problems

(1) I download and run the firmware to the NUCLEO-L073RZ NUCLEO development board, and reset the board, I got a LORAMAC_STATUS_BUSY and PHY txTimeOut message.

ps:

I added PRINTF("\n\rLORAMAC_STATUS_BUSY\n\r" to LoRaMacMlmeRequest function in LoRaMac.c as follows:

if( LoRaMacIsBusy( ) == true )
      {
         PRINTF("\n\rLORAMAC_STATUS_BUSY\n\r"); // added 2020/03/16
         return LORAMAC_STATUS_BUSY;
      }

The message shown in the console is as follows:

[12:00:00.303]receive�?◆APP_VERSION= 01.03.00.00
MAC_VERSION= 04.04.02.00
OTAA
DevEui= 8C-F9-58-20-00-00-F5-2C
AppEui= 6D-09-AA-AA-AD-20-4E-72
AppKey= 8C F9 58 20 00 00 F5 2C 6D 09 AA AA AD 20 4E 72
  
[12:00:00.385]receive�?◆LORAMAC_STATUS_BUSY
[12:00:02.873]receive�?◆\0
[12:00:04.394]receive�?◆ 4s093: PHY txTimeOut
[12:00:06.596]receive�?◆\0
...

(2) I read the source code, and in sx1276.c it says

    // Tx timeout shouldn't happen.

    // But it has been observed that when it happens it is a result of a corrupted SPI transfer

    // it depends on the platform design.

    //

    // The workaround is to put the radio in a known state. Thus, we re-initialize it.

so I guess, it might be a problem of the antenna, and the "soft" reset does not work well; so I reset the board by pressing the reset button(black) on the NUCLEO-L073RZ NUCLEO development board, meanwhile reset the antenna by pressing NRST button on the LoRa LF BAND (443/470 MHZ) sensor expension board. And this time the message shown in the console is as follows:

[12:21:00.015]receive�?◆APP_VERSION= 01.03.00.00
MAC_VERSION= 04.04.02.00
OTAA
DevEui= 8C-F9-58-20-00-00-F5-2C
AppEui= 6D-09-AA-AA-AD-20-4E-72
AppKey= 8C F9 58 20 00 00 F5 2C 6D 09 AA AA AD 20 4E 72
 
[12:21:00.098]receive�?◆
LORAMAC_STATUS_BUSY
 
[12:21:01.948]receive�?◆  1s935: PHY txDone
 
[12:21:04.193]receive�?◆\0
[12:21:09.981]receive�?◆  9s968: PHY rxTimeOut
 
[12:21:12.747]receive�?◆\0
[12:21:14.141]receive�?◆ 14s128: PHY txTimeOut
 
[12:21:16.323]receive�?◆\0
[12:21:22.379]receive�?◆\0
[12:21:24.140]receive�?◆ 24s128: PHY txTimeOut
...

This time I got PHY rxTimeOut message and then PHY rxTimeOut, and then LORAMAC_STATUS_BUSY and PHY txTimeOut repeatedly. I did more investigation and found that MacCtx.MacState is stuck at LORAMAC_TX_RUNNING, which I think is the root for this issue.

So, my immediate question would be: why the tx is running persistly (the gateway works fine)?

---------------------------------------------------------------------------------------------------------------------------------

What I have done:

  1. in hw_conf.h, uncomment #define DEBUG and #define SENSOR_ENABLED
  2. In the IDE, Projece/Options/C /C++ Compiler/Preprocessor, I define a symbol as REGION_CN4700693W000000UAI0QAO.png
  3. in comissioning.h, config the OVER_THE_AIR_ACTIVATION/ DEVICE_EUI/JOIN_EUI (AppEUI)/ APP_KEY, other fields are left using default value.
/*!
 * When set to 1 the application uses the Over-the-Air activation procedure
 * When set to 0 the application uses the Personalization activation procedure
 */
#define OVER_THE_AIR_ACTIVATION                            1
 
/*!
 * When using ABP activation the MAC layer must know in advance to which server
 * version it will be connected.
 */
#define ABP_ACTIVATION_LRWAN_VERSION_V10x                  0x01000300 // 1.0.3.0
 
#define ABP_ACTIVATION_LRWAN_VERSION                       ABP_ACTIVATION_LRWAN_VERSION_V10x
 
/*!
 * Indicates if the end-device is to be connected to a private or public network
 */
#define LORAWAN_PUBLIC_NETWORK                             true
 
/*!
 * IEEE Organizationally Unique Identifier ( OUI ) (big endian)
 * \remark This is unique to a company or organization
 */
#define IEEE_OUI                                           0x8C, 0xF9, 0x58
 
/*!
 * When set to 1 DevEui is LORAWAN_DEVICE_EUI
 * When set to 0 DevEui is automatically generated by calling
 *         BoardGetUniqueId function (it is 0 by default)
 */
#define STATIC_DEVICE_EUI                                  1
 
/*!
 * Mote device IEEE EUI (big endian)
 *
 * \remark see STATIC_DEVICE_EUI comments
 * IT WAS { IEEE_OUI, 0x01, 0x01, 0x01, 0x01, 0x01 } BY DEFAULT
 */
#define LORAWAN_DEVICE_EUI                                 { IEEE_OUI, 0x20, 0x00, 0x00, 0xF5, 0x2C }
 
/*!
 * App/Join server IEEE EUI (big endian)
 * IT WAS { 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01 } BY DEFAULT, USED AS AppEUI
 */
#define LORAWAN_JOIN_EUI                                   { 0x6D, 0x09, 0xAA, 0xAA, 0xAD, 0x20, 0x4E, 0x72 }
 
/*!
 * Application root key
 * WARNING: NOT USED FOR 1.0.x DEVICES
 * IT WAS { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C } BY DEFAULT
 */
#define LORAWAN_APP_KEY                                    { IEEE_OUI, 0x20, 0x00, 0x00, 0xF5, 0x2C, 0x6D, 0x09, 0xAA, 0xAA, 0xAD, 0x20, 0x4E, 0x72 }

3. the device and gateway have been registered on the cloud (server) correctly.

0 REPLIES 0