I am attempting to port an app from boot-from-RAM to boot-from-flash using CCSv4 on an F2812 board I designed usingthe ezDsp as a template. I got one of these to work lastweek, but involved my own code only. This integrates codefrom my fellow programmer which has many more user-definedsections than my prior attempt.
It took forever to overcome all the build errors, but when Ifinally tried to launch the debugger it terminated in anerror message (I retrieved this after the fact from theerror 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 L0or L1 SARAM it dies with "Data verification failed ataddress ...". The addresses I checked on were in L1SARAM.
I can still load and run apps that place all code & data inthe H0SARAM, and followed another posting on this forumindicating I could look at the addresses in 0x3F7FF8-0x3F7FFF in the data space using the Memory window. They allread back as 0000.
Refreshing the display of those words and running a scriptfrom Scripts >> Code Security Module >> Unlock_CSM have noeffect.
1. Have I exhausted all opportunities for salvaging my DSP board?
Worst still, if the passwords have unknown values in them, Ihave no idea how they got there, nor how to keep from doingit again. At $570 a board (and we only have 2 left) I canill 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 ofanything else to volunteer (That was not its original name).
Advance thanks for any money you can save my employer.
============================================================Gary Lynch printf("lynchg%cstacoenergy%ccom", 55+9, 55-9)============================================================
I have received as yet no responses to this query, but havecontinued to research and am adding my discoveries forfuture 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.
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.
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) haveemphasized this point, which I was aware of before Iattempted 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 apoint I noticed from a slide show in the C2000 wiki entitled"TMS320F281x Flash Programming Solutions," SPRB169, andwhich 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) youprogram your device, it must first be erased, and one of theintermediate steps is to change all bits of each sector toall 0's (precisely what you must NEVER do to the PWLs).Several TI documents warn non-descriptly of the danger ofpulling the plug or resetting your MCU during the erasecycle, and I had no intention of doing so. It self-aborted.
But I think I answered my own question when copying theproject to a new workspace. I originally created thisproject using the CCS new project wizard, and then copiedall the files into it from two other projects containing thecode I wanted to merge. I was careful to copy a pre-existingtarget configuration file from only one of the sourceprojects, but apparently not careful enough.
During the new copy I discovered there was another targetconfiguration file in the project folder likely created bythe wizard, which was marked as 'active', overriding my own.ccxml file and which may have had all defaults for theconfiguration values. I deleted it, making my own file theactive one and now I can load my app into flash without MCUdestruction.
Thanks, Will (you get the prize), and to all who contributed off-line.
Gary Lynch I can still load and run apps that place all code & data inthe H0SARAM, and followed another posting on this forumindicating I could look at the addresses in 0x3F7FF8-0x3F7FFF in the data space using the Memory window. They allread back as 0000. Refreshing the display of those words and running a scriptfrom Scripts >> Code Security Module >> Unlock_CSM have noeffect. 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 = 0Gary Lynch1. 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 Lynch2. 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 Lynch1. 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.
Gary Lynch2. 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.
Gary Lynch 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.