ChibiOS Free Embedded RTOS

Did not get an assertion error, it was used in TX for SPI1 and RX for SPI5, could that circumvent the assertion?
You can see the config that did not throw an error in my earlier post.

The assertion is thrown if you try to start both device drivers at same time.

Giovanni

Where would the assertion show? I started 1 and 5 and didn't get anything during compile time.

Assertions are a runtime thing, the system is stopped in an halt function and a pointer is there to a message.

http://chibios.org/dokuwiki/doku.php?id ... ebug_guide

Giovanni

Giovanni wrote:Assertions are a runtime thing, the system is stopped in an halt function and a pointer is there to a message.

http://chibios.org/dokuwiki/doku.php?id ... ebug_guide

Giovanni

System didn't halt, just SPI5 didn't work.

Meanwhile the journey continues While I'm still trying to figure out debugging I encountered a system halt. I have 2 Threads now ordered by priorities (high, low)

1. Receives a PAL Gpio event and uses and SPIExchange on SPI4 and 3 SPISendStart und SPI1-3.
2. Send lower priority messages on SPI1 with a 1000us wait in between.

Now the system runs for something in between 1-3 seconds and then stops completly. Setting a breakpoint in chSysHalt shows "spiStartSend" as a reason.

I'm using the acquireBus function so it shouldn't be that the bus isn't ready right? Or do I need to check for bus ready as well?

When I use a 200us sleep function instead of the palWaitPadTimeout in Thread 1 the problem doesn't occur. TraceBuffer shows that it's always a similar thread order before the halt. The "SPI Thread AFE" is the higher prio thread.



Is that because I use spiStartSend? I assume it releasing the bus before the transmission is over leads to issues.
Can I release the mutex in the callback function as well?

The functions with "Start" in the name are asynchronous, the function return while the operation is still in progress, synchronous ones are those without "Start", for example spiExchange().

Giovanni

Jup, I got that far

I want the three spi in the high prio-thread to be sent as fast as possible (not waiting for one to finish the sync send of the other)
Now trying to figure out if I can
a) Call spiStartSend in the high-prio thread and somehow release the mutex of the bus in the callback of the spiStartSend
b) Create 3 different threads and release an event from the high prio-thread. Then I can call the SPI in each of the thread synchronously

Look at SPI demos, those have 2 thread competing for SPI access, you could do something similar, it is the simplest approach.

Giovanni

The STM32F7xx-SPI Demo was my starting point, however all the threads there are executed synchronously (spiSend/Exchange). However I need my 3 SPIs to fire as fast as possible after the high-prio thread finished, as well have a slower, async messages on that bus.

If I execute my spiSend synchronously in the high prio thread one has to wait for the other finish:

If I excecute them with spiStartSend they are a lot faster, but if I release the bus directly after calling the function it gets released to early, so no other threads can use the bus without crashing:


I want the latter behavior without the system crashing

That leads my to my options I described above, unsure if there is a 3rd option

Hi,

You cannot have that directly, threads queue on spiAcquireBus() in priority order. SPI functions should not be called by multiple threads together, this is why you have those acquire/release functions.

Assign priorities according to your needs.

Giovanni