ChibiOS Free Embedded RTOS

Hi,

I spent quite a while figuring out why I couldn't get sleep and USB working on a project using a H743, and it turns out it's a known problem, described in this old thread: https://forum.chibios.org/viewtopic.php?f=16&t=1798
What happens specifically is that the current code uses BOARD_OTG2_USES ...

Hi,

I needed to use ADC5 for a project. Caveat: the project uses v20.3.2, where I know for sure it works. I ported my changes to master, and as far as I can tell only the newline style changes for the files affected, however I won't be able to port the project for testing for a long time (ideally ...

This is what I ended up changing in ChibiOS:


--- a/os/common/ports/ARMCMx/chcore_v7m.h
+++ b/os/common/ports/ARMCMx/chcore_v7m.h
@@ -502,9 +502,18 @@ struct port_context {
* @brief Computes the thread working area global size.
* @note There is no need to perform alignments in this ...

Giovanni,

do you plan on adding an "official" example showing the proper way to use FatFS on the H7? I'm having a hard time getting it to work via MPU region settings.

Setting up the object is still a bit awkward, because it needs to be in a region with size a power of two, and aligned to its size ...

That also would need changes to ChibiOS. On STM32H7 SDMMC1 cannot do DMA from/to any of the memories that are currently supported for disabling caching (SRAM1+SRAM2, SRAM3).

Up to you to do what you think it's best, as I said before mine was just a suggestion on how to fix it. Thanks.

GB

Here's what I would do (also attached)

--- a/os/hal/ports/common/ARMCMx/cache.h
+++ b/os/hal/ports/common/ARMCMx/cache.h
@@ -84,6 +84,8 @@
#define cacheBufferInvalidate(saddr, n) { \
uint8_t *start = (uint8_t *)(saddr); \
uint8_t *end = start + (size_t)(n); \
+ chDbgCheck((((uint32_t ...

I'm not sure I see how that would work.

If the unaligned invalidate is done with interrupts disabled, you still have the case where after it completes the thread that invalidated is waiting on DMA to complete, so you could switch to another thread that then proceeds to read or write one of the ...

Thinking some more about it, this problem can potentially affect anything else that uses DMA. For example, if you allocate a small buffer for a SPI transfer that ends up on the same cache line as other global data used by other threads, you could have the same behavior you outlined.

So maybe the ...

Actually, I was experimenting a bit with things, and at least for our use the following seems to work well, requiring no changes in FatFS, and only requiring to add the (regular, aligned) flush/invalidate to fatfs_diskio.

Basically manually allocate a larger buffer, and incapsulate it into a method ...

True. The extra stuff at the beginning of the buffer is safe in this specific case, but not in general. And even for this case the linker could put data accessed by other threads after the end of the buffer.

The ideal fix would be for FatFS itself to move the buffer to the beginning of struct FATFS ...