SPI DUART driver -- are ioctl/fread/fwrite calls ISR-safe?

[dmarks_ls]

I'm using CW 7.2.1 and MQX 3.6.0 with the M52259EVB, and writing a driver for the SC16IS752 SPI-based dual UART.  The DUART has an IRQ* output which I've attached to IRQ7.  SPI is connected normally to the QSPI port (CS0).  No other devices are on the QSPI port.

Looking at the SPI memory access example (mqx\examples\spi), one uses ioctl(), fread(), fwrite(), and fflush() to manipulate the QSPI port.  I need to implement an ISR for the DUART, and that ISR will need to perform reads and writes to the QSPI port to access the DUART chip.

My question is, if I use the polled-mode SPI driver ("spi0:"), is it safe to make ioctl/fread/fwrite() calls from within the IRQ7 ISR?  Or do I need to figure out some other way to do this and move all QSPI operations out of the ISR?  Has someone ever done something similar (i.e. implement an ISR for a device connected via SPI/I2C/etc)?  Thanks.

[carlos_neri]

Hi there,

Actually, the ISR on MQX should just be used to post a semaphore, or signal an event, should not call any other functions that might hang the processor, such as a call to a driver.

Your application, in this case your driver for the DUART should wait for the IRQ event and then perform all the QSPI driver calls.

I recommend you to take a look to the section 3.10 of the MQX user's guide.

Also, as last hint, I really recommend you to use a different IRQ than IRQ7, since IRQ7 is a NMI, this makes it impossible to be handled by MQX and you could face several issues.

Hope this helps.

Carlos

[dmarks_ls]

You're kidding me... IRQ7 (PNQ7, pin 96 on MCF52259 144-LQFP) can't be handled as an MQX-aware ISR?  I don't see anything in the datasheet that suggests IRQ7 is non-maskable, or at the very least likely to be handled differently in software.  We used IRQ7 for the DUART because IRQ1 is used by another chip, and we were leaving IRQ3 and IRQ5 alone since those normally belong to the Fast Ethernet port (for MDIO).

I don't suppose the priority/IRQ level of the IRQ7 pin can be altered?  If it absolutely won't work, I suppose I could cut-n-jump IRQ7 to short to IRQ5, ignore IRQ7, and get IRQ5 working; we have a tentative respin of the board scheduled, this would just be one more change.  While I know my way around 8-bit and 32-bit MCUs in general, I'll admit I'm something of a ColdFire noob; I'm just not familiar with how exactly interrupt priorities are handled within the chip.

It looks like I'll have to have a dedicated DUART "interrupt" thread that will service semaphore posts from the ISR to do all the busy work; at least in this context, I should be able to use the interrupt-based QSPI driver instead of the polled-mode one.  The interrupt needs to be level-sensitive, though, not edge-triggered, so I'll have to disable the interrupt source from within the ISR before posting to the semaphore, then re-enable the interrupt source after my DUART thread finishes servicing the DUART.  How easy is it to enable/disable interrupt sources after ISR installation?

EDIT: Looking at the interrupt-based MCF UART driver, ISR installation and interrupt enabling are handled separately, and interrupt enabling just fiddles directly with the relevant bits in the IMR for the UART.  So looks like I'll just have to figure out the relevant bits for IRQ7 (or IRQ5) for my driver, and there's no reason I can't write those in an ISR.  Thanks.