STM32H743VG QSPI in double flash mode for driving external DAC

[JWizard]

I need to make 2 DAC channels 4bit each. I plan to use QSPI in double flash mode.

Task is to play prerecorded samples from RAM cyclically. Samplerate is 45Msamples/second

I plan to use DMA in circular mode to send data from RAM to QSPI

Are there limitations on summary samples count? Because I see data size fields in QSPI  registers

Are there any other limitations for my setup?

[KDJEM.1]

Hello @JWizard and welcome to the community :),

Which QSPI frequency and mode are you using?

Could you please share a QSPI register screenshot?

Please try to decrease the OCTOSPI frequency by increasing the prescaler.

I hope this help you!

Kaouthar

[Tesla DeLorean]

In memory-mapped you could likely feed directly from QSPI. Can also read via commands

Bandwidths do seem rather high, any other things that are going on that might cause contention?

Data for play-back in internal RAM or SDRAM?

DMA has a 16-bit transfer count, so the amount of memory will be dictated by the width being read. Also double-buffer (ping-pong) modes.

[JWizard]

I am starting pcb design for project.

I want to be shure that when I choose This microcontroller, it Will work as i want. 

Qspi frequency 45mbit per second

Indirect Mode, no commands, no address, double flash enabled

I other words I want to use it as 8-bit spi.

Questions are:

1. Will Qspi work With circular dma from internal sram to Qspi?

2. Is there a limitation on bytes count? I am asking, because there are some qspi  registers where flash size is mentioned. Will qspi stop sending data when flash size bytes count is reached? 

[Tesla DeLorean]

Ok, so you don't want to use it as FLASH, but rather use the BUS for some secondary use case.

To a FPGA/CPLD perhaps, not sure it's going to sustain continuous activity in a synchronous sense.

Pretty sure the H743 doesn't facilitate a memory-mapped WRITE

Command level to a QSPI NOR FLASH, pages are 256-bytes. I think you can burst write significantly more. But in any case you're not going to be able to stream in a continuous synchronous fashion.

[tjaekel]

My thoughts:

OK, connect two DAC via QSPI interface (OCTOSPI, where two banks are configured).

"Direct Memory Mapping Mode" will not works - you have to use in "Indirect Mode (writing data to QSPI DR FIFO register via SW).

Memory Mapped Mode would send all the time a preamble with a CMD, ADDR (and maybe ALT) which would not be understood by your DAC. And the address would be always something like 0x60000000...0xAFFFFFFF (now way to send an address outside this range).

OK, "Indirect Mode". But there is a delicate detail: every transaction starts with a CMD (at least one byte). The QSPI in STM MCUs are not "simple QSPI" - they are intended (only) to connect external memory (NAND, NOR,. PSRAM).

You can "fake" it: if you want to send the 1st byte (word) which is actually CMD (in indirect mode) - you can transmit any byte/word. Just to be aware off: the first data byte/word goes into CMD register for QSPI. You can skip ADDR and ALT words - but not CMD.

Check the protocol for QSPI on your DAC - check, how it would look like when sending a "faked" QSPI Memory Transaction (in Indirect Mode), where the data for the DAC should go (e.g. into CMD register, into ADDR /ALT register).

Also very important to know!

• When you send CMD, ADDR, ALT - all these as sent as "MSB First"
• and CMD, ADDR, ALT as words are "Big Endian": the highest part comes first
• BUT! when you do a write - and you send data as payload - they are also just and only MSB fist, but now the words are sent as Little Endian (the lowest byte first)

The QSPI in STM32 MCU is not a "regular SPI"! For instance: you cannot drop all phases, at least CMD is needed.
And all remains "MSB First": if your DAC expects "LSB First" - you had to flip all the bits (the OCTOSPI does not do/ does not support "LSB First"). And when transmitting words, e.g. assuming PCM values, as 165/24/32 bits - the Endian (byte order) changes during a transaction.

Possible, in "Indirect Mode" only (but still possible to use DMA). Just create a "mapping" for the QSPI protocol you need (for the DAC) and how the OCTOSPI has to be used (which parts, e.g. CMD, ADDR, and in which "format" to write those values).

I have QSPI working for a Non-memory devices, but very tricky to "map" the OCTOSPI features to the resulting protocol you want to generate. Possible - but not standard and not straight forward.