EVB9S12XF512E RTI not generated

[ramakr02]

Development board:          EVB9S12XF512E 

Target Processor:           MC9S12XF512MLM

Operating system:           N.A.

Debug Protocol:              BDM

Additional Info:            P&E micro USB multilink interface

Following the steps of EVB9S12XF512E User Manual, I have successfully opened and flashed the example project 'EVB9S12XF512E_Node1_LS.mcp' thru the debug mode. I can observe the LED indicator D26 toggling when switch SW2 is pressed. But LED indicators D22, D27, and D29 are NOT sequentially turned on at 1 s interval (as mentioned in the startekite document). On placing a breakpoint inside 'Scheduler_RTI_Isr' in 'Scheduler.c', I observed that the program never reaches the breakpoint which means the real-time interrupt is not generated. This an example program from the CD provided with the Kit with no changes. But the breakpoint in 'External_XIRQ_Isr' is reached while executing the code, this is expected as the toggling of LED D26 is observed with the pressing of SW2.

Hence for some reason RTI is not generated and the respective ISR (which has scheduler code) is not executed. The only difference in the procedure i followed and as written in the manual is that I'm using CW for HC(S)12x, Version 5.1 (which was provided in the Kit CD and updated to CW 5.9.0) whereas the document mentions the code is intended for CodeWarrior Development Studio for HC12X, version 4.6. with CW46_XF512_upgrade_beta0.zip. Why would the real-time interrupt not be generated? Does the CW version difference have any issue? I think there is an issue clock settings in the example code being specific to another core? 

Thank you for your time. RadekS‌, requesting help.

Best regards,

Rohit

[RadekS]

Hi Rohit,

Unfortunately, I don’t have here S12XF boards for testing it.

I cannot see any issue when I look at the code.

The RTI is simple peripheral and shouldn’t cause any issues.

Inside vfnInterrupts_Init() is:

    RTICTL_RTDEC = 1;   /* Real time interrupt decimal divider */                                                                     

    RTICTL_RTR = 0x79;  /* Divider = 2x10^6; RTI period=2M/4MHz = 500 ms */

    CRGFLG_RTIF = 1;    /* Clear real time interrupt flag */   

    CRGINT_RTIE = 1;    /* Enable real time interrupt */ 

In main():

    ENABLE_INTERRUPTS();

In Scheduler_RTI_Isr():

    CRGFLG_RTIF = 1;         /* Clear the real time interrupt flag */

That should be enough for invoke RTI interrupts.

BTW: the Scheduler_RTI_Isr() function is in Interrupts.c file.

Since XIRQ works, are you sure that main code already reached the ENABLE_INTERRUPTS(); line in the main code?

The most typical issue with S12XF EVB is forgotten jumper J27. This jumper must be disconnected during step by step debugging, otherwise the SBC resets MCU periodically.

Please try to remove the breakpoint and set it again. Please ensure that you placed the breakpoint inside the Scheduler_RTI_Isr() and not u8Scheduler() function. The switch code may be sometimes optimized out by compiler (depends on optimization level) and breakpoints placed in C code cannot work correctly.

I hope it helps you

Best regards

Radek

[ramakr02]

Hi Radek,

Thank you for the information.

As you said, on further debugging, i discovered that program is not able to reach ENABLE_INTERRUPTS(); in main.c.

The program halts forever in the following subroutine in FlexRay_handler.c :

void Failed(uint8 u8number)
{
while(u8number); /* Function only for debugging, CC should be restarted */
}

The debugger windows shows the value u8number = 1. This means flexray initialisation is not successful. The code reaches line number 200 of Fr_UNIFIED.c, and returns FR_NOT_SUCCESS. This is because  FlexRay CC is not in FR_POCSTATE_CONFIG and the wait cycles (incrementing i counter) expires waiting for (Fr_CC_reg_ptr[FrPSR0] & 0x0700) == FrPSR0_PROTSTATE_CONFIG).

I am not able to figure why the flexray initialisation is failing. This is the example project of "EVB9S12XF512E_Node1_LS.mcp".

Could you please provide more info on the above issues and check points i need to verify to get to the cause of issue.

Thank you so much for your help.

Best regards,

Rohit

[RadekS]

Hi Rohit,

just idea: Since you didn't mention Node2, I suppose that this board works correctly.

Could you please try to upload Node1 software into Node2 board and opposite Node2 software into Node1 board?

This may help us to test whether the problem is rather in hardware or in software.

If Node1 software will work correctly on Node2 board, we should focus on hardware - interconnection, power supplies, jumper settings,...
If Node1 software will have the same behavior at Node2 board, the problem will be rather in software...

BR

Radek

[ramakr02]

Dear Radek,

Thank you for your reply.

