This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Calls to Spi_transfer from a HWI or SWI

We have a system running on a Tiva evaluation board, reading data from the SPI bus, using callbacks.  On startup, the system calls Spi_transfer from a task, but thereafter the flow is as follows:

// The HWI ISR

MySPICallback ()

{

StampTheBuffer()

Swi_post (MySPISwi);

}

MySPISwi ()

{

ProcessTheData();

SPI_Transfer (); // Callback mode, so mutual recursion of a sort with the HWI.

}

In RTOS 2.12.1.33 this works beautifully, basically as written above, without any explicit management of interrupts - disabling or restoring of interrupts. 

But in 2.16.0.8 the call to SPI_transfer in the SWI gets lost in the HWI and SWI dispatching code, and never returns.

I know that I recently read a post about very nearly this situation (it may not have been the SPI bus but about one of the other callback drivers) explaining that this sort of recursion didn't work in most versions, then was allowed to work in some version or another, then was broken, then was allowed to happen again, as long as one took some precautions or followed some particular practices.

I've decided that that post has all the answers, so I've spent an hour or so looking for it but am now starting to wonder whether it was a late-night hallucination. 

There's not much going on on this system - 1 interrupt per millisecond.

Did some behavior relating to nested interrupts change between 2.12 and 2.16?

I'd be grateful if anyone remembers that post or has any particular insight into this problem.

- Bob

  • Hi Robert,

          Is this the post about this issue you're referring to? From my research, I believe this was an issue that only applied to the UART driver. The issue was a sort of recursion that happened when you called a UART_read from a callback function which lead to sort of a recursion because UART_read could call the UART callback if data was still in the buffer. This could lead to a possible read->callback->read->callback...  sequence from the ISR which could cause the system stack to overflow. To my knowledge this does not apply to the SPI driver.

         Also, nested interrupts is not a possibility in this case as you can't have an interrupt(Hwi) preempt itself. For SWIs also, each SWI runs to completion, can't preempt itself but can only be preempted by a Hwi or SWi of higher priority. I have to say there's been a couple of changes in the SPI driver and TI-RTOS as a whole between 2.12 and 2.16 so my hunch is that it could be a different issue and not the possible nesting of interrupts like you think. We can simplify things and test to narrow it down. If you did a single SPI_transfer from a task does that work? It would help if you can share the relevant part of your application code and config file for me to take a look as well.

    Thanks,

    Moses

  • Moses. Thank you, that is the post, and though unfortunately it doesn't include the magical answer for me, I'm OK saying that my question (does anyone remember that post?) has been answered. As far as my larger question goes, I'm going to re-build the libraries, make the stack bigger, and follow up some other leads. I will start a new thread if or when I have a more focused question.

    Thanks,

    Bob