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.

[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, but I do have it correct in my firmware -- just missed out on one zero when asking my question.

[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.

[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.

[RMand]

Hi,

This is the STM32 off the shelf development board -- I could be wrong but I don't believe I have access to the signals that you are referring to. For that matter, being a firmware/software developer, I don't have easy access to any instruments such as oscilloscopes etc. Would love to get to the bottom of this issue without having to resort to such tactics :)

[Tesla DeLorean]

You should have access to RCC and OCTOSPI peripheral registers. The use of printf(), or code to unpack them would be sufficient to check their content. Parking a debug view over them might be more invasive, clearing status, breaking the FIFO, etc.

The HAL peripheral instance should indicate the busy state of the peripheral. If it's not been started into Memory Mapped mode, say that failed for some reason, or was exited, this would Hard Fault if you touch the mapped (effectively unmapped) area. The base address is determined by the architecture, the breadth of the decode by the OCTOSPI_DCR1.DEVSIZE 

Add code to unpack settings in your Hard Fault Handler that's dumping failure context.. should be able to recognize the address as falling within is OCTOSPI's

[RMand]

Thanks for the hints..... much appreciated.

I finally got past the data abort issue. Turns out that the HAL requires that the application also set up the 'write configuration in memory mapped mode' even when the applicatoin only uses the flash in 'read only mode'. Due to this requirement, I had side stepped the final call to call the HAL function that I guess sets up the SPIM in memory mapped mode. In other words -- the SPIM was not set up at all.

The HAL mis-step was a bummer -- don't understand why STM HAL is not smart enough to allow setting up SPIM withou setting up the write-configuration.

Now I need to figure out why the read is not returning the correct value -- perhaps the 'dummy cycles' or the 'clock' need to be tuned some more.

[RMand · Accepted solution]

OK, so I figured out that I had accidentally, in all my experimentation, disabled the external loader that loads the NOR Flash. with the 'expected values'. Now that I took care of it, I am able to read what was externally loaded/written into the NOR Flash. 

Thanks for your help Tesla Delorean and KDJEM1.....