During my initial flashing, I did flash both Node 1 and Node 2 LS flexray code to designated EVBs. I did check the tightness of flexray cables, tried resetting the boards simultaneously, but the LEDs did no blink as per the operation of Flexray LS code.

Next, going with your advice, I interchanged the code and flashed Node 2 project code to EVB1 and vice versa, still the LEDs did not blink as per the code. So it is the same behaviour in both EVBs for the code, which possibly indicates an issue with software. As i mentioned earlier, during the debug the code goes into void failed ISR of FlexRay_handler.c .

As discussed with Diana, I will share the observation with standalone code as follows. 

When step running using multilink(Jumper J27 disconnected), the program routinely goes to RTI ISR and I am able to see LEDs (D22, 23,25,28) switch ON and OFF as per the switch case in scheduler code. Also, I verified the program reaches ENABLE_INTERRUPTS(); naturally since the RTI ISR is reached. So the initialisation of flexray is successful and code proceeds.
The problem is when I run (free run, no stepping) the code without any breakpoint (multilink connected to EVB, true time simulator run), the code never reached the RTI ISR and it remains inside the following ISR in Vectors.c (when i halt the run):

/*******************************************************************************/

/* Dummy interrupt service routine */

#pragma CODE_SEG __NEAR_SEG NON_BANKED

void interrupt Dummy_D_Isr()

{

for (;;)

;

}

/****************************************

Hence, in the free run, no LED indication is observed. Why is the code working while single stepping but jumping into dummy ISR while running freely?

Thank you for your time.

Best regards,

Rohit

[RadekS]

Hi Rohit,

thank you for your investigation.

Based on your observation, this situation is now much more clear.

Obviously, there is enabled and reached one of interrupts which was not implemented by own interrupt routine.

The Dummy_D_Isr() function does not clear any interrupt flag, therefore the code jumps into this routine again and again.

The XIRQ has higher priority, therefore SW2 works correctly.

• Please make a backup of your vectors.c, interrupts.c and interrupts.h files and use attached files. I implemented interrupt catcher code for your reference - unfortunately, not tested.
• Build the code and place a breakpoint into Unimplemented_ISR() dummy function.
• When the code will reach this breakpoint, the number_of_ISR will show the source of an interrupt.
• The name of the interrupt source may be found in MC9S12XF512.H file ("interrupt vector numbers" table) or you may calculate vector address as 0xFFFE-(2*number_of_ISR). Note: just be careful and do no mix hex and decimal numbers.

Note: If the code will not jump into Unimplemented_ISR(), the source of the issue was probably in the original vector table. Any unintentional modification or just commented single line changes the interrupt vectors order.

I hope it helps you.

Best regards

Radek

[ramakr02]

Dear Radek,

Thank you for providing the modified source files.

I replaced the three files in the standalone FS code and compiled and flashed the code to EVB. Following are the observations:

1. The LEDs, apart from D27 and D29, start blinking in orderly manner (see attached video for reference). This is a good observation since earlier no LEDs were blinking. It seems that LEDs D27 and D29 (which do not blink) are related to CAN messages, which I am not particularly interested. The observation in stepping and free run is same.

2. Since our objective was to find which Interrupt was causing the original code to jump to dummy ISR, and as you explained, i placed a breakpoint inside Unimplemented_ISR(void), and while running the breakpoint is reached and the value of the variable number_of_ISR is 6. From the vector table, I see that the source of interrupt is IRQ ( Port E pin E1 Input, Maskable Interrupt). I am not sure why this interrupt happens, since in the schematic of EVB, PE1 is connected to U4 (MC33742). Is there anything to investigate why PE1/IRQ is causing an interrupt?

In the original example code, as i mentioned in earlier post, the code jumped to Dummy ISR because of the forever FOR loop and remained there. By replacing the code comes out of the unimplemented ISR and allows other ISRs to execute.

Thank you again for your help.

Best regards,

Rohit

This video has been deleted

[dianabatrlova · Accepted solution]

Hello Rohit,

I would like to add here the solution which we found after the discussion in a support ticket.

The boards have to switch ON one after the other.

Best regards,

Diana

[dianabatrlova]

Hello Rohit,

Unfortunately, I have to refute the SW issue, because it works on both boards which I have, see the attached videos.

One of them shows the StandAlone_FS project and another one Node1_LS and Node2_LS project. 

I think another chance could be to test it on the CW 5.1 and, for example, Win 7 

Best regards,

Diana

[ramakr02]

Yes, I completely agree that the code works and there seems to be different issue to be investigated.

BR,

Rohit

[RadekS]

Hi Rohit,

I fact, I am not sure what is the reason for it now.

Please ensure that both boards are connected properly together with FlexRay cables, both boards are powered and one board has uploaded EVB9S12XF512E_Node1_LS.mcp while the second board uses EVB9S12XF512E_Node2_LS.mcp.

Please try to reset both boards simultaneously.

Best regards

Radek