2023-02-02 06:59 AM
Hey Octospi experts,
I just got an external quad-SPI SRAM (AP6404L-3SQN) running via the H723's Octospi.
At least mostly...
No HAL use, only direct register settings (except for writing via DMA, still using HAL_MDMA_Start_IT() to trigger the transfer).
Right now Memory-Mapped reading* is working, so does DMA writing.
And good that I tested with write / read buffers > 1024, the SRAM's page size, so that I found the page wrap problem early.
Question:
There are many STM32 registers concerning WRAP stuff, but can I set these up so that I don't need any other precautions vs page wrapping?
Esp. when doing memory-mapped reading (with the 8 byte limit) and DMA writing (probably not, as the ref manual says)?
Before spending another week on that and wrecking my nerves, I better ask here.
I honestly admit that I don't really understand the (slightly thin) documentation about the wrap part in the ref manual (RM0468, pg 923) - and I experienced that this is not always 100% reliable.
* Memory-Mapped writing is NOT working 100% reliable (sometimes it does...), as expected after advice from AP-Alex and this thread:
2023-02-02 11:09 PM
Any hints or ideas anybody?
2023-02-08 01:49 AM
Nobody?
I really get some strange results, sometimes it's wrapping, sometimes it doesn't, depending on compilation, without having changed any OCTOSPI registers.
2024-10-01 08:55 AM - edited 2024-10-01 08:58 AM
@LCE Any progress here? I'm running into the same issue. It seems like the wrap setting in CubeMX have no effect on what the MCU does. I can look at the signal level and see it's treating the interface as if there is no wrap.
Will make a new thread if you haven't found the answer.
Edit: seems like I made this too soon. It looks like memory mapped writes are simply not fully supported on the H723 with AP memory. Okay, that's that. Weird for STM32 to have an "AP Memory" setting if that's the case.
The more I read into troubles and erratas it feels like the OCTOSPI interface is quite half-baked on the STM32H7. Maybe newer families are better.
2024-10-01 11:25 AM
Yes, there are a documented limitation for supporting Quad SPI SDR memorry mapped write on STM32H723. OCTAL SPI Memory controller is full spec. Newer MCU have this QSPI limitation solved.
Alex
2024-10-01 11:57 AM
>>it feels like the OCTOSPI interface is quite half-baked on the STM32H7
Well at least 3 models of H7 and differences in the H72x/H73x vs H7Ax/H7Bx
The whole concept of SPI RAM and page sizes, vs MCU using in a random access and potential RMW fashion, likely to cause all manner of headaches from the outset.
This is compounded by failure to properly validate silicon (or the design prior to tape-out), and not fix issues. Whilst I understand the keep-moving-forward strategy is does leave in it's wake a lot of unsatisfactory parts, and a commitment to keep making them for 10 years..
I'd much prefer to see earlier retirement / EoL on broken stuff, and direct replacement in form-and-function
2024-10-01 03:14 PM
@Alex - APMemory Thanks for the reply.
I was able to get this working by limiting the transaction length to a single byte. At 100 MHz clock speed, I can read 8 bits in 145 ns (yes, 14.5 clock cycles, not 14 or 15) which is a data rate of 55.1 Mbps. This avoid the mis-handling with wrap size, which occurs on both memory mapped reads and writes. But what a mess getting there.
ST's hardware is usually great and it's the software that is lagging behind. This is certainly one exception. The errata for OCTOSPI on this chip is huge. One item in there says that two registers just flat out don't work. How did that pass any sort of internal testing? Hopefully whatever comes after H7 does a better job here.
2024-10-02 12:19 AM
I actually gave up on using a quad RAM - and a good idea that was, seeing that you only get 55 Mbps...
I need at least 55 MByte/s.
I somehow got a H735 dev board including the octal HyperRAM, and that worked like a charm, also on my custom board with a H733 and a newer version of Infineon's HyperRAM.
The only drawback: it's a BGA - which we still try to avoid in our small company, not having the tools to change or repair these.