CCS locked CSM on F2812

Gary Lynch

I am attempting to port an app from boot-from-RAM to boot-
from-flash using CCSv4 on an F2812 board I designed using
the ezDsp as a template. I got one of these to work last
week, but involved my own code only. This integrates code
from my fellow programmer which has many more user-defined
sections than my prior attempt.

It took forever to overcome all the build errors, but when I
finally tried to launch the debugger it terminated in an
error message (I retrieved this after the fact from the
error log):
]
] eclipse.buildId=4.2.4.00033
] java.version=1.5.0_14
] java.vendor=Sun Microsystems Inc.
] BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
] Command-line arguments: -data C:\CodeComposer2 -os win32 -ws win32 -arch x86
]
] Error
] Wed May 02 11:41:33 EDT 2012
] Error: C28xx: Flash Programmer: Error erasing Flash memory.
]

I clicked a button that allowed it to halt and tried again.
The second attempt ended in:
]
] eclipse.buildId=4.2.4.00033
] java.version=1.5.0_14
] java.vendor=Sun Microsystems Inc.
] BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
] Command-line arguments: -data C:\CodeComposer2 -os win32 -ws win32 -arch x86
]
] Error
] Wed May 02 11:41:33 EDT 2012
] Error: C28xx: Flash Programmer: Error erasing flash memory.
] Device is locked or not connected. Operation cancelled
]
Now any time I attempt to load an app that uses flash, or L0
or L1 SARAM it dies with "Data verification failed at
address ...". The addresses I checked on were in L1SARAM.

I can still load and run apps that place all code & data in
the H0SARAM, and followed another posting on this forum
indicating I could look at the addresses in 0x3F7FF8-
0x3F7FFF in the data space using the Memory window. They all
read back as 0000.

Refreshing the display of those words and running a script
from Scripts >> Code Security Module >> Unlock_CSM have no
effect.

1. Have I exhausted all opportunities for salvaging my DSP
board?

Worst still, if the passwords have unknown values in them, I
have no idea how they got there, nor how to keep from doing
it again. At $570 a board (and we only have 2 left) I can
ill afford this category of education.

I have uploaded the linker command file here:
- http://my.execpc.com/~bookworm/Profession/LockCsm_cmd.html

should anyone care to take a look at it. I can't think of
anything else to volunteer (That was not its original name).

Advance thanks for any money you can save my employer.

over 14 years ago

0 Gary Lynch over 14 years ago

Expert 1310 points

I have received as yet no responses to this query, but have
continued to research and am adding my discoveries for
future readers.

1. Other than the first time, every time you program the
    flash of your F2812, CCS erases the whole flash memory.
    The erase algorithm includes writing zeros to every
    memory location (including the CSM passwords), which is
    exactly what TI says YOU MUST NEVER DO, if you don't
    want to render the DSP unusable.

2. If Code Composer decides to dive into its naval
    immediately after zeroing out your passwords, you are
    through using this chip. I suspect that is what
    happened to me.

3. Up until today, every flash programming example I had
    ever found for the F2812 assumed you were using CCSv3 or
    earlier, and was not very applicable to someone who has
    only used v4. But this morning I noticed that document
    SPRA958K:
    - http://www.ti.com/lit/an/spra958k/spra958k.pdf

    references (on page 1) a fileset inside spra958.zip
    which includes flash programming examples that are
    supposed to run under v4.

4. The aforementioned file set lacks a function:
Uint16 CsmUnlock()

    that was present on all the other flash programming
    examples I had used, but which gave me build-time
    difficulties until I eliminated it from my source. This
    also could have caused me more difficulties.

F.Y.I.

0 William Colley97918 over 14 years ago in reply to Gary Lynch

Prodigy 90 points

If you all 128 PWL bits, the device is frozen forever in its current state. It won't erase. It won't debug. If you've done that to a part inadvertantly, you'll have to replace the part.

The fact that CsmUnlock() is cauing you build errors is a bad sign. You probably are not defining the CSM password section in your load image. You need to do that. The Piccolo file DSP2803xCSMPasswords.asm should work fine for your processor as well. Add it to your project.

That file fills sections csm_rsvd and csmpasswds, so define those sections in your linker command file. Define memory regions to load the sections into. csm_rsvd needs to load into a memory region with org=0x3f7f80 and len=0x000076. csmpasswds needs to load into a memory region with org=0x3f7ff8 and len=0x000008. Both memory regions go on page 0, i,e. in flash.

This will insure that your load image doesn't load zeroes into the eight PWL words and lock up your part.

I took a look through a Piccolo example that uses CsmUnlock(). It accesses the PWL locations through a data structure on page 1 call CsmPwl. It learns about that data structure via a header file included by master header file DSP2803x_Device.h. The data structure is defined in file DSP2803x_GlobalVariableDefs.c. You do have that either with your project sources or linked to the project, right? Those many data structures are allocated to page 1 via the linker command file DSP2803x_Headers_nonBIOS.cmd. You have that in the root directory of your project, right? I'm sure there are equivalents for the 2812.

You can have two linker command files in a project as long as they don't allocate the same spaces. All of my projects have DSP2803x_Headers_nonBIOS.cmd right alongside my own linker command file that allocates the RAM and flash spaces.

