CCS/TMS320F28069: Question about CPU reset(watch dog software reset)

How frequently does this (illegal_ISR) happen? Say, if you were to try this a 100 times, how many times would you see it? Section 3.6 of SPRU430F says the following.

3.6 Illegal-Instruction Trap

Any one of the following events causes an illegal-instruction trap:

• An invalid instruction is decoded (this includes invalid addressing modes).
• The opcode value 000016 is decoded. This opcode corresponds to the ITRAP0 instruction.
• The opcode value FFFF16 is decoded. This opcode corresponds to the ITRAP1 instruction.
• A 32-bit operation attempts to use the [@SP] register addressing mode.
• Address mode setting AMODE=1 and PAGE0=1

An illegal-instruction trap cannot be blocked, not even during emulation. Once initiated, an illegalinstruction

trap operates the same as a TRAP #19 instruction. The handling of an interrupt initiated by the

TRAP instruction is described in Section 3.5.2. As part of its operation, the illegal-instruction trap saves

the return address on the stack. Thus, you can detect the offending address by examining this saved

value. For more information about the TRAP instruction, see Chapter 6, C28x Assembly Language

Instructions.

Is it possible one bullet applies to your situation? is it possible to examine the stack to identify at which point, this interrupt was taken?

Thanks for your reply.

I think illegal_isr enterred 5 times for a 1000 trying.

I check the stack, sometimes it looks like the following, 0x6A is the SP pointer.

0x213100FF should be the return address saved on stack, which is confusing.

Sometimes it runs the either way, SP is also 0x6A. The problem

is that illegal_isr is serviced in bootloader, however the return address

on stack belongs to application code.

Yunhua,
Something that shows up once in 200 attempts can be challenging to debug. Is it possible that some external noise is corrupting the program counter or other bits in the CPU registers?

Yunhua,
in addition to what Hareesh asked, You clearly mention that Illegal ISR is happening in the boot loader. So after watchDOG reset the boot loader is getting started correctly and occasionally it is failing to start the application.

When the failure happens :-
> are you sure the application is programmed correctly in the previous step?
> does your boot loader illegal ISR trigger another watchDOG reset and try to start the application again and does it work?
> how does the device recover from this state, you do a power on reset and the application runs or do you have to re-flash the board?

try to make sure that the application is programmed by the boot loader correctly when the error happens. If you are sure the application is programmed correctly and the boot loader is still seeing the illegal ISR randomly and occasionally, you will have to now narrow down the scenario to
> is the iTRAP (=Illegal ISR) happening when bootloader is executing after watchDOG reset
OR
>is the ITRAP happening when application is running.

This will give you some idea on if there is a RAM corruption, it is possible that either bootloader/application is thinking that there is a function in RAM and branches to RAM location but that RAM is over-written by the previous instance of code. So pay attention to the functions that are loaded to RAM from flash for execution and see if there is any corruption by comparing memory between successful and unsuccessful runs.

You can also compare memoy dumps between two unsuccessful runs and see if the failure itself is random or if there is any similarities between fails.

Hope this helps.

Best Regards
Santosh

Thanks for your reply.
I will look into it.

Best Regards!
Yunhua

I think I solve the problem.
Before software reset, System_DeInit is executed. I comment out the following code, there is no more illegal_isr. And I don't know why?
EALLOW;
PieCtrlRegs.PIEIER2.bit.INTx1 = 0;
PieCtrlRegs.PIEIER2.bit.INTx2 = 0;
PieCtrlRegs.PIEIER2.bit.INTx7 = 0;
EDIS;

EALLOW;
PieCtrlRegs.PIEIER10.bit.INTx1 = 0;
PieCtrlRegs.PIEIER10.bit.INTx2 = 0;
EDIS;

EALLOW;

PieCtrlRegs.PIECTRL.bit.ENPIE = 0;

PieCtrlRegs.PIEIER1.all = 0x0;
PieCtrlRegs.PIEIER2.all = 0x0;
PieCtrlRegs.PIEIER3.all = 0x0;
PieCtrlRegs.PIEIER4.all = 0x0;
PieCtrlRegs.PIEIER5.all = 0x0;
PieCtrlRegs.PIEIER6.all = 0x0;
PieCtrlRegs.PIEIER7.all = 0x0;
PieCtrlRegs.PIEIER8.all = 0x0;
PieCtrlRegs.PIEIER9.all = 0x0;
PieCtrlRegs.PIEIER10.all = 0x0;
PieCtrlRegs.PIEIER11.all = 0x0;
PieCtrlRegs.PIEIER12.all = 0x0;

