Configuring OCTOSPI on a STM32H723/STM32H730

[JCoop.2]

I'm having an issue configuring the OCTOSPI for accessing an external HyperRAM (Cypress S27KL0643) connected to OCTOSPI1.

My basic issue is that the STM32 doesn't provide a chip select or clock when I attempt to access the chip.

I'm suspect I'm misconfiguring the OCTOSPI in some fashion, but I can't figure out what I'm doing wrong.

I'm using MxCube.Version=6.3.0 and running on a Nucleo STM32H723 and on a custom board using a STM32H730 and seeing the same problem on both boards.

I don't actually have a HyperRAM chip on the Nucleo, but since the issue I'm currently having is that I can't get a CS or clock out from the OCTOSPI, I figured it wouldn't really matter if there wasn't anything connected to the STM32 to talk to. I just wanted to see those signals change on a logic analyzer.

As part of my debug process, I enabled a free running OCTSPI clock as I wanted to see if that would continue to be generated by the STM32 but I found that when MX_OCTOSPI1_Init() is called, the freerunning clock starts and then stops shortly afterwards.

Looking in further, it's actually stopping during the call to HAL_OSPIM_Config().

Here's what the signals are doing:

Clock and CS are the OCTOSPI signals. Reset is a GPIO to the chip (active low).

I'm setting/clearing DBG2 around the calls to HAL_OSPI_Init() and HAL_OSPIM_Config().

I see that the CS goes high and the clock starts near the end of HAL_OSPI_Init() which is what I was expecting. However, the clock stops in the middle of the HAL_OSPIM_Config() call. That I wasn't expecting.

Is this a valid test? That is, should I expect the free running clock to stay running after the configuration of OCTOSPIM?

I also logged the state of the OCTOSPIM registers during the initialization process:

Debug: app: Before HAL_OSPI_Init (0x5200b400)
Debug: app:      CR: 0x00000000 (0x5200b400)
Debug: app:    P1CR: 0x00000000 (0x5200b404)
Debug: app:    P2CR: 0x00000000 (0x5200b408)
Debug: app: After HAL_OSPI_Init (0x5200b400)
Debug: app:      CR: 0x00000000 (0x5200b400)
Debug: app:    P1CR: 0x03010111 (0x5200b404)
Debug: app:    P2CR: 0x07050333 (0x5200b408)
Debug: app: After HAL_OSPIM_Config (0x5200b400)
Debug: app:      CR: 0x00ff0000 (0x5200b400)
Debug: app:    P1CR: 0x03010111 (0x5200b404)
Debug: app:    P2CR: 0x07050333 (0x5200b408)

Those look like what I'd expect to see in those registers.

I've got a minimal example that shows what I'm seeing at:

https://github.com/repoocaj/H723_basic/tree/dev

If anyone can suggest some things to look at or possible problems with how I'm initializing, I'd appreciate it!

thanks,

Jeff

[Tesla DeLorean]

Not personally using the RAM devices, but I have fixtured a SOP16(W) socket to the NUCLEO-H723 for QuadSPI devices (Micron, Winbond, Macronix).

I think I'm working with a different subset of pins, and at least one on the header looks to be potentially conflicted, or have a stub.

I think all the pins can be pulled from the connector to implement an OCTO device, I'll pull the pin diagram when I get back to that system.

[Tesla DeLorean]

[JCoop.2]

Found out what was causing me not to see a CS/clock, but still don't know why it's occuring.

There were two things that were contributing to the issue:

1. Configuring a free-running clock.
2. Setting the device size to anything other than 32. I had configured it to 22 for an 8 MB device based on the documentation for the DEVSIZE bitfield of OCTOSPI_DCR1 in section 25.6.2 of RM0468. However, looking at the HAL source code, they're doing the subtract one internally, so the correct value I should have been using would have been 23.

Once I disabled the free-running clock and set the Init.DeviceSize structure to 32, then I could see activity on the configured CS/clock lines when I attempt to do a read/write.

I'd be interested in hearing from anyone at ST as to why the DEVSIZE needs to be set to 32.

[Tesla DeLorean]

Well that's interesting, DEVSIZE = 0x1F (the register setting) allows for 4GB Indirect Access modes

I can't say I've encountered any discussions about it's need for free-run