Skip to main content
Visitor II
June 12, 2025
Question

STM32N6570-DK XSPI flash incorrect data

  • June 12, 2025
  • 2 replies
  • 547 views

Hello,

I use an external flash in memory mapping mode and I have a strange problem. The application is executed from the internal RAM, while the checksum is calculated on the data from the external flash (simple summing of successive bytes in a loop). Interestingly, sometimes I get an incorrect result, i.e. the sum is a bit smaller, e.g. instead of 3233257 it is 3233225 as if one byte had not been counted. Interestingly, later the program jumps to the application that is executed from the external flash and it works normally (does not crash). I tried to turn off D-Cache but it does not help. Since the program from the flash executes correctly, I assume that it is not a problem with the memory configuration. What could it be?

EDIT:

I will add that the memory is configured using the ExternalMemory manager. I added a second identical image in flash memory in a different location and for which I calculate the checksum simultaneously and interestingly for both the same problem occurs alternately, exactly at the same offset byte 0x20 is changed to 0x00 offset 0x2fe0b. When I stop the debugger after some time there is already the correct value 0x20. D-Cache is disabled. I still do not know what the problem is..
 
EDIT2:
It seems that reducing the XSPI clock frequency from 200MHz to 160MHz solves the problem. However, I still do not understand why the program executes correctly from flash.
 

 

BR

Artur

    This topic has been closed for replies.

    2 replies

    Technical Moderator
    June 16, 2025

    Hello @Artur5;

     

    Thank you for sharing the issue and your investigation.

    It seems that reducing the XSPI clock frequency from 200MHz to 160MHz solves the problem. However, I still do not understand why the program executes correctly from flash.

     

    The maximum frequency of XSPI depends on several factors, including: memory characteristics, the specific STM32 devices used, OCTOSPI pins, the operating modes (SDR, DTR, HyperBus), the system clock, the OCTOSPI kernel clock... Each of these factors can significantly impact the achievable maximum frequency.

    The user should refer to the datasheets of both the STM32 and the memory to find the maximum OCTOSPI frequency and the conditions required to achieve this frequency.

    KDJEM1_0-1750070675592.png

    KDJEM1_1-1750070708602.png

    KDJEM1_2-1750070737358.png

     

    Thank you.

    Kaouthar

    Artur5Author
    Visitor II
    June 16, 2025

    Hi. Thanks for your reply. I am using the STM32N6570-DK discovery board as mentioned. Is it designed to work with a 200MHz XSPI clock?

    Artur

    Technical Moderator
    June 16, 2025

    Hello @Artur5 ,

     

    The STM32N6570-DK discovery board designed to support maximum frequency.

    I'm asking about the software, the software must ensure that SSHIFT = 0 when the data phase is configured in DTR mode (when DDTR = 1), GPIOs is configured very high-speed.

     

    KDJEM1_0-1750083334686.png

     

    Are you starting from an XSPI examples or XSPI templates?

    May be these examples can help you.

     

    Thank you.

    Kaouthar

    Artur5Author
    Visitor II
    June 16, 2025

    I use ExtMem Manager to configure memory. As I wrote above, the problem is only when calculating the checksum in FSBL and it is always an error in the same byte. When calculating the checksum, the next bytes from Flash are added (about 300kB). Later, the code starts executing from Flash (XiP). I have not noticed that the application has ever crashed. This is strange to me. I also see a changed byte when I stop the application under the debugger. It happens more often when the board is disconnected from the power supply for a moment.

     

    Artur5_0-1750085157608.png

    I use multiplexed flash access. On xspi1 I have indirect access, xspi2 is mapped. Everything works very well, except for this problem with a corrupted byte from time to time.
     
    Artur5_0-1750085708116.png