RT1176 refuse to wakeup up from SLEEP on DMA Interrupt for SPI peripheral

[_Manish]

CM7 on RT1176 is a SPI master and able to communicate with a custom hardware over LPSPI6 at 9600k baudrate using DMA. Where MCU receives DMA Interrupts upon end of each DMA transfers.

The problem starts when enabling tickless power mode. Firmware offloads the SPI data transfer to DMA (especially larger ~12+kB data) so the MCU can sleep during that time. However, the SPI transfer failed to complete when there's no other active tasks - as the MCU actually goes to sleep at that time, and the DMA interrupt which is supposed to wake-up the MCU won't wake it up!

The LPSPI6 module does not seem to clock or power gated, as I can see the data flowing in and out.. until 7th bit of nth byte!

I saw a similar issue https://community.nxp.com/t5/i-MX-RT/RT1050-LPSPI-last-bit-not-completing-in-continuous-mode/m-p/898... on some other i.MX RT part though. However, that ticket has no mention of Low Power Mode.

[Omar_Anguiano]

Hello
Hope you are well.
Regarding the low power, could you provide me more detailed information about the CPU mode and Setpoint you are using?
As the interruption occurs the system should wake up from the power mode however this is not happening, am I correct?

I´m looking forward to hearing more details about this so I can help you find the reason why this is happening.
If you have more questions do not hesitate to ask me.
Best regards,
Omar

[_Manish]

Hello Omar,

Thanks for your reply. And yes you are right, I want to let the system sleep during larger data transfer over SPI bus which happens periodically (every 40ms), and wake up when DMA interrupt occur at the end of data transfer. And this is not happening.

And to answer your question about CPU mode and setpoint - I am using the freertos_tickless example from SDK, which I believe is using the Software control mode.

Let me know if you recommend using Hardware control mode/setpoint method. Also, I wonder if you have any relevant example code?

Thanks,

Manish

[Omar_Anguiano]

Thank you for the additional information!

There are some things that I would like to confirm to identify the reason for this trouble. 
When you set the Low Power mode are you able to wake the device either by a timer or GPIO? It will be helpful to check if one of these interruptions is able to wake up the system.
Are all the interruptions enabled before going to sleep?

For setpoint usage, you may refer to power_mode_switch example. In order for LPSPI to work correctly under any low power mode, you need to check that the clock source is enabled under that power mode and CR[DOZEN] = 0.

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[_Manish]

Hello Omar,

I see the MCU wakes-up from SLEEP on Timer (from GPT module) and GPIO interrupts. Meaning sleep and wakeup sequence works fine!

Are all the interruptions enabled before going to sleep?

I disabled all the interrupts using GPC_DisableAllWakeupSource() and then only enabled those interrupts I need to wake-up the system:

GPC_DisableAllWakeupSource(GPC_CPU_MODE_CTRL);
EnableIRQ(DMA0_DMA16_IRQn); // IRQ for DMA channel associated with SPI bus
GPC_EnableWakeupSource(DMA0_DMA16_IRQn);

EnableIRQ(DMA3_DMA19_IRQn); // IRQ for DMA channel associated with I2C bus
GPC_EnableWakeupSource(DMA3_DMA19_IRQn);

EnableIRQ(GPIO6_Combined_0_15_IRQn); //GPIO Interrupt
GPC_EnableWakeupSource(GPIO6_Combined_0_15_IRQn);

EnableIRQ(GPT1_IRQn);
GPC_EnableWakeupSource(GPT1_IRQn);

MCU wakes-up from SLEEP upon all other three interrupts except DMA0_DMA16_IRQn. For completeness all the interrupts shares the same priority i.e. 2 except GPT which has priority 1.

Please note, the I2C communication (over LPI2C2) works fine during the low power mode - meaning after setting up the DMA transfer (of about 2k bytes of data), the MCU can go to SLEEP and DMA3_DMA19_IRQn interrupt is able to wake-up the MCU. 

you need to check that the clock source is enabled under that power mode and CR[DOZEN] = 0

All three modules - LPI2C2, LPSPI6 and GPT1 are sharing the same clock source, i.e. "24 MHz Crystal Oscillator" - MuxOsc24MOut. So, as the clock is functional for LPI2C2, I presume it should be functional for LPSPI6 as well? I can also see the SPI clock and data signals while probing on SPI bus, so that also indicates that the Clocks are active.

And Regarding DOZEN bit:

Unlike LPI2C, there's no config flag in LPSPI driver which App can use to set the DOZEN mask, so I went ahead and modified LPSPI_MasterInit()

base->CR &= ~LPSPI_CR_DOZEN_MASK;

For I2C, I made sure that the masterConfig->enableDoze = true;

Which takes care of writing 0 to MCR[DOZEN].

Please find the snippet covering SPI communication. Let me know if you need more details. I will be curious to know your thoughts. And at last, I am using the Software controlled Low Power Mode as I did not have luck with setpoint method, with SP method, I see the SPI bus frozen the moment system goes to SLEEP (I used setpoint 1, cpumode Wait and standby enable).

[Omar_Anguiano · Accepted solution]

TCM is needed when using DMA even if he is using DMA with SPI.

It is strange since other interruptions work well with the exception of the DMA which makes me think that the interruption is not generating correctly.
I suggest you set CM7_FORCE_HCLK_EN in the GPR16 register:

Since the CPU goes to wait it will be needed to change LPCG setting for the CM7 clock to level2(run and wait mode).

Additionally, I would suggest you enable all IRQ instead of activating each one individually.
Best regards,
Omar

[_Manish]

Hi Omar,

Setting CM7_FORCE_HCLK_EN in the GPR16 register fixes the problem for me!!  And that was the only missing part, as LPCG setting for the CM7 clock was already set to level2(run and wait mode).

Thanks so much for your help!

- Manish