cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WL FUOTA single core not working on FW_WL_V1.3.0 in EU868 and AWS IoT LoRaWAN

jmmunoz
Associate II

Hi,

Has someone made a FUOTA session succesful in EU868 using the Nucleo-WL55JC using FW_WL_V1.3.0? 

When I run the FUOTA example, single core, the device goes to the HardFault_Handler interrupt. 

This happens right after the device switches from class A to class C at the start of the FUOTA campaign. At the reception of the first frame, the device halts. The last thing I see in the serial terminal is:

 

 

###### ========== MCPS-Confirm =============
###### U/L FRAME:0070 | PORT:2 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
1700119218s532:RX_C on freq 869525000 Hz at DR 3
Switch to Class C done
1700119219s243:MAC rxDone
1700119219s248:BufferRX Port: 201

 

 

I have tried with DR_0 and DR_3 as downlink datarates. For DR_0 I use a maximum packet size of 48B and 112B for the DR_3.

2 REPLIES 2
STTwo-32
ST Employee

Hello @jmmunoz 

In FUOTA procedure:

  • The campaign starts up correctly, so the process, the device and network configuration seem to be fine.
  • The device switches to class C, which means it listens on a particular window (RxC), which is open all the time. at this point, it receives a first frame, so the configuration is correct.
  • If a hardfault is generated at this point, the most likely explanation revolves around memory configuration, since the only thing done when a fragment of a FUOTA campaign is received is to place it in FLASH until the whole image can be recomposed.

A bad memory access (wrong section, memory protect unit enabled on the wrong region, a non-8bytes aligned fragment) may be the cause of this error.

  • First check: SBSFU security. if there are protections, it's best to disable them during dev.
  • Second check: memory and region defined for storage of fragments awaiting FW image recompositing.

Best Regards.

STTwo-32

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi @STTwo-32 ,

thank you for your inputs.

Reading the AN5554 document, I see that by using 

#define SECBOOT_DISABLE_SECURITY_IPS  /*!< Disable all security IPs at once when activated */

in app_sfu.h, the security is deactivated. Is there any other security to be disable?

If I understood correctly, in the single core LoRaWAN_FUOTA there is not SBSFU.

For the second check, I haven't touched any configuration in the memory and region for storage/fragments. What should I look for?