STM32G474RE internal bootloader - cannot read Unique Device ID, Flash size and package reigsters with Read Memory command

[Adam1]

Hi everybody,

in my current project I use G474RE MCU and I wanted to use internal bootloader with the same tools which I've used with some previous projects and F401 MCU.

I jump to internal bootloader with following code (ported from some official reference example):

#define dSystemMemoryAddress        0x1FFF0000UL
#define dSystemMemoryResetVector    0x1FFF0004UL
 
void jump(void)
{
     LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_SYSCFG);
 
     /* set stack pointer to the bootloader start address */
     __set_MSP(*((uint32_t*)(dSystemMemoryAddress)));
 
     /* system memory mapped at 0x00000000 */
     __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();
 
     /* jump to @bootloader + 4 */
     ((void (*)(void))(*((uint32_t*)(dSystemMemoryResetVector))))();
}

Then I wanted to use exe app "Flash loader demo" but it's doesn't support G4 family yet. By the way version on the site is 0.2.8 from 2015 which is kinda outdated ;)

I've checked AN3155 (Bootloader USART protocol) and I tested some commands.

"Get" command is fine, "Get Version" returns bootloader version 0x31 (is it ok? Shouldn't it be 0xD5?), "Get ID" returns correct chip ID 0x469.

Finally we come where I have my issue. Read memory command works fine, I can read user flash memory and so on, but read memory works till address 0x1FFF 73FF. After that I always get NACK response.

I need to read areas described in RM as "Device electronic signature" which is UID (0x1FFF7590), flash size (0x1FFF75E0), and package (0x1FFF7500).

How can I get it through internal bootloader? Should I unblock something in option bytes before jumping to bootloader? It worked fine with previous MCUs. Also there is no problem to read this data within running code.

[Igor Cesko]

Hi Adam (Community Member),

I have tested the USART bootloader through STM32CubeProgrammer. STM32CubeProgrammer can program the STM32 also through embedded bootloader (just select UART instead of ST-LINK as interface in STM32CubeProgrammer). In STM32CubeProgrammer can be watched in Log window all communication between master and the device (select appropriate "Verbosity level" - how deep we can see the communication).

In STM32CubeProgrammer I cannot read the addresses for device identification for STM32G474 device but I can do it for STM32G491 device.

I will check with bootloader designers why it is like this

Regards

Igor

[Igor Cesko]

Hi Adam (Community Member),,

After discussion with bootloader expert: the bootloader version (bootloader ID version) 13.4 (0xD4) doesn't support this memory addresses to read. But this is corrected in new bootloader version 13.5 (0xD5) . The bootloader ID is programmed in the last byte "address - 1" of the device System memory  (address 0x1FFF 6FFE) - see application note AN2606 for explanation.

Which device revision do you have? Devices with newest revision "Rev X" (X written on the chip or read DBGMCU_IDCODE register or read it by STM32CubeProgrammer) should have newest bootloader inside.

Regards

Igor

[Adam1]

Hi Igor,

first of all, thanks for response! It passed a while since I had this issue ;)

Right now I've jumped to STM32G474QE (more pins).

I have Bootloader ID 0xD4 @ 0x1FFFFFFE, that's why I couldn't read that memory. DEV_ID field in DBGMCU_IDCODE tells me that I have 0x2001 which is "Revision Z" (another confirmation).

One thing which I don't understand:

With bootloader command GET (0x00 0xFF) I receive Bootloader version 0x31 - 3.1

With bootloader command GET VERSION (0x01 0xFE) I also receive Bootloader version 0x31

In which bootloader command I could check that I have bootloader ID 0xD4 (13.4) or 0xD5 (13.5)?

In STM32CubeProgrammer after connecting with bootloader over UART I see in "Target information" field "Flash size 512 - Default", so CubeProgrammer really reads flash size from somewhere or it assumes it? ;)

[Igor Cesko]

Hi Adam (Community Member),

The bootloader commands support only Bootloader protocol version to return. There is not supported the Bootloader ID. But this Bootloader ID is always located ad given address:  last byte "address - 1" of the device System memory.

Regarding the Flash size - I don't know. I think STM32CubeProgrammer reads this from device database according the device identification: 0x469. From the LOG window we can see that STM32CubeProgrammer doesn't read the given memory areas.

Regards

Igor

[Adam1]

Hi Igor,

alright, that explains a lot!

to sum up, Bootloader ID is in the memory area which I cannot read in older siliocon revision so anyway reading 0x1FFFFFFE to get bootloader ID or reading 0x1FFF75E0 is not possible ;) Only solution for me now is just to check chips revision when we will order new batch of MCUs to make sure bootloader will be in newer revision.

About Flash size in CubeProgrammer - I think flash size is assumed, because device ID is the same for example for STM32G474RE and STM32G474QE. They differ only in package, but I think device ID is the same for smaller flash size models. Do you know where I can find full list of Device IDs and corresponding MCU models? It would make developing my SW update app much easier.

Thanks in advance!

Adam

[Igor Cesko]

Hi Adam (Community Member),

The device ID is the same for various memory sizes - so we cannot identify the memory size according device ID.

If you are using USART + bootloader for device update - then bootloader must support reading of the "memory size" register. But for some older STM32 devices (not STM32G4) the "Flash size" register shows real physical size of Flash memory on device - but the device can be marked as device with lower memory size - because the rest of Flash memory was not tested and device is sell as lower memory size device. Then the only difference is the marking on top of device.

For STM32G4 bootloaders which don't support reading of Flash memory size register: You can use some trick (but a bit complicated for automation): you can load some firmware into STM32G4 (load it into RAM) which reads the content of "Flash size register" and store it into some specific SRAM address which can be read by bootloader. This required double connection to bootloader: 1- load SRAM firmware and execute it, 2 - reconnect and read given SRAM address. The SRAM firmware for reading "Flash size register" can be very simple: read the register, store it to given SRAM address, infinite loop. Some development is needed to debug this case.

Regards

Igor