I-CUBE-LRWAN v2.0.0 with Nucleo-L073RZ board and I-Nucleo-LRWAN1 shield

[Andrew Neil]

Nucleo-L073RZ board and I-Nucleo-LRWAN1 (USI module) shield - as supplied as the "Sensor" part of the P-NUCLEO-LRWAN2 kit:

 

The documentation refers to I-CUBE-LRWAN at v1.2.2; in v2.0.0 (March 2021), the directory structure has changed somewhat.

I assume the correct path for the "Sensor" node project is now:

Projects\NUCLEO-L073RZ\Applications\LoRaWAN\LoRaWAN_AT_Master\STM32CubeIDE\I_NUCLEO_LRWAN1

Can anyone confirm if this actually works?

At the moment, mine doesn't seem to be sending any AT commands from the Nucleo board to the USI shield...

[JCOUP]

oK , we see the TX (ATE is a md to disable echo). Normally after we must have the AT cmd to see is the modem is ready and then the AT+JOIN=1. Should seem that problem come just afetr ( yes could be unexpected interrupt ???). Could to could plug the spy on the RX ( modem to master transmission) to see the return value coming from Modem. Is it possible for you to to step by step up to the Lora_fsm() (line 99 - app_master.c file)

[JCOUP]

Andrew, Here are some fixes to solve the problem . Main problem encountered was du to a less memory array allocation. Was already present in the previous version of the package (1.3.1) but without board effect !!! (could be possible following the final mapping organization provided by the linked).

in lora_driver.c in line 81 --> replace 16 by 32 size --> static uint8_t PtrTempValueFromDevice[32] ; /*to get back the device address in */

in sys_app.c --> just reorganize two statements UTIL_TIMER_Init() and Modem_IO_Init() in the SystemApp_Init(void) function

 */

void SystemApp_Init(void)

{

 /* USER CODE BEGIN SystemApp_Init_1 */

 /* USER CODE END SystemApp_Init_1 */

 /*Initialises timer and RTC*/

 /*UTIL_TIMER_Init();*/

 Gpio_PreInit();

 /* Configure the debug mode*/

#if 1  

 DBG_Init();

#endif

 /*Initialize the terminal */

 /*UTIL_ADV_TRACE_Init();*/

  

 Modem_IO_Init();

  

  /*Initialises timer and RTC*/

 UTIL_TIMER_Init();

 /*Set verbose LEVEL*/

 /*UTIL_ADV_TRACE_SetVerboseLevel(VERBOSE_LEVEL);*/

 /*Initialize the temperature and Battery measurement services */

 SYS_InitMeasurement();

 /*Initialize the Sensors */

 EnvSensors_Init();

 /*Init low power manager*/

 UTIL_LPM_Init();

 /* Disable Stand-by mode */

 UTIL_LPM_SetOffMode((1 << CFG_LPM_APPLI_Id), UTIL_LPM_DISABLE);

#if defined (LOW_POWER_DISABLE) && (LOW_POWER_DISABLE == 1)

 /* Disable Stop Mode */

 UTIL_LPM_SetStopMode((1 << CFG_LPM_APPLI_Id), UTIL_LPM_DISABLE);

#elif !defined (LOW_POWER_DISABLE)

#error LOW_POWER_DISABLE not defined

#endif /* LOW_POWER_DISABLE */

 /* USER CODE BEGIN SystemApp_Init_2 */

 /* USER CODE END SystemApp_Init_2 */

}

in sys_app.c --> remove from MasterApp_Init(void) the Modem_IO_Init()

in sys_app.c --> remove Gpio_PreInit(void) the two follwoing statements

line 310 --> /* __HAL_RCC_GPIOA_CLK_DISABLE();*/

line 312 --?  /* __HAL_RCC_GPIOC_CLK_DISABLE();*/

in uart.c --> add the sys_conf.h --> to define the USE_USART2 symbol

here is the trace ( Rx pin) transmitted by the modem at reset .. Then after join accepted modem return 254 for battery level and return code OK for the sending frame . On Tx we see the AT+SEND cmd

This problem will be reported on L073 and L053 and will be present in the future next package release ...

[Andrew Neil]

@JCOUP​ "Here are some fixes to solve the problem"

Thanks. I won't be able to look at it immediately - will let you know ...

"here is the trace"

Did you mean to attach something?

;)

[JCOUP]

Hello reha,

I did reproduce the problem. I posted the some fixes on Andrew Neil tchat ..

Regards

[JCOUP]

In order to be homogeneous, one more correction in stm32l0xx_it.c , add "sys_conf.h" header file

line 23 --> #include "sys_conf.h"

[Andrew Neil]

There's also the incorrect Project Definitions

I'm sure I posted about that, but can't seem to find it now. The search here is awful. How do I even find a list of my own threads?

:pouting_face:

EDIT

Found it:

https://community.st.com/s/question/0D53W00000wUOpaSAG/icubelrwan-v200-with-bl072zlrwan1-

That was actually the End_Node project - not AT_Master.

But it is still a fix required in the I-CUBE-LRWAN package

[JCOUP]

Here are two files, one giving the reboot sequence we have to do and the second one giving the sending trace

[JCOUP]

..

[JCOUP]

FYI , I'm doing re-validation tests . For the time being the end-node is running since more that 24h .... We plan to provide a new package release version during summer time.

[JCOUP]

I do not have official released date , but we can expect for September ( we are in the summer period vacation :( ) .... Regarding your other issues, ( double definition with cubeIDE) .... I'm mainly using IAR an keil IDE tools but a colleague is working on it . For the beta testers/reviewers, thankyou for the proposition. I keep the point and tell you. Will be a reel opportunity to improve the reliability and avoid some mistakes .

[JCOUP]

OK and sorry for this omission. I did a complete compare between your Project and my project . In the file stm32l0xx_it.c we have to include the header file "sys_conf.h" (see attached file)

[Andrew Neil]

Ah - that's better:

now to see what's happening at the TTN end ...

[JCOUP]

OK, we see that the join has been accepted... 254 is the response to the battery level request and data has been send to the 99 port.. keep me info on the TTN result

[Andrew Neil]

I think it's time to mark this as 'answered' - as the Nucleo-L073RZ board does now seem to be communicating with the I-Nucleo-LRWAN1 shield.

I'll start a new thread on the TTN interactions...

[Andrew Neil]

"I'll start a new thread on the TTN interactions..."

Here: https://community.st.com/s/question/0D53W00000zI8U9SAK/icubelrwan-v200-nucleol073rz-inucleolrwan1-on-ttn

tl;dr: although it joined initially (as shown above) it then dropped into a continual failing join-request loop. :unamused_face: