PIT interrupt before configuration in main()

[mikel1]

Hi,

I’m developing a program for an MPC5744P using Simulink + Embedded Coder + Model Based Design Toolbox. I compile it with the S32DS compiler. I’ve been working in the model for a while now, and it has been working well so far.

However, I’ve had some problems in the last few days. I added some extra operations to an array, just one concatenation and a bitwise XOR of the elements of the array, nothing too complicated. It compiled well but when I tried to test it in HW, it seemed like nothing was being executed, or at least I wasn’t receiving anything through the CAN communications. I have been debugging using S32DS and iSystem’s BlueBox debugger, and I found the problem.

Usually, the program runs the initialization disassembly code and jumps to main(). In main(), it does an initialization first, and then configures the PIT Channel 0 interrupt, which is used to run the periodic task.

However, this behaviour changes with the last compilation. In the initialization disassembly code, in startup_MPC5744P.S, there is a line which seems to enable the interrupts:

    wrteei 1    ;# Enable interrupts

As soon as this line is executed, the MCU launches the PIT Channel 0 interrupt Handle. This happens before the main() function is executed. Because of this, the periodic task is executed before the initialization, so it reaches a point where some variable is used before it is initialized and the program crashes.

The code that configures this interrupt is executed from main(), so I don’t know why it launches as soon as the interrupts are enabled in startup_MPC5744P.S. It is as if the interrupt remained configured from the previous execution. However, this never happened with previous compilations. As I said, the changes in the code don’t justify this change in the behaviour of the interrupts, nor in the Simulink model, nor in the C code.

Any tips on how to solve/debug this problem? I include the startup_MPC5744P.S file and the file containing the main().

[petervlna]

Hello Mike,

Hmm, it looks like you have pending IVOR4 exception (external interrupt) in your system. As soon as you enable external interrupts it is executed.

Yes, this could be remnant of previous execution of code. It depends on kind of reset you are doing.

Pleas check whether there is set PIT TIF flag in PIT periphery prior to execution or wrteei 1.

I expect you are doing short functional interrupt in previous SW iteration.

An enabled 'functional' reset will normally trigger a reset sequence starting from the beginning of PHASE1. Nevertheless, the RGM_FESS register enables the further configuring of the reset sequence triggered by a 'functional' reset. When RGM_FESS.SS_<functional reset> is set, the associated 'functional' reset will trigger a reset sequence starting directly from the beginning of PHASE3, skipping PHASE1 and PHASE2. This can be useful especially in case a 'functional' reset should not reset the flash module.

Once you see TIF set, it means the termination of your previous execution or SW init setup before application in you current run is not done correctly.

Best regards,

Peter