PieCtrlRegs.PIEIFR1.all = 0xFFFF;
PieCtrlRegs.PIEIFR2.all = 0xFFFF;
PieCtrlRegs.PIEIFR3.all = 0xFFFF;
PieCtrlRegs.PIEIFR4.all = 0xFFFF;
PieCtrlRegs.PIEIFR5.all = 0xFFFF;
PieCtrlRegs.PIEIFR6.all = 0xFFFF;
PieCtrlRegs.PIEIFR7.all = 0xFFFF;
PieCtrlRegs.PIEIFR8.all = 0xFFFF;
PieCtrlRegs.PIEIFR9.all = 0xFFFF;
PieCtrlRegs.PIEIFR10.all = 0xFFFF;
PieCtrlRegs.PIEIFR11.all = 0xFFFF;
PieCtrlRegs.PIEIFR12.all = 0xFFFF;

SysCtrlRegs.PCLKCR1.bit.EPWM1ENCLK = 0; // ePWM1
SysCtrlRegs.PCLKCR1.bit.EPWM2ENCLK = 0; // ePWM2
SysCtrlRegs.PCLKCR1.bit.EPWM3ENCLK = 0; // ePWM3
SysCtrlRegs.PCLKCR1.bit.EPWM4ENCLK = 0; // ePWM4
SysCtrlRegs.PCLKCR1.bit.EPWM5ENCLK = 0; // ePWM5
SysCtrlRegs.PCLKCR1.bit.EPWM6ENCLK = 0; // ePWM6
SysCtrlRegs.PCLKCR1.bit.EPWM7ENCLK = 0; // ePWM7
SysCtrlRegs.PCLKCR1.bit.EPWM8ENCLK = 0; // ePWM8

SysCtrlRegs.PCLKCR0.bit.HRPWMENCLK = 0; // HRPWM
SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 0; // Enable TBCLK within the ePWM

SysCtrlRegs.PCLKCR1.bit.EQEP1ENCLK = 0; // eQEP1
SysCtrlRegs.PCLKCR1.bit.EQEP2ENCLK = 0; // eQEP2

SysCtrlRegs.PCLKCR1.bit.ECAP1ENCLK = 0; // eCAP1
SysCtrlRegs.PCLKCR1.bit.ECAP2ENCLK = 0; // eCAP2
SysCtrlRegs.PCLKCR1.bit.ECAP3ENCLK = 0; // eCAP3

SysCtrlRegs.PCLKCR2.bit.HRCAP1ENCLK = 0; // HRCAP1
SysCtrlRegs.PCLKCR2.bit.HRCAP2ENCLK = 0; // HRCAP2
SysCtrlRegs.PCLKCR2.bit.HRCAP3ENCLK = 0; // HRCAP3
SysCtrlRegs.PCLKCR2.bit.HRCAP4ENCLK = 0; // HRCAP4

SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 0; // ADC
SysCtrlRegs.PCLKCR3.bit.COMP1ENCLK = 0; // COMP1
SysCtrlRegs.PCLKCR3.bit.COMP2ENCLK = 0; // COMP2
SysCtrlRegs.PCLKCR3.bit.COMP3ENCLK = 0; // COMP3

SysCtrlRegs.PCLKCR3.bit.CPUTIMER0ENCLK = 0; // CPU Timer 0
SysCtrlRegs.PCLKCR3.bit.CPUTIMER1ENCLK = 0; // CPU Timer 1
SysCtrlRegs.PCLKCR3.bit.CPUTIMER2ENCLK = 0; // CPU Timer 2

SysCtrlRegs.PCLKCR3.bit.DMAENCLK = 0; // DMA

SysCtrlRegs.PCLKCR3.bit.CLA1ENCLK = 0; // CLA1

SysCtrlRegs.PCLKCR3.bit.USB0ENCLK = 0; // USB0

SysCtrlRegs.PCLKCR0.bit.I2CAENCLK = 0; // I2C-A
SysCtrlRegs.PCLKCR0.bit.SCIAENCLK = 0; // SPI-A
SysCtrlRegs.PCLKCR0.bit.SCIBENCLK = 0; // SPI-A
SysCtrlRegs.PCLKCR0.bit.SPIAENCLK = 0; // SPI-A
SysCtrlRegs.PCLKCR0.bit.SPIBENCLK = 0; // SPI-B
SysCtrlRegs.PCLKCR0.bit.MCBSPAENCLK = 0; // McBSP-A
SysCtrlRegs.PCLKCR0.bit.ECANAENCLK=0; // eCAN-A

EDIS;

Yunhua,
that is good progress, my suggestion would be to dig a bit more into this and see which line of code in above is code is causing the problem to go away. I suppose it must be PIE interrupts and you are most likely having a PIE interrupt and the interrupt handlers are not properly set yet because the SW is switching in between between boot loader and new application. Finding exactly the problem piece will help the robustness of the SW going further.

Best Regards
Santosh Athuru