B-L072Z-LRWAN1: Can't connect to target (anymore)

Development Platforms
1

I had B-L072Z-LRWAN1 board working with PlatformIO via built-in ST-LINK. I was able to upload programs and run them just fine.

Then, to read back DevEUI on Murata module, I switched to STM32CubeIDE and uploaded “LoRaWAN_End_Node” (demo program supplied by ST). This is maybe silly thing to do to just read DevEUI, but I don’t know any other way to do it.

I got the DevEUI and went back to PlatformIO and now I can’t upload anything to B-L072Z-LRWAN1.

image
image731×304 8.81 KB

Also tried with STM32CubeProgrammer but it can’t connect either.

image

Going back to STM32CubeIDE to see if it’s still able to connect and it seems to be able to connect to target.

image
image464×521 8.23 KB

So what’s going on here??

Thanks,
Tipo

2

Did you try this with all available reset modes? (Hardware Reset, Core Reset, etc.)

3

Now I tried with “Hardware reset” and it worked.

With STM32CubeProgrammer I downloaded firmware.bin file created with PlatformIO, and now I can connect with PlatformIO again.

Many thanks!!!

4

What would be an easy way to read DevEUI from LoRa module in PlatformIO?

5

The module is just a “STM32L072CZ microcontroller and SX1276 transceiver”, there is no item named “DevEUI” statically burned in these components by themselves. The way I read it, when it connects to a LoRaWAN network it uses the activation methhod

So it uses OTAA to join the network, which needs a DevEUI, AppEUI (and JoinEUI). Since the app is configured for

which means it will use a callback function to acquire the DevEUI as per

The callback is set through this function

which is used as

and callbacks->GetUniqueId from that function is sourced from

which initializes it as its input parameter

which finally at the highest level is called from here

so for the DevEUI, the function GetUniqueId here is used.

You can see this impelmentation here

The function LL_FLASH_GetUDN() only exists for the STM32WL devices here, so I assume it actuallyl is taking the upper path for the STM32L0 chip in the module. In that case, the UniquE ID is simply uses the 12-byte microcontroller’s unique ID (UID), which every STM32L0 (and others) microcontroller gets during the factory production process, and combines the first and last 32-bit word of that into a single 32-bit word, to get a 8 byte ID out according to the code above.

#include <stm32l0xx_hal.h>

void GetUniqueId(uint8_t *id) {
    uint32_t ID_1_3_val = HAL_GetUIDw0() + HAL_GetUIDw2();
    uint32_t ID_2_val = HAL_GetUIDw1();

    id[7] = (ID_1_3_val) >> 24;
    id[6] = (ID_1_3_val) >> 16;
    id[5] = (ID_1_3_val) >> 8;
    id[4] = (ID_1_3_val);
    id[3] = (ID_2_val) >> 24;
    id[2] = (ID_2_val) >> 16;
    id[1] = (ID_2_val) >> 8;
    id[0] = (ID_2_val);
}

(Otherwise, in the lower path, which uses LL_FLASH_GetUDN() (4 bytes), LL_FLASH_GetDeviceID() (1 bytes) and LL_FLASH_GetSTCompanyID() (3 bytes) to generate the DevEUI).

So, to repeat, there is no directly designed “DevEUI” burned in the module, the code and this application just initializes the LoRaWAN stack in a way that uses the UniqueID of the microcontroller and specific transformation (addition of the first and last 32-bit word) to calculate the DevEUI. The application could have done that in an arbitrary way.

Similiarly, the DevAddr is calculated.

When creating a LoRaWAN device, one can also just generate any DevEUI in the LoRa Network Server (LNS), e.g., TTN or Chirpstack, and copy that value into the firmware of the firmware of the device, and it would work too.

Refernence: https://www.st.com/en/microcontrollers-microprocessors/stm32l072cz.html# in the reference maual

grafik
grafik778×285 18 KB

grafik
grafik766×621 14.8 KB

6

Thanks for complete explanation :+1:

I really thought DevEUI’s are assigned and programmed to Semtech chips at their factory…

The DevEUI is a 64-bit globally-unique Extended Unique Identifier (EUI-64) assigned by the manufacturer, or the owner, of the end-device.