TMS320F280049: FORCESEC set to 1 cased code break at 0x3fbd92.

Hi, 

It is not recommended to secure the zone prior to programming the DCSM OTP region. The default values in the OTP are such that if zone is secured while leaving the DCSM OTP unprogrammed, all the securable RAM/Flash will become inaccessible. If your code is running on any of these memories, it'll be inaccessible which would lead to an ITRAP. That is why the PC moves to the location you indicated. 

You need to program DCSM OTP and assign the RAM/Flash as per your application requirement and then attempt to secure the zone. 

Hope this resolves your query. 

Thanks & Regards

Pramod

Pramod,

I don't think this is root cause.

If the memory be inaccessible which would lead to an ITRAP, that will caused the code run to illegal ISR. 

Actually , the code run to the illegal ISR by step debugging, then if run again , the CPU finally break at 0x3fbd92.

But the  illegal ISR code  like following , why CPU still will break at 0x3fbd92

static void Interrupt_illegalOperationHandler(void)
{
//
// Something has gone wrong. The CPU has tried to execute an illegal
// instruction, generating an illegal instruction trap (ITRAP).
//
ESTOP0;
for(;;)
{
;
}
}

Also, if the device be secured, the instruction fetch has no issue, why the pervious code will get ITRAP instruction?

Pramod,

That still cannot explain  why during step debugging  the CPU could always in illegal ISR , will not break at  0x3fbd92.

static void Interrupt_illegalOperationHandler(void)
{
//
// Something has gone wrong. The CPU has tried to execute an illegal
// instruction, generating an illegal instruction trap (ITRAP).
//
ESTOP0;
for(;;)
{
;
}
}

If the RAM /FLASH are inaccessible, during stepping debugging in  illegal ISR also will caused CPU get ITRAP. and should break at  0x3fbd92..

You can try the below code  which is very simply ,and try step debugging  when PC run to illegal ISR., you could repeat my issue.

void main(void)
{
//
// Initialize device clock and peripherals
//
Device_init();

//
// Initialize GPIO and configure GPIO pins for CANTX/CANRX
//
Device_initGPIO();

//
// Initialize PIE and clear PIE registers. Disables CPU interrupts.
//
Interrupt_initModule();

//
// Initialize the PIE vector table with pointers to the shell Interrupt
// Service Routines (ISR).
//
Interrupt_initVectorTable();

//
// Enable Global Interrupt (INTM) and realtime interrupt (DBGM)
//
EINT;
ERTM;

DCSM_secureZone1();

for(;;)
{
cot++;
}

}

Pramod,

Also GRAMRAMx/GRABSECTx default 11 not belong to other values.

Hi Huihuang,

During step debug, since the debugger is involved, the behavior of exception handling is quite different when compared to what happens during the non step debug (run button on CCS). If you have any meaningful code in your custom illegal ISR, the effect of which wont be visible. Basically debugger prevents the target to jump into exceptions during step debugs. If you do a step debug while keeping CCS in real time debug enable mode, you can see it jumping immediately to the bootROM default ISR. 

However, having said the above, trying to secure the zone while not having programmed the DCSM OTP is an invalid scenario and lead to the securable memories being inaccessible. If you try the same code by keeping the main code in GSRAM (unsecure memory), you will not see an issue. Please modify your linker command to see if this works. ( I am not suggesting you always need to have your main code in GSRAM, but this experiment is to prove that securable memories will become inaccessible in case security settings are invalid.)

Thanks & Regards

Pramod

Please go through the footnote as well below the table which mentions that the Zone1/Zone2 must be unsecure. 

I can probably ask for a clarity in the TRM for this to be explicitly mentioned if necessary.  

Thanks & Regards

Pramod