CCS/TMS320F280049: DCSM programed and set for FLASH BOOT but the processor will not startup

For reference I was able to figure out that the processor seems to be stuck in the boot rom:

On connect: 0x3FC7A5

If I run after connect: 0x3FBD46

Not sure if that helps...

Thanks,

Hi Kyle,

When you program the password for a zone, you also need to program the GRABSECT field to allocate to flash sector to that zone or make it unsecure. If you leave the value to default ('b11) then flash sectors will be in-accessible if zone is locked. Please refer "Table 3-103. B0_Z1_GRABSECTR Register Field Descriptions" which describe the definition of GRABSECT fields.

When you are connected to debugger, it look like zone is getting unlocked (Z1_CR values is 0x60 which means UNSECURE is '1') hence it works fine.

Regards,

Vivek Singh

Kyle,

Let's say I set the all the flash and all the RAM to Z1.  Do I need to do a secure copy (versus MEMCOPY) to load applications into RAM?  Or is that only when going between zones (or this really seems impossible)? 

Secure copy is only needed if using EXEONLY feature. In this case you can simply do MEMCOPY but you need to make sure that MEMCOPY function is placed in secure flash which will be the case if you are making all flash sector secure.

Or does the unlock process need to be run before I can do that? 

Does the unlock process need to be done at all?

You don't have to run unlock process and we do not recommend to have that in your application.

Regards,

Vivek Singh

Vivek,

So I've moved the memory to zone 1 and it still will not startup into flash.  I made my code's first line to turn on an LED and that doesn't even work, so it's a not memcopy error or something along those lines.

The DCSM registers appear correct... Z1 requests all memory, Zone 2 says no request (I did try it without the no-request from Z2... it also didn't start)

The PSWDLOCK fields may have been corrupted with all of this.  And that might be it, but I think it's probably something else...

Thanks,

Kyle

Kyle,

The PSWDLOCK fields may have been corrupted with all of this.  And that might be it, but I think it's probably something else...

PASWDLOCK fields should not cause any issue because that only impacts the visibility of password locations.

Why don't you debug it with debugger connected and ECSL unlock (standalone emulation boot). Follow below step (assuming code is already loaded) -

• Connect to CCS.
• Reset the CPU
• Unlock the ECSL by writing only Z1_CSMKEY0 and Z1_CSMKEY1 register with matching key.
• Set the emulation boot to standalone emulation boot by writing 0xA500_0000 at address 0xD00 (32bit value)
• Set the hardware breakpoint at main() entry point in your code.
• Click on "Run"

If your bootmode pins are set properly then code execution should halt at main(). If not then check the bootmode pin setting. If it does halt at main() then step through further to see where is the issue. You'll not be able to see the code but since ECSL is disable, you'll be step through it.

Regards,

Vivek Singh

So I think I followed your steps, but after doing all of that it still halts at 0x3FD46 (somewhere in TI_Boot)...

Or maybe I'm not sure I'm doing the debugging/ loading memory process correctly

Kyle,

You should be able to load the BOOTROM symbol from C2000Ware (<C2000Ware>\libraries\boot_rom\f28004x\revB\rom_sources\ccs_files\cpu\Release) and check where in BOOTROM code it is getting stuck.

Regards,

Vivek Singh

OK...  So I was able to track it to what looks like to to be the problem.  Not sure how to solve it...

It appears my OTP looks to be set correctly.  Boot mode is coming back as 3 and it moves to flash boot, but it halts before code is run.

The Boot mode seems to be halting on "Flash Uncorrectable Error" in this statement:

if(cbrom_nmi_status & NMI_FLG_FLUNCERR) /*check for C28FLUNCERR NMI */
        {
            cbrom_status |= BOOTROM_GOT_A_FLASH_UNCERR_NMI;

            //if debugger connected - give a chance to user to know the scenario
            asm("   ESTOP0");

            //let NMIWD reset the device
            while(1);

//            cbrom_nmi_status &= ~(0x08);    /*clear bit 3*/
//            EALLOW;
//            NmiIntruptRegs.NMIFLGCLR.bit.C28FLUNCERR = 1;
//            EDIS;
        }

Any idea what might cause this or how to fix it?

How are you programming the security settings in OTP? Can you check the value of "UNC_ERR_ADDR_LOW" and "UNC_ERR_ADDR_HIGH" register in CCS register view let us know.

Regards,

Vivek Singh

It's the address 0x78010...  Looks like CSM password was written incorrectly...  I'm guessing this particular processor has been bricked.

I was writing the CSM password with the debugger (ECC autogeneration is enabled), but I may have tried to flip the bits twice (one bye once, and then the other byte later).   This may have screwed up the ECC...  

I'll try what I have (completed DSCM) with a new processor and let you know.

Thanks for the help.

Thanks Kyle. That's PSWDLOCK location. Have you programmed that? In general if you have programmed the location once and try to change it again, API should not allow that so I am still not sure how you got this issue. Have you checked the voltage on the board and that is proper?

Kyle, do you have any further debug info on this issue ?

Regards,

Vivek Singh

Vivek,

I haven't had time to work on this section of the project.  So, I can't give you an update at this time...  probably sometime next week I will get time to look into this again.

Thanks,

Kyle