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]

The loaders seem ridiculously large the first is close to 200KB, not sure of the second. Can you dump the headers of the second with objcopy or something similar, or provide the two binaries for inspection?

Correct it doesn't look to load it into RAM 

[Pc10]

Hi, I attach the requested binary files.

Thanks for your response

[Tesla DeLorean]

Was looking for the .STLDR, but never mind

The other is smaller, but both look to have incorrect StorageInfo structures and don't look to be describing QSPI/OSPI, and each describes different memory spaces starting at zero (TCM), one 64Mb (8MB) the other 256Mb (32MB). I suspect this zero addressing conflicts with other expectations within the memory space.

Perhaps set the basis as 0x70000000 or 0x80000000 ?

[Tesla DeLorean]

@Sarra.S @Nawres GHARBI - Can we get some eyes on this as to why a loader might not get pulled into memory, the bigger 200KB one loads, where as the smaller 150KB does not. Structures look intact. Any additional debug output, or diagnostics that might be helpful? Output in logs is frequently duplicative rather than informative.

Some issue with the structure of the .ELF file? Support for one U5 and not the other in the current release? Hidden rules/choices being made here? Do those log / report in some way?

[Aziz BRIGUI]

Hello @Pc10,

You have segments overlapping in both the loaders you attached, could you fix this for U545.stldr and retry with CubeProgrammer ? If that doesn't work, could you attach or PM me your EL project for U545 ? 

Thanks in advance,

Aziz

[Pc10]

Hello @Aziz BRIGUI ,

where do you see the mentioned segments overlap? Where should I check to avoid such scenario? I've analyzed my linker conf file without detecting the problem. I attach you my linker and startup files, thank you so much.

[Tesla DeLorean]

@Aziz BRIGUI Ok, I see what you mean, some degree of conflict with the StorageInfo and other content, although the StorageInfo could be fished out via the Program Header or the 200-byte Section Header.

@Pc10   This is the Linker Script I use for the 0x20000004 RAM loaders, pushes the StorageInfo structure out at ZERO. Although you'd need to expand the the RAM section to accommodate 150 or 200 KB loaders

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader_F7.ld

[Pc10]

Thank you, I've tried your Linker Script, adapted to U545 architecture and startup file, but the final result is the same.

U545 doosn't have addressable RAM at address 0, so I have to put both StorageInfo and Loader into the same region

[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]

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

[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

[Pc10]

Hi @Tesla DeLorean, 

I'm thinking about possible problems caused by the different RAM organization of the two microcontrollers.. any news from your side? Thanks

[Tesla DeLorean]

I have a couple of NUCLEO-U545RE-Q in hand, need to wire up a harness to a SOIC-16 ZIF socket.

I did build a tentative U545 loader off the U599 fork. Things I learned there, No OSPIM, No GPIOF, No OCTOSPI2

External Loader size less than 7KB, was successfully loaded by STM32 Cube Programmer V2.14 into RAM, and Init() called. Failed due to lack of physically attached QSPI device, and perhaps other bugs to-be-determined

https://github.com/cturvey/stm32extldr/blob/main/u5_w25q512/CLIVEONE-W25Q512_STM32U545-PB10-PA4-PB1-PB0-PA7-PA6.stldr

 10:11:57:102 : UPLOADING ...
 10:11:57:103 : Size : 1024 Bytes
 10:11:57:103 : Address : 0x90000000
 10:11:57:103 : Read progress:
 10:11:57:104 : Reading data...
 10:11:57:104 : halt ap 0 
 10:11:57:104 : w ap 0 reg 15 PC (0x20000000) 
 10:11:57:104 : w ap 0 reg 17 MSP (0x20000500) 
 10:11:57:104 : w ap 0 reg 16 xPSR (0x01000000) 
 10:11:57:104 : w ap 0 @0x20001AC0 : 0x00000200 bytes, Data 0x00000000...
 10:11:57:104 : w ap 0 @0x20000000 : 0x00000004 bytes, Data 0x0000BE00...
 10:11:57:144 : w ap 0 @0x20000004 : 0x0000168C bytes, Data 0x4000F080...
 10:11:57:144 : Loader read...
 10:11:57:144 : Init flashloader...
 10:11:57:145 : halt ap 0 
 10:11:57:145 : w ap 0 reg 0 R0 0x00000000
 10:11:57:145 : w ap 0 reg 1 R1 0x00000000
 10:11:57:145 : w ap 0 reg 2 R2 0x00000000
 10:11:57:145 : w ap 0 reg 3 R3 0x00000000
 10:11:57:145 : w ap 0 reg 4 R4 0x00000000
 10:11:57:146 : w ap 0 reg 5 R5 0x00000000
 10:11:57:146 : w ap 0 reg 6 R6 0x00000000
 10:11:57:146 : w ap 0 reg 7 R7 0x00000000
 10:11:57:146 : w ap 0 reg 8 R8 0x00000000
 10:11:57:146 : w ap 0 reg 9 R9 0x00000000
 10:11:57:146 : w ap 0 reg 10 R10 0x00000000
 10:11:57:146 : w ap 0 reg 11 R11 0x00000000
 10:11:57:146 : w ap 0 reg 12 R12 0x00000000
 10:11:57:147 : w ap 0 reg 13 SP 0x00000000
 10:11:57:147 : w ap 0 reg 14 LR 0x20000001
 10:11:57:147 : w ap 0 reg 15 PC 0x200007F5
 10:11:57:147 : w ap 0 reg 16 xPSR 0x01000000
 10:11:57:147 : w ap 0 reg 17 MSP 0x20001A8C
 10:11:57:147 : w ap 0 reg 18 PSP 0x00000000
 10:11:57:147 : run ap 0 
 10:11:57:148 : halt ap 0 
 10:11:57:148 : r ap 0 reg 0 R0 0x00000000
 10:11:57:148 : Init function fail
 10:11:57:148 : r ap 0 reg 16 xPSR 0x41000000
 10:11:57:149 : halt ap 0 
 10:11:57:149 : w ap 0 reg 15 PC (0x20000000) 
 10:11:57:149 : w ap 0 reg 17 MSP (0x20000500) 
 10:11:57:149 : w ap 0 reg 16 xPSR (0x01000000) 
 10:11:57:149 : Error: Data read failed

 

[Tesla DeLorean]

Built the fixture this evening, and tested/validated with a Winbond W25Q256 loader

Looks like I have access to enough pins to facilitate OCTO on something like a Macronix MX25LM51245G

 

PB10:AF10 CLK
PA4:AF3 NCS
PB1:AF10 IO0
PB0:AF10 IO1
PA7:AF10 IO2
PA6:AF10 IO3

PC1:AF10 IO4
PC2:AF10 IO5
PC3:AF10 IO6
PC0:AF3 IO7
PB2:AF10 DQS