Storing Images in QSPI Flash

[TonyFocusLCDs]

Hello,

I am using the STM32H747I-DISCO board for prototyping. I was able to load up the "Tutti Frutti" game demo on the board to verify the hardware. In my own application I was able to store a small 320 x 240 image in the internal flash of the STM32H747XIH6 device on the discovery board. I understand how that works.

I have my image data as a C array of uint32_t data formatted as ARGB8888.

My questions are:

1.  How do I compile/build/assemble that data into a .bin or .hex file to load into the external Quad SPI flash available on the discovery board? I just want the image data stored there, not the entire application.

2. What tools do I need besides what comes with STM32CubeMX, STM32CubeIDE, and STM32CubeProg? 

3. If the QSPI flash stores the data as bytes, do I have to do bit shifting conversion as I read the bytes out? What I mean is do I read 4 bytes and shift them into a uint32_t variable or can I just move the bytes from the QSPI to SDRAM (where my frame buffer is stored) and it is just how the LTDC reads the data that determines if the bytes are read as a uint_32_t?

In the game demo, the files stored in the external flash are .hex files, so my guess would be that some how I need to turn my C array (or just the data) into a .hex file that can be loaded into the external flash. I don't know how to do that.

From there I can then access the address of the image in the external flash through the QSPI interface (HAL driver).

Thanks for any help.

[Tesla DeLorean]

If you've got it as a C array, could you just fwrite() that data to a .BIN file on the host system?

.HEX files have been used since the late 1970's so I'd expect them to be well documented, and there to be prolific number of examples. Perhaps look at tools like SRECORD.

Compiling seems like overkill, but you could likely direct data via the Linker Script, and recover .BIN or .HEX data using OBJCOPY

In memory mapped mode the data can be processed as uint8_t or uint32_t, like the MCU internal FLASH, each byte is uniquely addressable, or read as groups.

[TonyFocusLCDs]

@Tesla DeLorean 

Sorry if my questions are too newbie/noob, but I have never had to turn image data into a .bin or .hex file before.

I am running on Windows 11, not sure if command line or power shell has an fwrite() command. Would a Linux Bash shell have that command? And would I just pass it it the data?

I do know I can use OBJCOPY to convert a .bin to .hex. Once I have it in a .hex format I know how to use STM32CubeProg to get the hex file into the QSPI flash.

Thanks for the information, I will look into it.

[Pavel A.]

@TonyFocusLCDs There's no need to convert bin to hex. CubeProgrammer can directly write .bin files if you provide the address to write. Of course if you want to combine a bin file with something else, or combine several bin files, some custom programming will be needed.

[Tesla DeLorean · Accepted solution]

Maybe you work with someone familiar with C programming? Basic C File IO functions like fopen(), fwrite() and fclose() should be sufficient to write a binary array of data to a file.

On Windows, I'd use Microsoft Visual C (MSVC), but there are probably other options at this point.

In STM32 Cube Programmer, it can deal with .BIN or .HEX files. When writing a .BIN you'll specify the 0x90000000 base address of the QSPI memory, and use an External Loader (EL) selection suitable for your board.

STM32CubeProgrammer_v2.15.0\bin\ExternalLoader\MT25TL01G_STM32H747I-DISCO.stldr

#include <stdio.h>

uint32_t ImageData[] = {
...
};

int main(int argc, char **argv)
{
  FILE *f;

  if (argc > 1)
  {
    f = fopen(argv[1],"wb"); // TEST.BIN

    if (f)
    {
      fwrite(ImageData, sizeof(ImageData), 1, f); // Write block of binary data

      fclose(f);
    }
  }

  return(1);
}

[TonyFocusLCDs]

@Tesla DeLorean :

Thanks for the C code, I also found several references of C++ that will do the same thing. I wasn't sure what I was looking for until you mentioned fwrite() as a function. Then I started finding example code.

I have Visual Studio (latest version) so I can recreate what you wrote along with the C++ examples.

@Tesla DeLorean and @Pavel A. :

OK, as I understand it the .bin file is just the hexadecimal numbers. Example, if my array has 0xAF34CD70 then the binary file will have AF 34 CD 70. If that is correct then I do not need to convert .bin to .hex like you both mention.

I can program the QSPI using STM32CubeProg with the binary file. That I know how to do. I just thought since the ST example had me load a hex file that it was a requirement the binary file needed to be converted to a hex file.

Thank you both for your help. @Tesla DeLorean I am going to accept your last reply as the solution. 

As a side note, on my STM32H747I-Discovery board, I have the 2 QSPI flash chips U3 and U14, so mine are MT25QL512 Micro parts. I know they designed the board to take a few options depending on what they could get at a reasonable cost. 

[Pavel A.]

> OK, as I understand it the .bin file is just the hexadecimal numbers. 

Nope, a .bin file is just a sequence of raw binary bytes. Hexadecimal, decimal etc. is text. A .hex file is text, and it contains the addresses with the data.

[TonyFocusLCDs]

@Pavel A. : Will the binary file store 0xAF34CD70 as AF 34 CD 70 or not? I do not want to convert binary data to hex inside my firmware as that would be a huge waste of processing power. If the data is not stored like that, then I will have to convert it to a hex file. I need the data stored exactly as what 0xAF34CD70 is, not as ASCII code or the binary representation of ASCII.

AF 34 CD 70 is what I need, not 65 70 51 52 67 68 55 48. Which file type will store the data exactly like that?

0xAF34CD70 should be 0b1010 1111 0011 0100 1100 1101 0111 0000 and when the binary file is viewed in a hex editor I should see those representations.

Thanks again.

[Pavel A.]

> Will the binary file store 0xAF34CD70 as AF 34 CD 70 or not? 

More likely a binary file will contain 70 CD 34 AF.

AF will be 0b1010 1111. 

[TStra.6]

@Pavel A. ,

I am just going to create a ST support ticket to ask their developers how they specifically formatted the data for their demo application. I need to do all the image data formatting outside the the MCU as that would be a total waste of processing power to have the MCU convert the data into the correct format. The LTDC is looking for the data to be in ARGB format so that if I store (and this works when using the internal flash) 0xAF34CD70 - AF is A, 34 is R, CD is G, and 70 is B. The LTDC requires that the data be presented in that exact manner. If the .bin or .hex stores it as 70 CD 34 AF and it gets read into the LTDC that way then 70 is A and so on which is completely wrong.

Thanks for your help, but I need the actual ST developers who created the demo or support/maintain the demo to explain exactly how they did it.