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.
Getting SPI to work on STM32F7 Topic is solved
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Getting SPI to work on STM32F7
The assertion is thrown if you try to start both device drivers at same time.
Giovanni
Giovanni
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Getting SPI to work on STM32F7
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
http://chibios.org/dokuwiki/doku.php?id ... ebug_guide
Giovanni
Re: Getting SPI to work on STM32F7
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?
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Getting SPI to work on STM32F7
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
Giovanni
Re: Getting SPI to work on STM32F7
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
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
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Getting SPI to work on STM32F7
Look at SPI demos, those have 2 thread competing for SPI access, you could do something similar, it is the simplest approach.
Giovanni
Giovanni
Re: Getting SPI to work on STM32F7
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
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
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Getting SPI to work on STM32F7
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
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
Who is online
Users browsing this forum: No registered users and 14 guests