Hi, Could you please add some more information about the configuration like "CONFIG_STM32F7_DMACAPABLE", "CONFIG_SPI_TRIGGER", "CONFIG_STM32F7_SPIx_DMA_BUFFER" and "CONFIG_STM32F7_SPI_DMATHRESHOLD". Also the D-cache configuration like "CONFIG_ARMV7M_DCACHE_WRITETHROUGH".
I do not see obvious issue except mirror improvement where "up_clean_dcache((uintptr_t)txbuffer, (uintptr_t)txbuffer + nbytes);" can be used instead of "up_flush_dcache((uintptr_t)txbuffer, (uintptr_t)txbuffer + nbytes);", but that obviously should not lead to random extra bytes. Best regards, Petro чт, 22 черв. 2023 р. о 16:14 Oleg <ev.m...@gmail.com> пише: > Hi all, > > I'm working with custom stm32f7 board and PX4 old fork, where I have my > module that writes in several chunks some data (289 bytes) inside one of > the partition of MTD mx25lx at SPI1, while there is PX4 params module that > autosave parameters on changes in another partition of the same MTD. > And sometimes data in my part of MTD (at least) gets corrupted by a couple > of zeroed bytes, I can check it by rereading right after writing. > > It does not always happen and it's quite tricky to catch. There is no issue > if no parameters change in parallel or if I disable > CONFIG_STM32F7_SPI1_DMA. > > As for me looks like potential issue with dcache, especially taking into > account I'm quite "lucky" for such issues (: previously were "SD FAT32: > Write failed with err 28 (no space left on device)" that was fixed in > https://github.com/apache/nuttx/pull/5062 and "Potential UDP packets loss" > that was fixed in https://github.com/apache/nuttx/pull/6831. > > Unfortunately I don't have enough perception of dcache, how to debug such > time-related things, so I'm looking for any advice. > > --- > With best regards, Oleg. >
