CubeProgrammer error on STM32U545

[Pc10]

Hi, I've developed a custom ExternalLoader for STM32U575VGT6Q installed on my board, following the online guides provided by ST, obtaining a fully functional version. On the new version of the board I have an STM32U545VET6Q, so in ExternalLoader project I've carried out the necessary porting for the new micro pinout, and the memory was replaced with a larger one but with the same interface.

On the new version of the board with STM32U545VET6Q, my ExternalLoader has been successfully tested in debug, both in reading and writing, but it does not work when launched from CubeProgrammer (with both versions 2.13 and 2.14 of CubeProg, the only ones that support U545). I attach the CubeProgrammer logs in the two cases, obtained with Verbosity Level 3. I've tried to read small portions of the external flash, but the CubeProgrammer interface always shows the error message when reading (same behavior for writing).

From the logs (the figure below shows an extract of the reading procedure for both micros) I've noticed that in the case of the U545 it seems that the ExtLoader binary is not loaded into RAM, unlike what happens on the U575 (lines 97-99 of the U575 log, absent in U545). Following this (and probably related to the previous problem..) the Main Stack Pointer of U575 seems to point to a coherent memory location, while on U545 it points to zero.

Does anyone have any suggestions on this?

Thank you

[Tesla DeLorean]

It's not looking to load StorageInfo into RAM, it's a structure describing the name and geometry of the memory device so the tools can enumerate the tables in the tools from the files it finds in the bin/ExternalLoader subdirectory. 

[Tesla DeLorean]

What you've generated

========================================================================

** ELF Header Information

    File Name: U545.stldr

    Machine class: ELFCLASS32 (32-bit)
    Data encoding: ELFDATA2LSB (Little endian)
    Header version: EV_CURRENT (Current version)
    Operating System ABI: none
    ABI Version: 0
    File Type: ET_EXEC (Executable) (2)
    Machine: EM_ARM (ARM)

    Image Entry point: 0x200200dd
    Flags: EF_ARM_ABI_FLOAT_HARD (0x05000400)

    ARM ELF revision: 5 (ABI version 2)

    Conforms to Hard float procedure-call standard

    Header size: 52 bytes (0x34)
    Program header entry size: 32 bytes (0x20)
    Section header entry size: 40 bytes (0x28)

    Program header entries: 2
    Section header entries: 24

    Program header offset: 52 (0x00000034)
    Section header offset: 2382924 (0x00245c4c)

    Section header string table index: 23

========================================================================

** Program header #0 (PT_LOAD) [PF_X + PF_W + PF_R]
    Size : 133628 bytes (132092 bytes in file)
    Virtual address: 0x20000004 (Alignment 65536) .. 0x20020A00

====================================

** Program header #1 (PT_LOAD) [PF_W + PF_R]
    Size : 200 bytes
    Virtual address: 0x200201f4 (Alignment 65536)  CONFLICTS

========================================================================
..

What ST's look like

========================================================================

** ELF Header Information

    File Name: MX25LM51245G_STM32U59x.stldr

    Machine class: ELFCLASS32 (32-bit)
    Data encoding: ELFDATA2LSB (Little endian)
    Header version: EV_CURRENT (Current version)
    Operating System ABI: none
    ABI Version: 0
    File Type: ET_EXEC (Executable) (2)
    Machine: EM_ARM (ARM)

    Image Entry point: 0x200024e7
    Flags: None (0x05000000)

    ARM ELF revision: 5 (ABI version 2)

    Conforms to Base float procedure-call standard

    Header size: 52 bytes (0x34)
    Program header entry size: 32 bytes (0x20)
    Section header entry size: 40 bytes (0x28)

    Program header entries: 2
    Section header entries: 20

    Program header offset: 197992 (0x00030568)
    Section header offset: 198056 (0x000305a8)

    Section header string table index: 1

========================================================================

** Program header #0 (PT_LOAD) [PF_R]
    Size : 200 bytes
    Virtual address: 0x00000000 (Alignment 4)

====================================

** Program header #1 (PT_LOAD) [PF_X + PF_W + PF_R]
    Size : 14669 bytes
    Virtual address: 0x20000004 (Alignment 4) .. 0x20003951

========================================================================
..

[Tesla DeLorean]

Possible .LD that shouldn't overlap, STM32U545_LOADER_B.ld should map header / StorageInfo data at zero as read-only

[Pc10]

Hi @Tesla DeLorean,

thank you for your suggestion, I've tried your alternative solutions for .Id file, unfortunately the error persists in both cases

[Pc10]

Hello @Aziz BRIGUI,

I've fixed segment overlapping for U545.stldr, but CubeProgrammer doesn't work. How can I send you the EL project privately?

[Aziz BRIGUI]

I will PM you ASAP.

Aziz

[Tesla DeLorean]

Unless STM32 Cube Programmer outputs more diagnostics about what it dislikes about the ELF Object (.STLDR) this is going to be very difficult to debug externally.

I suspect you'll need to de-complicate the implementation, avoid C++ constructors, interrupt tables, need for startup.s and main(), etc.

A lot of the loader's I've build are a fraction of the size here, and far less complicated internally.

[Pc10]

Thank you @Tesla DeLorean, I've tried to semplify the implementation, unfortunately the described problem seems not dependent on this. On the other hand, the project works on U575.

@Aziz BRIGUI no news on your side?

Is it possible that the U545 processor is not supported? 

[Aziz BRIGUI]

Hello @Pc10,

Please check your community inbox. As far as I know, U545 is supported. But I don't think we can debug further without your loader project.

Thanks,

Aziz

[Tesla DeLorean]

Avnet not making the NUCLEO-U545RE-Q easy to order, not stocked at MOUSER or DIGIKEY