ChibiOS Free Embedded RTOS

I believe you need to use the cycle of spiStart/Select/Send/Unselect for each transfer.

Yes I tested that, pre-filled the buffer with a pattern, and all get overwritten as 0. What I'm not sure is whether only the last byte get corrupted or all get corrupted, because the external device is supposed to return {0, 0, 0, 0, 0, 4}. I'll poke around and try to come up with more information ...

Right I agree. Currently I don't believe it has that facility, let me check the document further for this.

Aside from the efficiency issue, any suggestions on the corruption problem? Thanks.

OK thanks, that's reasonable assumption. But we do have code to wait for all activity to finishes, like following:

In ChibiOS, in RX DMA interrupt handler, we have code to clear DMA_CR_EN, and then wait for DMA_CR_EN becomes zero.

while (((dmastp)->stream->CR & STM32_DMA_CR_EN) != 0 ...

In our code which using ST library, the DMA RX is programmed to read just the data, *no* CRC byte included. The STMF4 manual seems indicate everything is handled by Hardware, by the time RX DMA interrupt triggered, as long as we wait for DMA ENABLE bit be cleared, CRC check should have been done and ...

Thank you Giovanni.

To be clear I'm using STM32F407-discovery board. I think we only need to take care of CRCNEXT in software mode. In DMA mode this is supposed to be managed automatically. Following is extracted from STM32F4 manual:


When SPI communication is enabled with CRC communication and ...

Thank you Giovanni.

I compared the version using STM library and using ChibiOS, it seems they are doing the similar things. Regarding 'end of transfer', ChibiOS waits for bit STM32_DMA_CR_EN be cleared, which is a good approach stated in STM32 manual. We tested the same approach in the version ...

Hello,

To communicate my discovery board with an external device, it's required to use SPI in DMA mode with CRC enabled. Firstly we wrote a program using STM library directly, it works very well. Then we rewrote it using ChibiOS 2.6.1 and now got a data corruption. It appears we can send data to ...

Hi Giovanni, now it's more clear that the problem is somewhere in the custom FPGA I'm using to generate external interrupt. It has nothing to do with ChibiOS. I'm very sorry I wasted your time. But I still learn a lot from the conversation with you, thanks again!

Thanks for looking at it, Giovanni.

The program continue running, because I have another test thread which just flash LEDs in order and print messages to serial console regularly, it runs fine while the waiter thread trapped in chSchGoSleepS().

The threads are creates in standard way as following ...