QSPI data is incorrect when using the APP_TYPE = BOOT_SRAM

[Electro-Jam]

QSPI data is being corrupted when using APP_TYPE = BOOT_SRAM.

Repro:

1. Use the QSPI DaisyExample
2. Setup the Daisy Seed to run the Daisy Bootloader for APP_TYPE = BOOT_SRAM
3. Make the needed modifications to the launch.json files to support the SRAM launch and debugging.
4. Set a breakpoint on line 59

    hw.qspi.Erase(address, address + size);

5. Set a breakpoint on line 60

    hw.qspi.Write(address, size, (uint8_t*)wavform_ram);

6. run through the program for the first time
7. Run past the second break point (post the Write operation)
8. Notice the QSPI memory starts with 0.00000 and starts to smoothly build in a positive direction.
9. Restart the debugging of the program
10. Go to the first break point, so that the erase does not happen, but the system is initialized.
11. Look at the memory location for the QSPI data
12. Notice: The data is corrupt and not the same 0.000 data ramping up in the positive direction.

Expect: the QSPI data remains the same over restarts.

Notes:

• After every restart the QSPI data is consistently incorrect in the same way:
  • Example array items 7-10 are always zero.
• This does not happen when the Diasy Bootloader is not in use.

[Electro-Jam]

Note: as an experiment I changed the QSPI MEMRY segment in the _SRAM.LDS file to this:

  QSPIFLASH (RX): ORIGIN = 0x90100000, LENGTH = 6M

This fixes the issue.

I was wondering if there was an alignment issue happening due to the 0x90040000. I'm not sure if that was really this issue, but once I changed the to the 0x90100000 the QSPI flash seems to be returning correct data for me now across restarts.

Also, please note: the 6M in the above may not be accurate, I placed something there to give the starting memory location change a try and I wanted to share this update.

Hope this helps.

[Electro-Jam]

I had two thoughts this morning, I will try one of the two later tonight my time. 😊

1. I am wondering if the data structure that I put in QSPI memory should have the attribute packed?”
2. I was also wondering if in the linker script could the ALIGHN(4) be incorrect for the QSPI flash sections? Note: this is just a hypothesis but might be one reason all the zeros show up and don't when I start at a different location in memory.

I was thinking about both of these because when I looked into the memory before and after the Flash, then restart, then read the memory was consistently "corrupted" in the same way. Example from above: array items 7-10 were always zero. This type of pattern was common no matter the type of data I was using.

I wanted to share that idea in case it helped.

[takumi-ogata]

Hi Brett,
Thank you for writing a detailed report. We will have a closer look at this as soon as we can.

[CorvusPrudens]

The main issue you're probably facing is that your original code was using the same address space in QSPI for the program itself and anything you later wrote to it. The Daisy bootloader uses the region beginning at 0x90040000 for the program, which can be anywhere from a few kB to around 500 kB. It's probably a good idea for us to adjust that BSS region for the linkers that use the bootloader in any case.

I wouldn't mess with the packed attribute or the alignment in the linker. If you're storing arrays, the data is already "packed." If you're storing a lot of your own structs, just place data types of similar size together if you're really worried about the density. Using the packed attribute or changing the alignment might result in read or write issues if the QSPI peripheral doesn't support unaligned operations. I haven't specifically checked the manual on whether it's an error, but it's generally not a robust approach.