That's what I've got with the information you gave me.

0 Gary Lynch over 14 years ago in reply to William Colley97918

Expert 1310 points

On Friday, May 04, 2012 3:52 PM; William Colley97918 wrote:
>
> That file (DSP28...CSMPasswords.asm) fills sections csm_rsvd
> and csmpasswds, so define those sections in your linker
> command file. Define memory regions to load the sections
> into. csm_rsvd needs to load into a memory region with
> org=0x3f7f80 and len=0x000076. csmpasswds needs to load into
> a memory region with org=0x3f7ff8 and len=0x000008. Both
> memory regions go on page 0, i,e. in flash.
>
> This will insure that your load image doesn't load zeroes
> into the eight PWL words and lock up your part.
>
Several people (including Bruce Nielsen: off-line) have
emphasized this point, which I was aware of before I
attempted this port, and I thought I took that into account,
as TI provided source for all those operations.

I tried to stress that in my original post, as well as a
point I noticed from a slide show in the C2000 wiki entitled
"TMS320F281x Flash Programming Solutions," SPRB169, and
which is available as a pdf at:
- http://www.ti.com/lit/ml/sprb169/sprb169.pdf

According to slide 7, every time (other than the first) you
program your device, it must first be erased, and one of the
intermediate steps is to change all bits of each sector to
all 0's (precisely what you must NEVER do to the PWLs).
Several TI documents warn non-descriptly of the danger of
pulling the plug or resetting your MCU during the erase
cycle, and I had no intention of doing so. It self-aborted.

But I think I answered my own question when copying the
project to a new workspace. I originally created this
project using the CCS new project wizard, and then copied
all the files into it from two other projects containing the
code I wanted to merge. I was careful to copy a pre-existing
target configuration file from only one of the source
projects, but apparently not careful enough.

During the new copy I discovered there was another target
configuration file in the project folder likely created by
the wizard, which was marked as 'active', overriding my own
.ccxml file and which may have had all defaults for the
configuration values. I deleted it, making my own file the
active one and now I can load my app into flash without MCU
destruction.

Thanks, Will (you get the prize), and to all who
contributed off-line.

0 Lori Heustess over 14 years ago

TI__Guru* 93800 points

Gary Lynch said:

I can still load and run apps that place all code & data in
the H0SARAM, and followed another posting on this forum
indicating I could look at the addresses in 0x3F7FF8-
0x3F7FFF in the data space using the Memory window. They all
read back as 0000.

Refreshing the display of those words and running a script
from Scripts >> Code Security Module >> Unlock_CSM have no
effect.

1. Have I exhausted all opportunities for salvaging my DSP
board?

Unfortunately it does sound like your device is locked. One thing to try is please check is the VDD3VFL voltage. Please make sure it is connected well and powered to 3.3. This pin powers the flash and if it is not healthy the CSM will appear to be locked.

I took a look at the linker command file and the only thing I see assigned to the password location is the "passwords" section. If this is filled with all 0xffff then the code should be fine.

/* + + + + + + + + + + + + + + + + + + + */
/*** Code Security Password Locations  ***/
/* + + + + + + + + + + + + + + + + + + + */
   passwords              : > PASSWORDS,        PAGE = 0

Gary Lynch said:
1.  Other than the first time, every time you program the
    flash of your F2812, CCS erases the whole flash memory.
    The erase algorithm includes writing zeros to every
    memory location (including the CSM passwords), which is
    exactly what TI says YOU MUST NEVER DO, if you don't
    want to render the DSP unusable.


Yes this is correct.  Unfortunatly part of the erase process is to program all bits to 0.  This is a requirement of the technology.  If you can spare sector A, and keep your entry point to your code fixed,  you can mark it to not be erased in the plug-in settings in CCS.  This may help during development when the device is erased often.  

Gary Lynch said:
2.  If Code Composer decides to dive into its naval
    immediately after zeroing out your passwords, you are
    through using this chip.  I suspect that is what
    happened to me.


There is an amount of time where the password is 0 and then it becomes unknown - individual bits will become 1's at different rates.  It is a dynamic process where charge is being removed slowly until the bits reach a solid 1.  If this process is interrupted then the password could be 0 or it could be unknown.  Due to security this will lock the device unfortunately.

Gary Lynch said:
3. Up until today, every flash programming example I had
    ever found for the F2812 assumed you were using CCSv3 or
    earlier, and was not very applicable to someone who has
    only used v4. But this morning I noticed that document
    SPRA958K:
    - http://www.ti.com/lit/an/spra958k/spra958k.pdf

    references (on page 1) a fileset inside spra958.zip
    which includes flash programming examples that are
    supposed to run under v4.

4. The aforementioned file set lacks a function:
      Uint16 CsmUnlock()

    that was present on all the other flash programming
    examples I had used, but which gave me build-time
    difficulties until I eliminated it from my source. This
    also could have caused me more difficulties.

I'll make note of this in our bug tracking database and revisit. The 281x is a bit old so the collateral is in need of an update. I regret you were not able to find an example easily for this device.

-Lori

C2000™︎ microcontrollers

C2000 microcontrollers forum

CCS locked CSM on F2812