Hi Marcus
Thanks for checking!
But no, still the same problem...
Moving Code from Deck-Driver to App-Layer
Re: Moving Code from Deck-Driver to App-Layer
Looking at the asserts you're hitting it's a good guess that you're taking too much execution time, which is resulting in the communication queues filling up.
If I understood correctly you're moving the code from a deck driver to the app layout, but in both cases you're creating two new tasks and running your code within these right? Or are you running any code in the tasks provided by the system? If you are using the tasks provided by the system then priority is not the same for the app layer task (0, the lowest) (link) and the deck driver task, I would guess this is the system task (link), which is higher. But where you're creating the tasks (app layer vs deck driver) doesn't matter.
For the random assert after a longer time this happens, as you wrote, when the idle task doesn't get time to run and to reset the watchdog. I'm assuming you get this error when running on a priority greater than 0. Otherwise the scheduler should round-robin the tasks on the same prio level and this should not happen.
It's possible to disable the watchdog by building the firmware with DEBUG, but this will probably only hide the problem. Whatever you want to do in your tasks is taking too long and might effect the rest of the system. One thing to keep in mind is that SPI communication takes some time. Even though the tasks yield during the transfer there's a lot of back-and-forth communication for the LPS deck. Not having seen the code I would guess accessing the LPS deck less frequently would solve the issue.
If I understood correctly you're moving the code from a deck driver to the app layout, but in both cases you're creating two new tasks and running your code within these right? Or are you running any code in the tasks provided by the system? If you are using the tasks provided by the system then priority is not the same for the app layer task (0, the lowest) (link) and the deck driver task, I would guess this is the system task (link), which is higher. But where you're creating the tasks (app layer vs deck driver) doesn't matter.
For the random assert after a longer time this happens, as you wrote, when the idle task doesn't get time to run and to reset the watchdog. I'm assuming you get this error when running on a priority greater than 0. Otherwise the scheduler should round-robin the tasks on the same prio level and this should not happen.
It's possible to disable the watchdog by building the firmware with DEBUG, but this will probably only hide the problem. Whatever you want to do in your tasks is taking too long and might effect the rest of the system. One thing to keep in mind is that SPI communication takes some time. Even though the tasks yield during the transfer there's a lot of back-and-forth communication for the LPS deck. Not having seen the code I would guess accessing the LPS deck less frequently would solve the issue.