How to Start/Stop hardware interrupts of LPUART in Transfer mode (i.MX RT)

[Maciek]

Hi,

When using LPUART in Transfer mode there are no options in 'Hardware_Interrupt_Start_Stop' block listed in 'Interrupt Handlers' field in the block mask. Why ? Interrupts are used by the driver in this mode and it would be convenient to be able to temporarily stop/start them (e.g. to protect global variables accessed from main model and interrupt handler). How to start/stop interrupts when peripheral is in Transfer mode ?

Is it safe to just clear RIE bit in CTRL register using 'Register Write' block to temporarily stop 'Read Transfer Callback' from execution ? Is it safe to clear TIE bit in CTRL register to temprarily stop 'Write Transfer Callback' from execution ?

Also I can't see LPI2C peripheral in the 'Interrupt Group' field of 'Hardware_Interrupt_Start_Stop' block. Is it by design ? If yes: why ?

Thanks
Maciek

[ioanapirjol]

Hi @Maciek

The interrupt handler for LPUART in Transfer mode does not appear because, during development, we considered that since the Interrupts Enable/Disable operations are handled internally by the SDK transfer functions, there will be no need for the user to interfere in that workflow. For the LPI2C Interrupt group, the logic is the same as for LPUART peripheral - the only 2 modes supported are Polling and Transfer (as seen in ConfigTools) and the interrupts operations are handled internally, so the handlers were not added to the ISR blocks - but since this is something that is needed in your application, we will add the necessary modifications for this toolbox release, so that you can Start/Stop the interrupts when the peripheral is configured in Transfer mode.

As for your question about temporarily stopping the Callback routine, I am not sure if it would be safe to just clear the register fields: from what I see in the implementation of the SDK DisableIRQ function (which is used by the Hardware_Interrupt_Start_Stop), two synchronization barriers (for memory access and instructions) are used before completing the routine, so I think that trying to disable them using register blocks (+ in application context) might generate unexpected behavior.

Kind Regards,

Ioana