• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 718 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CSM lockout on eZdsp F28335

Jeremy Skippen
Prodigy 50 points

After developing some code in CCS and running it in RAM I was interested in running it from flash.
I managed to compile, link and load the program easily enough, but I started getting wierd behaviour after calling the following routine:

#pragma CODE_SECTION(InitFlash, "ramfuncs")
void InitFlash(void) {

    EALLOW;

    /* Flash set to activate mode */
    FlashRegs.FPWR.bit.PWR = 3;
    /* Clear the 3VSTAT bit */
    FlashRegs.FSTATUS.bit.V3STAT = 1;
   
    /* ONLY THE DEFAULT VALUE FOR THESE 2 REGISTERS SHOULD BE USED */
    FlashRegs.FSTDBYWAIT.bit.STDBYWAIT = 0x01FF;
    FlashRegs.FACTIVEWAIT.bit.ACTIVEWAIT = 0x01FF;

    /* Set the Random Waitstate for the Flash */
    FlashRegs.FBANKWAIT.bit.RANDWAIT = 5;
    /* Set the Paged Waitstate for the Flash */
    FlashRegs.FBANKWAIT.bit.PAGEWAIT = 5;
    /* Set the Waitstate for the OTP */
    FlashRegs.FOTPWAIT.bit.OTPWAIT = 8;

    /* Enable Flash Pipeline mode to improve performance */
    FlashRegs.FOPT.bit.ENPIPE = 1;
  
    EDIS;

    /* Force a pipeline flush */
    asm(" RPT #6 || NOP");
}

After (or during) execution of that function, the PC seemed to jump around into ISRs that were also loaded into RAM, and after a while the PC ended up at an ESTOP0 instruction.

After a few attempts to debug the problem (recompiling and reloading etc.) I find that I'm now being prompted for a CSM password when reading/writing flash, and now I can't even load programs into RAM.
Is there anyway to reset the CSM password?
Surely there's no security comprimise if the flash is erased at the same time as resetting the password?

Is there a way to salvage the chip or should I just bin it now?

Any help is appreciated.

  • 0
    Intellectual 760 points

    If you dont know the password then ur flash has been rendered useless due to lockout. also the CSM secured SARAM cannot be used. which are L1,L2, L3 and L0.

    but for testing purpose you can use L4 to L7 RAM with proper memory allocation for differnet sections.

    so now you are left with 4K X 16 of SARAM X4.

    Always refer your .cmd ( 28335_RAM_lnk.cmd ) file for proper memory allocation and check whether the CSM password locations are not used for your code.

    ((  .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used                    */
       csm_rsvd         : > CSM_RSVD   PAGE = 0, TYPE = DSECT /* not used for SARAM examples */
       csmpasswds       : > CSM_PWL    PAGE = 0, TYPE = DSECT /* not used for SARAM examples */

     

    ))

    see that in your code development phase DSECT is present for these locations.

  • 0 in reply to Pankaj
    Prodigy 50 points

    I used the default linker file supplied with the header files (non-BIOS), which has

       csmpasswds          : > CSM_PWL     PAGE = 0
       csm_rsvd            : > CSM_RSVD    PAGE = 0

    but I think my problem came from a random write to memory when my PC was off in RAM somewhere.
    Does TYPE = DSECT protect these sections from such occurances? I'll add it anyway just to be sure...

  • 0 in reply to Jeremy Skippen
    Intellectual 760 points


    · The DSECT type creates a dummy section with the following characteristics:
    – It is not included in the output section memory allocation. It takes up no memory and is not included
    in the memory map listing.
    – It can overlay other output sections, other DSECTs, and unconfigured memory.
    – Global symbols defined in a dummy section are relocated normally. They appear in the output
    module's symbol table with the same value they would have if the DSECT had actually been
    loaded. These symbols can be referenced by other input sections.
    – Undefined external symbols found in a DSECT cause specified archive libraries to be searched.
    – The section's contents, relocation information, and line number information are not placed in the
    output module.

     

     

    plz refer

    http://focus.ti.com/lit/ug/spru513c/spru513c.pdf

  • 0 in reply to Pankaj
    Prodigy 50 points

    I figured out how the random write happened.
    When I was copying my ISRs to RAM with the code:

    extern Uint16 ramfuncs_loadstart;
    extern Uint16 ramfuncs_loadend;
    extern Uint16 ramfuncs_runstart;

    memcpy( &ramfuncs_runstart, &ramfuncs_loadstart, &ramfuncs_loadend - &ramfuncs_loadstart );

    only half my code was copied from Flash to RAM for some reason. I changed the code to

    extern Uint16 ramfuncs_loadstart;
    extern Uint16 ramfuncs_loadend;
    extern Uint16 ramfuncs_runstart;

    Uint16 *source = &ramfuncs_loadstart;
    Uint16 *dest = &ramfuncs_runstart;

    while (source != &ramfuncs_loadend)
        *dest++ = *source++;

    and I get expected behavior.