ChibiOS Free Embedded RTOS

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 th...

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 macro. */ +^M +#if...

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 ...

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) start) % CACHE...

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 cache...

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 cor...

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 ...

Hello geebee, I have question about your implementation, You do up to 2 cacheBufferFlush in your invalidate function, can you explain the rational behind that ? I don't say it's a problem, it's just i want to understand. FatFS has something like this (conceptually): struct __attribute__((packed)) s...