S32K312: unknown signal handler taking program control to LPI2C IRQ handler

[himonkoch]

I am using a custom board fitted with S32K312 MCU. I want to continuously change the pin config and clock config for power saving feature. When testing the MCU gets "stuck" in a high power state, causing increased power consumption.

When I connect my PE-micro debugger to the board and attach to running target, the control always shows up at the "Lpi2c_Ip_ModuleIRQHandler" function. The debug call-stack shows a signal handler at 0xffffffe9.

What is causing this and how can I solve this?

#s32k312

[Julián_AragónM]

Hi @himonkoch,

Could you clarify what routine and configuration you are using when saying "I want to continuously change the pin config and clock config for power saving feature."? 

Are you going to standby and waking up repeatedly? Have you referred to any of the low power examples for S32K3? S32K3 Low Power Management AN and demos - NXP Community & [RTD400 & 500 MCAL & IP] S32K3 Low Power Management AN and demos - NXP Community.

Also, before going to standby, are you de-initializing I2C instance?

Lpi2c_Ip_MasterDeinit(instance);

Please share any relevant configuration or code snippet.

Best regards,
Julián

[himonkoch]

@Julián_AragónM 

This feature does not utilise the standby power mode of the MCU, rather I am reducing the power consumption by disabling certain clocks, reducing the overall clock speed, and disabling certain pin outputs.

This is done using different Clock and Pin functional groups, which I switch between to obtain the desired output.

Also before this transition, I am calling the Lpi2c_Ip_MasterDeinit() function to disable any i2c involvement.

[Julián_AragónM]

Hi @himonkoch

Thank you for the additional information. Are you specifically using Option E - Low-Speed Run mode (CORE_CLK @ 3 MHz)?

I asume you are getting stuck at Lpi2c_Ip_ModuleIRQHandler because LPI2C interrupt remains enabled or pending, although it is quite hard without sharing configuration or routine to test it.

Before switching the clock configuration, abort or complete any pending transfer, you can use Lpi2c_Ip_MasterEndTransfer(), for example. Added to this, try clearing and disabling interrupts through the IntCtrl driver:

IntCtrl_Ip_DisableIrq(LPI2C0_Master_Slave_IRQn);

IntCtrl_Ip_ClearPending(LPI2C0_Master_Slave_IRQn);

Lastly, please make sure that AIPS_SLOW_CLK and LPI2C0_CLK are both enabled when returning from VLSR.

Best regards,
Julián

[himonkoch]

@Julián_AragónM , thanks for the reply.

Yes, this feature is an implementation of the Low Power Run mode, wherein the clock frequency is reduced to 3MHz by reducing the output frequency of the FIRC, and disabling the PLL.

I've tried the steps you've mentioned
1. AIPS_SLOW_CLK and LPI2C0_CLK and successfully enabled when switching out of Low Power run mode

2. IntCtrl_Ip_DisableIrq and IntCtrl_Ip_ClearPending are called right before the mode switch to disable and clear the interrupts associated with I2C.

3. I could not find the Lpi2c_Ip_MasterEndTransfer function in the Lpi2c_Ip header file.

The problem of getting stuck in the mentioned address still exists.

During an internal discussion with my team, it was found that the execution was stuck in the same address in the firmware when a different and unrelated problem are being debugged. Is it possible for the running target debug configuration to show the incorrect problem address?

[Julián_AragónM]

Hi @himonkoch,

Most likely yes.

ARM documentation shows that 0xFFFFFFE9 refers to return to thread mode, exception return uses floating-point state from main SP and execution uses main SP after return.

You can refer to the following document: HOW TO DEBUG A FAULT EXCEPTION ON ARM CORTEX M MCU. You can try to locate the Fault Address by stack Backtrace, since in your stack trace you have not returned from the interrupt yet, you are still in the handler.

Best regards,
Julián

[himonkoch]

Hi @Julián_AragónM,

I will be looking into the document you've sent and try.

Meanwhile, while trying to re-create the problem in Debug_FLASH debug session, this issue never occurred and execution of the feature went about uninterrupted. So far the firmware pushed into the MCU was the bin file generated after building the code with Release_FLASH build configuration. To my limited knowledge, this build configuration incorporates compiler level optimizations.

To confirm this theory I ended up building the code again with Debug_FLASH build configuration and pushed the generated bin file into the MCU directly and waited for the problem to occur, which did not happen.

Is there any way we can change the optimization settings in the IDE for the Release_FLASH build config that can help change the outcome?

[Julián_AragónM]

Hi @himonkoch,

You can change optimization levels for your current build configuration by right clicking the selected project and going to "Properties > C/C++ Build > Settings > Standard S32DS C Compiler > Optimization".

Just keep in mind that RTD package is tested and delivered with optimization level -Os, as stated in the release notes for the respective package:

Best regards,
Julián

[himonkoch]

Hello @Julián_AragónM ,

I did just that and now the new bin file does not have the problem. Thanks for the help.

However, I would still like to know why the optimization causes the random interrupt trigger in the first place since later on I would like to reduce the file size of the binary file.

[Julián_AragónM]

Hi @himonkoch,

It is quite hard to find the root cause for the issue without having a SW + HW to re-create it.

Anyhow, NXP guarantees the functionality of the RTD only when the compiler options are configured according to the release notes. The RTD was developed and tested under the specific settings stated in section 2.7.2, as I've shared in my previous reply.

If you choose to use custom compiler flags or optimization levels, you are responsible for verifying the functionality of the drivers under those conditions.

I'm glad the new bin does not have the problem anymore.

Best regards,
Julián