STM32U5A9 OctoSPI memory mapped (read only) with NOR FLASH triggers hard fault on first access.

[RMand]

I am trying to bring up the MX25UM51245G NOR Flash connected to OctoSPI 1 on a STM32U5xx development board. I have implemented most of the actions specified in AN5050 to set up this NOR Flash.

Since my use case does NOT require the ability to have the MCU write to the flash, I have only implemented the read mode of the memory mapped interactions.I have generated code using CubeMX and have set up the memory component as follows:
    1. HCLK is 120Mhz.
    2. Single Data Rate (expect the OctoSPI to run at 60Mhz).
    3. OctoSPI clock prescaler set to '1' ==> expect this to generate a 60Mhz clock to the OctoSPI.

When I run the firmware I see that the  MCU has no issues accessing the OctoSpi and the OctoSpiManager on the MCU. I also do not see any 'obvious'  errors when the MCU interacts with the memory's SPI component in 'indirect' or 'auto polling' mode.

Then I enable the readonly memory mapped mode (based on example in AN5050) but the very first access to address location 0x9000000 generates a precise hard-fault.

Trying to correlate the documentation to the example source code to the 'tutorial videos' has been challenging at best and I am running out of ideas -- any clues would be a big help.

This would have been a piece of cake when Iused to work with the STM32 verilog hardware designs -- ah well....

[Tesla DeLorean]

Address should be 0x90000000 not 0x09000000.

 

[RMand]

Thanks, but I do have it correct in my firmware -- just missed out on one zero when asking my question.

[Tesla DeLorean]

Ok, the wrong address would fault for sure. If it's the right address double check that it's successfully engaging Memory Mapped, that's it not been aborted. Check OCTOSPIx / SPIM clocks, and dump registers. Check the memory size field.

[KDJEM.1]

Hello @RMand ,

I recommend you to get inspired from an available OSPI_NOR_MemoryMapped example in STM32CubeU5.

This example describes how to erase a part of an OSPI NOR memory, write data in memory-mapped mode and access to OSPI NOR memory in memory-mapped mode to check the data in an infinite loop.

Also, I advise you to check the Errata sheet and precisely the 2.5 OCTOSPI section.

I hope this can help you!

[RMand]

Thanks....

The example did help me out quite a bit -- but just not all the way through. For starters, my use case does NOT require erasing/writing of the memory so I took it out -- but the remaining firmware is what triggered my post here. There is also the minor fact that the memory in that example, and the MCU on that board, are different and require ever so slightly different values to be used. 

Last but not the least -- this is the first time I am trying to set up a commercial SPI slave device in memory mapped mode and it would have been really, really nice to have found some/any documentation describing at a very high level the sequence of steps required (regardless of the nitty gritty details such as clock cycles, etc.) to design and bring up this system -- I have done it a few times but with custom MCU cores and busses.