PIT_isr not be executed

[changchen]

Hi All,

when I debug the PIT module, I enconter a problem: 'void PIT0_isr(void)' can be executed.

In order find the reason ,I read the  PIT_0.TIMER[0].TFLG.B.TIF , and the PIT_0.TIMER[0].TFLG.B.TIF has be set .

Then I add the code :

if(PIT_0.TIMER[0].TFLG.B.TIF)
{
PIT_0.TIMER[0].TFLG.B.TIF=1;
SIUL2.GPDO[32].B.PDO=~SIUL2.GPDO[32].B.PDO;
}

and I used the scope to read the Pin[32],and the result is also right : the timer period is exactly 1ms.

But Why the funciton 'void PIT0_isr(void)' can not be executed?

How can I solve this problem?

Thank you!

[hongpingxu-b364]

Please refer to: https://community.nxp.com/thread/500672

[曾经怀念]

Hi Martin,Shane，

      if core0 use the core1 IACK and RCHW, So which resources that core1 use 

[shanescott]

I have the same issue with MPC5743R.  I can poll the TIF bit for PIT0_0 with no problem but can't get the ISR to work.  

Here is my vector table entry:

    (uint32_t) &pit0_0_isr, /* Vector # 226 Periodic Interrupt Timer (PIT0) PIT_0_TFLG0[TIF] */

I also set priority and core:

     INTC_0.PSR[226].R = 0x8001;

Any ideas?  

Shane

[petervlna]

Hi,

There is really no issue.

Set correctly ISR in vector table. Set priority. Initialize INTC and trigger interrupt.

Device must end up in IVOR4.

As an reference you can use this example for MPC5744P. It is different micro but principle is the same.

https://community.nxp.com/docs/DOC-103438 

Peter

[shanescott]

Hi Peter,

Sorry to waste your time on a non-issue but please be patient because it feels like an issue to me.

I had already tried your suggestions before I first posted so there must be a mistake somewhere in my code:

vector table entry:

(uint32_t) &pit0_0_isr, /* Vector # 226 Periodic Interrupt Timer (PIT0) PIT_0_TFLG0[TIF] */

void pit0_init(void) {
   INTC_0.PSR[226].R = 0x8001; //set priority and core
   PIT_0.MCR.B.MDIS = 0; //enable pit_0
   PIT_0.TIMER[0].LDVAL.R = 66000000-1; //setup pit0_0 for 1sec period
   PIT_0.TIMER[0].TCTRL.B.TIE = 1; //enable interrupt
   PIT_0.TIMER[0].TCTRL.B.TEN = 1; //enable timer
}

void pit0_0_isr(void) {
   PIT_0.TIMER[0].TFLG.B.TIF = 1; // Clear PIT_0 interrupt flag
}

I have set a breakpoint in IVOR4 but it is not ever reached even though TIF is set.

Can you see the problem or point me to some example code specifically for MPC5746R?

Shane

[petervlna]

Hi,

Could you tell me which compiler are you using?

Peter

[shanescott]

S32 Design Studio for Power Architecture

Version: 1.1
Build id: 160608

[martin_kovar]

Hello,

which debug probe you use? Do you use PEMicro and S32 Design Studio debugger or something different?

Regards,

Martin

[shanescott]

PE Micro Cyclone FX.  Standard Debug configuration from S32 Design Studio.

[martin_kovar]

Hi,

you have to set INTC.PSR[226] = 0x4001;

By default, MPC5746R boots from core0 and it's reset vector is placed at 0xF9C014 which is marked as CPU1 in the documentation and also in S32Design Studio (I agree it is confusing). 

In INTC_PSR register you have to set PRC_SELN1 instead of PRC_SELN0 (0x400x). Honestly I do not understand this designation too, but it works this way.

Regards,

Martin

[shanescott]

Martin,

PIT interrupt is now working fine when debugging but not in normal mode.  Any ideas?

Shane 

[martin_kovar]

Hello Shane,

it is strange. If interrupt works in debug mode, it should also work without debugger. I saw one mistake in your code. You should not clear interrupt flag using bit access (in this case it will work correct because there is only one bit in the register).

Instead of PIT_0.TIMER[0].TFLG.B.TIF = 1; // Clear PIT_0 interrupt flag, you should use following code:

PIT_0.TIMER[0].TFLG.R = 1; // Clear PIT_0 interrupt flag

How do you test interrupt without debugger? Do you toggle LED?

Regards,

Martin

[shanescott]

Ok I have more info for you.  

Setting INTC.PSR[226] = 0x4001 works with debugger but not without.  

Setting INTC.PSR[226] = 0x8001 does not work for debugger but does work without.

I read that the MPC5743R boots from core1 but then runs from core0.  Could it be that when debugging it stays in core1 ?      

[martin_kovar]

Hello Shane,

I would like to apologize about information that MPC5743R boots from core0. You are correct it boots from core 1, but core0 does not implicitly run. It must be started by software. If you create single-core project in S32 Design Studio, core0 is not started in the project and it is in reset state whole time.

I created simple example for you, which shows, that PIT interrupt works correct. I did not do any changes in the project (it is default project from S32DS). I tested it with NXP MPC57xx EVB and MPC5743R (1N83M) and it works correct with debugger and also without debugger.

Please check main.c file and intc_SW_mode_isr_vectors_MPC574xR.c file (interrupt vector table). Other files are default. If you have NXP EVB, please connect the LED according the example description and check, that LED is blinking with 1s period.

Regards,

Martin

[shanescott]

Hi Martin,

Your project does perform correctly but I was unable to replicate the result with a default S32 "New S32DS Project" even using the source files from your project.  This made me suspect a difference in the project settings so I compared them and found a difference.  Your project settings contain the symbol TURN_ON_CPU1

The "New S32DS Project" for MPC5743R generates the symbol TURN_ON_CPU_0

Just by changing this symbol manually the PIT interrupt now works with or without debugger for my project.

[shanescott]

I am getting an error building this project:

11:47:32 **** Incremental Build of configuration Debug for project MPC5743R-PIT_Test-S32DS_Z4_0 ****
make -j8 all
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x60E90000, RegionSize 0x460000, State 0x10000
C:\Freescale\S32_Power_v1.1\utils\gnu\bin\make.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

[shanescott]

I am reinstalling S32 and starting over.  Will be next week before I can get back into this project again.  Thanks for the help.

[shanescott]

The isr calls a function that drives a solenoid valve.  Works fine with or without debugger if I disable the interrupt and poll the flag instead. Only works with debugger if I use interrupt.  Could it have to do with my modification of the  intc_sw_handlers.s file since this is automatically generated/included with a new project maybe it is not supposed to be changed? 

[shanescott]

Thanks Martin that was the trick to trigger the interrupt.  The ISR was still not reached though because intc_sw_handlers.s uses INTC_IACKR0 and the actual request is held in INTC_IACKR1.  Confusing to me but consistent with your comment.  All that is required to fix it is changing 2 lines in that file

original (points to INTC_IACKR0):

.equ INTC_IACKR, 0xfc040020 ;# Interrupt Acknowledge Register address
.equ INTC_EOIR, 0xfc040030 ;# End Of Interrupt Register address

change to point at INTC_IACKR1:

.equ INTC_IACKR, 0xfc040024 ;# Interrupt Acknowledge Register address
.equ INTC_EOIR, 0xfc040034 ;# End Of Interrupt Register address

Shane

[changchen]

the microchip is MPC5746R