f2812 device locked.

Serge,

Well, you've certainly got yourself into a situation!

Is the .hex file a complete image such that it contains the passwords?  If so, then my thinking is this will be the easiest file to deal with since it is ASCII, whereas the .out and .bin are binary files.  I assume this is one of the formats the compiler hex2000 tool produces, such as Intel format, or Motorola-S record, etc.  There is a description of these formats in the C2000 ASM Language Tools User's Guide, SPRU513G.  This will help you parse through the file.

Do you recall if in the source code, you had the passwords in their own named section?  That is how TI examples have it.  Hopefully you do, as that will make things a lot easier.  The passwords are at addresses 0x3F7FF8 - 0x3F7FFF.  If the passwords were in their own named section, that section would appear seperately in the .hex file along with its starting address of 0x3F7FF8, and have a length of 8 16-bit words (or 16 bytes, not sure if the .hex file shows byte or word lengths.  You'll need to look).  You can search the .hex file for 0x3F7FF8 (or various ordered forms for this, such as

00 3F 7F F8

3F 00 F8 7F

7F F8 00 3F

F8 7F 3F 00

You can probably figure out the byte endianess that the section addresses appear in the file.  You need to figure it out anyway for the data, as you need to get the passwords into the correct order assuming you are able to locate them.

This could be a pretty long and tedious process.

I have one other thought, but I cannot guarantee it will not lock up another board.  I recall that after flashing a .out file in CCS, the processor is NOT reset.  If the CSM is unlocked (which it will be during/after flash programming), it will not lock until you reset the device.  So, if you had another board, you could flash the .out file into the device using CCS.  Then, view the flash passwords in a memory location.  DO NOT RESET OR POWER CYCLE the device after flashing it until you see what the passwords are.  Otherwise, you're going to lockup that board too.  You would need to do this very carefully.  My suggestion would be to practice/verify the procedure first using a different .out file for which you know the passwords.  That way if it doesn't work (i.e., the CSM is locked after flash programming with CCS) you can recover the second board and know that you should not try it with the .out for which you don't know the passwords.

Good Luck and let us know how it goes.

Regards,

David

Thanks for the detailed info, David. I used to always wonder, how to recover passwords.

Regards,

Gautam

Hi,

Thanks for your quick response.

I've tried recovering the pwd from the .hex file but didn't manage it so i gave up and instead replaced the locked TMS320f2812 chip with a new one and when trying to program the flash module using the SCI-A boot method, the device got again into a locked state !!

This is really weird.

Here is my what i did:

1- loads CKFA (communication kernel and flash API) into unsecured RAM

2- Built the application code using Code composer studio v5.5.0.00077, which produced a .out file

3- Used the hex2000 and FileIOShell programs to generate the .bin file

4- And finally transfered the .bin file to the CKFA code (which upon receiving it erases and loads flash)

Note: the CKFA code runs perfectly well from unsecured RAM

          However whenever i try to reprogram the flash after a first write is performed, the CKFA tells me that flash is                     locked

           And i've already locked six f2812 chips !!! --> so i need a bit of help here if you don't mind.

I think the issue is to with the way the linker command file is setup.

More Info:

• The Application code i tried to load in flash is the "EV Timer Period example" (see link below)

5126.flash.zip

• I used the following two linker command files to build the above project

1803.My_F2812_CmdFile.zip

3173.my_DSP281x_Headers_nonBIOS_cmdFile.zip 

• here is the some of the output files produces (including .hex, .map, .bin files etc.) which can also be found in the "Debug" folder of the supplied project directory (see very first link i.e. flash.zip) 

5635.output_files.zip

Quick view of the linker map file shows:

INPUT FILE NAME: <Example_281xFlash.out>
OUTPUT FORMAT: Motorola-S

PHYSICAL MEMORY PARAMETERS
Default data width : 16
Default memory width : 16
Default output width : 8

OUTPUT TRANSLATION MAP
--------------------------------------------------------------------------------
003d8000..003f7fff Page=0 Memory Width=16 ROM Width=16 "FLASH2812"
--------------------------------------------------------------------------------
OUTPUT FILES: Example_281xFlash.hex [b0..b15]

CONTENTS:   003d8000..003ebfff                     FILL = 0000ffff
                        003ec000..003ec085                  Example_281xFlash.out(ramfuncs) Data Width=2
                        003ec086..003f5fff                      FILL = 0000ffff
                        003f6000..003f636c                    Example_281xFlash.out(.text) Data Width=2
                        003f636d..003f636d                    FILL = 0000ffff
                        003f636e..003f646d                    Example_281xFlash.out(.econst) Data Width=2
                        003f646e..003f6483                    Example_281xFlash.out(.cinit) Data Width=2
                        003f6484..003f7ff5                      FILL = 0000ffff
                        003f7ff6..003f7ff7                        Example_281xFlash.out(codestart) Data Width=2
                        003f7ff8..003f7fff                         FILL = 0000ffff

Note: (you can find the files mentioned below in the project's Debug directory)

To generate a .bin file from the .out file produced, i run the following batch commands:

• hex2000.exe         Example_281xFlash_hex_2812.cmd
• FileIOShell.exe   -i Example_281xFlash.hex -o Example_281xFlash.bin

where Example_281xFlash_hex_2812.cmd  is a command file containing the following commands to fill unused (or remaining) flash sectors with 0xFFFFs :

Example_281xFlash.out

-map Example_281xFlash_hex.map
-o Example_281xFlash.hex
-m
-memwidth 16
-image

ROMS
{
FLASH2812: origin = 0x3d8000, len = 0x20000, romwidth = 16, fill = 0xFFFF
}

I've tried my best to debug this and read thru all relevant manuals and i'll appreciate some help.

Thanks,

serge

Hi,

I think i know what the issue is and it's to do with the .out to .bin file conversion procedure.

The generated .bin file seems to be corrupted for some reason.

Here is what i have done to figure it out:

1- built the code using CCSv5 and got  .out file

2-used these batch commands to generate a .hex file in intel HEX format

hex2000 -i file.out -romwidth 16 -memwidth 16 -map file_hex.map
rename    "file.i00" file.hex

3-then i tried loading the hex file into the flash using a third party tool called c2Prog and it worked, which means that my .out file  is good.

4-Next, i tried to convert the .out file to .bin file (using the batch commands listed below) and tried writting it to flash using the CKFA code previously loaded to unsecured RAM. the write process worked ok but then when trying to re-program flash using the same password, it fails.

a) hex2000.exe    Example_281xFlash_hex_2812.cmd

b) FileIOShell.exe   -i      Example_281xFlash.hex -o Example_281xFlash.bin

with the .cmd file in step a) above containing this:

Example_281xFlash.out

-map Example_281xFlash_hex.map
-o Example_281xFlash.hex
-m
-memwidth 16
-image

ROMS
{
FLASH2812: origin = 0x3d8000, len = 0x20000, romwidth = 16, fill = 0xFFFF
}

any thoughts? ... is it to do with my FileIOShell.exe program?

thanks,

serge