STM32F4 external loader erratic function parameter passing issue

[grams]

This is my first time making and external loader for an SPI flash device. I followed the examples and documentation I was able to find. I was to get the project setup on Keil and ".stldr" file loaded onto ST-Link Utility & CubeProgrammer.

Initially, I set up the "Read" function to send dummy data and that worked fine, so I thought everything would be straight forward from there.

When I added the quadspi code (which has been tested to work on application), the "Init" function would fail by HardFaulting presumably (I was unsuccessful at setting up a debugging project). Through trial and error, I have isolated the fault to be in the HAL_QSPI_Init() function where the "hqspi" function parameter is first referenced to access the hqspi->Instance. From my pseudo-debugging, I have concluded that that function parameter is incorrect and yields all 0xFF for all struct members, causing the HardFault; it almost seems as if that function parameter was corrupted and points somewhere else. 

If somebody with more experience on these external loader projects has a bit of insight as to what might be going on, I would appreciate it. 

[Tesla DeLorean]

These loaders don't enter through startup / main code, assume statics/globals are initialized

You might be able to call __scatterload() in Keil, but probably easier to memset() the structure to zero, and set the QSPI address into the Instance before doing HAL_QSPI_DeInit() or HAL_QSPI_Init() functions.

[grams]

Thank you for the speedy reply. 

I have tried a few iterations of doing something along those lines. I went ahead an tried it with memset() like you suggested but there was no difference. 

I find it very puzzling because I found an example (.FLM) with the STM32F7 that uses the HAL driver like I am trying to do and it works fine (when modified for ST-Link).

[Tesla DeLorean]

Make a framework/harness so you can fully test from application space.

Instrument it via a serial port so you understand what's happening internally.

Watch for uninitialized local/auto variables too.

[grams]

I set up the serial port and made an interesting find. It looks like the global variables, namely the hqspi struct, are getting placed, or being referenced to at the very least, at an erratic address. 

text add.:0x20009074         /* local variable placed at expected address range for reference */

QUADSPI.:0xA0001000     /* QUADSPI address for reference */

hqspi add.:0x0000002C     /* hqspi address before calling HAL_QSPI_Init, not in the expected range */

hqspi Inst.:0xFFFFFFFF    /* Should be the same as QUADSPI, but its not */

hqspi add.:0x0000002C    /* hqspi address inside HAL_QSPI_Init function, not in the expected range */

hqspi Inst.:0xFFFFFFFF

Now I just have to figure out why this is happening. 

[grams · Accepted solution]

So it appears to be working now after changing the linker/scatter file from the commonly suggested:

FLASH_LOADER 0x20000004 PI ; FlashLoader Functions
{
  . . . 
}

DEVICE_INFO +0 ; Device Info
{

  . . . 

}

to

FLASH_LOADER 0x20000004 ; FlashLoader Functions
{
  . . .
}

DEVICE_INFO 0x20040000 ; Device Info
{
  . . .
}

I'm no expert on scatter files, but I'll do some more reading to make sure this is acceptable. 

[Tesla DeLorean]

I'm not sure if the Program Address Independence implementation from ST's tools supports the R9 register for data section works properly. There was a brief discussion several years back, but I never got the answers I was looking for, and the logs would imply it was not, but ST built a number of their .STLDR with Keil, so hope it was understood / addressed.

Most .STLDR get loaded in RAM at 0x20000004, the H7's want 0x24000004

The StorageInfo section typically isn't loaded to the STM32 side, just used by the tools to understand the naming and geometry of the memory involved.

[grams]

It's very interesting stuff but I can see how it can get  very frustrating with the lack of documentation on many of the aspects that go into it and the variances of it based on the tools you use.

Thank you for all the help. I appreciate it.