QSPI and NUCLEO_H743ZI2

[IrekRM]

Hello,
I recently found out the release of the Mbed CE 7.0 and decided to try it out, as I have a project on hold for Mbed 6.xx.
In this project I use the NUCLEO_H743ZI2 board to connect to FPGA using QSPI for data exchange. With Mbed 6.xx, I found that it was impossible to transfer several kilobytes continuously — there were always breaks during the data transfer. So I was happy to see in the mbed-ce 7.0.0 release notes that "Fixed All STM32 MCU families: QSPI and OSPI drivers updated to use DMA internally. While they still don't support asynchronous transfers, the transfer rate has been substantially improved."
I have redesigned my project for Mbed 7.0 and it seems that now data writing is going well and really faster, but data reading still strange. I do in my code next data reading:
qspi_status_t result = qspi_device.read(RXbuf[1], RXbuf[2], ((RXbuf[0]&0xFF)<<8)|(RXbuf[3]&0xFF), &TXbuf[6], &datalen);
Here 4 bytes are sent with a command for the FPGA, and then the datalen bytes in TXBuf must be read.
If the datalen is less than 32 bytes, everything is fine, but if it is larger, there are gaps in the transmission - see, for example, the two screenshots of logic analyser window for 32 and 36 bytes reading, respectively.
.
And these three data chunks from the bottom figure are always present when I try to read more than 32 bytes - just middle part is increasing with increase of datalen.
Does anyone have any ideas why this is happening?
Or how can I contact the person who changed the QSPI driver code in Mbed CE 7? Maybe he can give me some advice.

[multiplemonomials]

Hmm, I suspect this might be due to cache line weirdness. IIRC, the transfer can only be done using entirely DMA if it's a multiple of 32 bytes. Otherwise it has to do some using the CPU, then the rest using DMA.

[IrekRM]

Thank you for suggestion. I agree that this problem relates to the DMA <-> QSPI exchange. When I read 32 bytes the total QSPI transmission is 36 bytes - there are 4 bytes as instruction-address-alt bytes at the beginning. But for when number of read bytes larger than 32 there is laways 3 chunks in transmission - and only the length of middle one is changing. The worst thing is that the CS signal for each chunk returns to the high state, which makes the output of FPGA crazy.

[wdx04]

Yes, this is expected behaviour. In the worst case, unaligned QSPI access may be split into three chunks. So try to use 32-byte aligned QSPI access on STM32F7 and STM32H7, if possible.

[IrekRM]

Thank you, but could you please add some more info how I can do this? I mean to use 32-byte aligned QSPI access ?

[wdx04]

1.Make your tx/rx buffer 32-byte aligned:

char buf[256] __attribute__((aligned(32))); // local or global

or

#include "stdlib.h"
char *p = (char*) aligned_alloc(32, 256); // dynamic

2.The length passed to read/write functions should be a multiple of 32, if possible.

[IrekRM]

Thank you very much! I'll try this magic receipt tomorrow!

[IrekRM]

Hello,
Unfortunately, the 32-byte alignment trick helped, but not much. Now three pieces in the reading transmission appear after 56 bytes — see the pictures below:

I also show the 1024 = 32 * 32 byte transmission as example. And I use global static buffers to keep data.
Any other ideas? Thanks in advance!

[IrekRM]

printf("RX buffer: %p\n", rx_buffer);
RX buffer: 0x24005346

[wdx04]

0x24005346 is not 32-byte aligned. An aligned address should end with X0, where X is an even number.

[wdx04]

Maybe the compiler you are using does not support the aligned attribute? Then try C++'s alignas:

    constexpr size_t buffer_size = 32768;
    alignas(32) static char buffer[buffer_size];

[IrekRM]

I found my mistake. I used next buffer definition:
char TXbuf[BUFFER_SIZE] __attribute__((aligned(32)));
And next command to read data:
qspi_status_t result = qspi_device.read(RXbuf[1], RXbuf[2], ((RXbuf[0]&0xFF)<<8)|(RXbuf[3]&0xFF), &TXbuf[6], &datalen);
I place the data since TXbuf[6] — I need this for the remainder logic. And this was a mistake!
So I changed to the
qspi_status_t result = qspi_device.read(RXbuf[1], RXbuf[2], ((RXbuf[0]&0xFF)<<8)|(RXbuf[3]&0xFF), TXbuf, &datalen);
And now YES—I see one QSPI transfer for any number of bytes that is a multiple of 32!!!
Thank you very much for your help!

[wdx04]

Glad I could help!

[IrekRM]

I looked the STM32H743xI/G datasheet and found next figure:

Could my problem be caused by the fact that QSPI is in domain D1, while SRAM1 and SRAM2 are in domain D2?
Is it possible to lock the QSPI input buffer in AXI SRAM, which is also located in the D1 domain, just like QSPI?
It is just an idea - I'm not an expert in all this stuff.

[wdx04]

Both AXI SRAM and D2 SRAM are much faster than QSPI. It should not affect the speed of QSPI. Also, Mbed uses AXI SRAM by default, all global variables are located in AXI SRAM.