ChibiOS Free Embedded RTOS

With my fixes in, I've run into another issue - when setting a higher baud rate, the transfer seems to stall with 0 bytes left in the tx DMA and 1 byte left in the rx DMA. Shouldn't happen because MASRX is set - the SPI peripheral should stop and wait for the rx bytes to be read if the DMA isn't keeping up...

Try giving RX DMA a higher priority than TX, if it is a bandwidth problem this should fix it.

Giovanni

Shouldn't be possible to drop bytes, right?

I'll try what you suggested.

I doubt it is a problem with bandwidth.

One byte left in RX DMA means that SPI stopped requesting a transfer too early, I would also check if there are problems with the RXFIFO settings (threshold).

What is the size of the failing transfer?

Giovanni

I remembered this discussion:

viewtopic.php?f=16&t=4140&start=110#p34911

Could you try the proposed fix? (setting the PPRE divider to 1)? there is something strange going on in HW I think.

Giovanni

I'm also dealing with issues with the H743 and SPI. With ChibiOS 19.1.3 there was no output at all and the spi_send was stuck after 3 or 4 iterations.

I updated to the latest trunk (from github), fixed my mcuconf and chconf and now I get an output but it looks very weird:


I attached a small demo project, the ChibiOS_git is the latest pull from the chibios github clone.

Hi,

Does the SPI demo in trunk work for you?

Giovanni

Are you referring to testhal\STM32\multi\SPI? Just discovered that instead of having STMxx_SPI they where now grouped under "multi" (sneaky ).


Tried to compile the "build for STM32H743", chose the ch.elf in the debug config manually and flashed it.

Correction: I get some output, need to figure out if that is what I should expect.

Okay, I modified the example to give out something more simple and now have the same behavior as above: CLK and CS works but no output on MOSI. Code attached, just to make sure i didn't do a simple mistake.



D7 is connected to D11(MOSI) D6 is connected to D13(CLK)

Good, I suggest you try your configuration inside the demo then we can trace the problem in your original code (if any).

I think you noticed that the first transfer in the demo is "circular", the function does not return until the blue button is pressed (the check is in the callback). After exiting the circular operation then SPI is accessed by the two threads that set different parameters and perform variable-length operations alternating access.

I have no access to instrumentation for a while here... we are all locked working from home by this virus thing.

Are you referring to testhal\STM32\multi\SPI? Just discovered that instead of having STMxx_SPI they where now grouped under "multi" (sneaky ).

There are way too many test projects, I am consolidating them into those "multi" projects, it is also a good example about how to write portable code.

Giovanni

bump and moving in bug reports....