TMS320F28377D: can CPU2 DCSM OTP security settings disable access to CPU1 flash memory?

Hi Vivek,

Vivek Singh said:

One thing is not clear is were you able to do it properly if CPU2 USER OTP settings are not programmed ? Also are you able to program the flash sectors and issue is only with USER OTP?

yes, if CPU2 User OTP is NOT programmed, my bootloader works fine and every operation with the device(program/verify/...) works without any trouble. This is valid for flash sectors or OTP memory of both CPUs. Of course, when I program the CPU1 user OTP password locations to some non-blank values, the situation will be the same. The device is from this point unaccessible for me(because of bootROM access...).

Vivek Singh said:

Can you connect the device to CCS and check the CPU2 USER OTP settings to make sure it's programmed as expected and if there is no issue in sharing this info, can you share the values.

I am sure, that the values are programmed successfully as I want - when I use the TI UniFlash flash tool, and put there the programmed password data, the CPU2 flash has been unlocked. In this case I am able to erase/program the CPU2 flash without any troubles in UniFlash tool. I don't know how to see in CCS "Memory Browser" window the CPU2 OTP locations, if the password locations of CPU2 User OTP is programmed to non-blank values. But my program and verification routines, which program the CPU2 User OTP locations, don't return any errors during programming.

The CPU2 User OTP locations have been programmed as follows:

Z1-LINKPOINTER1 - address 0x78000, data 0x1FFF_FFFF

Z1-LINKPOINTER2 - address 0x78004, data 0x1FFF_FFFF

Z1-LINKPOINTER3 - address 0x78008, data 0x1FFF_FFFF

Z1-PSWDLOCK - address 0x78010, some non-blank data(I can't share because of security...)

Z1-GRABRAM - address 0x78024, data 0xFFFF_5FFF

Z1-GRABSECT - address 0x78026, data 0xFFF5_5555

Z1-CSMPSWD0/1/2/3 - address 0x78028 - 0x7802E, some non-blank data(I can't share because of security...)

all other CPU2 User OTP has the 0xFFFF blank values.

Vivek Singh said:

Also when CPU1 bootloader is trying to program the it's flash/USER OTP setting, what CPU2 is doing?

Hmm, I have never taken a care about it. is there any special calls which is needed to call and I don't do it?. This is the start of my "main.c" procedure for CPU1 flash programming:

void main(void)
{
// Step 1. Initialize System Control:
// Enable Peripheral Clocks
// This example function is found in the F2837xD_SysCtrl.c file.
    InitSysCtrl();

//  Unlock CSM
//
//  If the API functions are going to run in unsecured RAM
//  then the CSM must be unlocked in order for the flash
//  API functions to access the flash.
//  If the flash API functions are executed from secure memory
//  then this step is not required.
    //DcsmZ1Unlock();

// Step 2. Initialize GPIO:
// This example function is found in the F2837xD_Gpio.c file and
// illustrates how to set the GPIO to it's default state.
   InitGpio();  // Skipped for this example

// Step 3. Clear all interrupts and initialize PIE vector table:
// Disable CPU interrupts
    DINT;

// Initialize the PIE control registers to their default state.
// The default state is all PIE interrupts disabled and flags
// are cleared.
// This function is found in the F2837xD_PieCtrl.c file.
    InitPieCtrl();

// Disable CPU interrupts and clear all CPU interrupt flags:
    IER = 0x0000;
    IFR = 0x0000;

// Initialize the PIE vector table with pointers to the shell Interrupt
// Service Routines (ISR).
// This will populate the entire table, even if the interrupt
// is not used in this example.  This is useful for debug purposes.
// The shell ISR routines are found in DSP2802x_DefaultIsr.c.
// This function is found in F2837xD_PieVect.c.
    InitPieVectTable();

// Copy time critical code and Flash setup code to RAM
// This includes InitFlash(), Flash API functions and any functions that are
// assigned to ramfuncs section.
// The  RamfuncsLoadStart, RamfuncsLoadEnd, and RamfuncsRunStart
// symbols are created by the linker. Refer to the device .cmd file.

   //memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

// Call Flash Initialization to setup flash waitstates
// This function must reside in RAM

    InitFlash();

  //Gain pump semaphore
    SeizeFlashPump();

//  Jump to RAM and call the Flash API functions
    Example_CallFlashAPI();
}

I have been thinking if my CPU1 code is not loaded and running from the secured RAMs(sets by the CPU2 User OTP setting listed above). Thus, I'm attaching the linker file for CPU1 programming.

linker_file_flash_programming_cpu1_RAM.zip

I really don't understand why the CPU2 user OTP settings cause that my bootloader(loaded and running from the shared GSxRAM) is not functional... Any idea? Do you need any additional information?

Best regards,

Tomas Lehotsky

Hi Vivek,

sorry for the delayed response - i was too busy with this project.

Vivek Singh said:

if CPU2 is booting but not able to run the code because of security then it may fire an NMI to CPU1 which will impact CPU1 execution. So it is important to understand what CPU2 is doing in this case.

You were right. The idea that CPU2 is doing something which can impact CPU1 code execution seems to be correct. I put under the main procedure the command:

	EALLOW;
	DevCfgRegs.CPU2RESCTL.all = 0xA5A50001;
	EDIS;

which hold the CPU2 in reset. This solution works and my CPU1 code is running without any trouble.

Thank you for your help!

Best regards,

Tomas