0

I'm trying to place specific data at a specific address in my DSP's flash memory. What I've tried so far works well until I try to generate a raw binary file that we provide to customers for firmware upgrades, the data is stripped from the binary file and replaced with 0xFF's.

What I'm doing right now is using a defined memory section that I entered into the TCF file named FLASH_ID starting at 0x3D8000 (the first address in processor flash) that is 32 words long and is in data space. In the linker command file I create a section called TO_FLASH_ID and direct it to FLASH_ID specifying page = 1 (data space). I then use a #pragma data_section directive to direct a const char[32] to that section.

Relevant section of linker command file:

SECTIONS
{
    TO_FLASH_ID : > FLASH_ID, PAGE = 1
}

Relevant C Code:

#pragma DATA_SECTION(FLASH_ID, "TO_FLASH_ID")
const char FLASH_ID[32] = {'0','0','.','0','0','.','0','0','.','0','6',0,'P','R','O','J','-','N','A','M','E',0,0,0,0,0,0,0,0,0,0,0};

This all works great, after flashing the DSP I look at address 0x3D8000 and the data is there... but when I use TI's tools (hex2000.exe and FileIOShell.exe) to generate a raw image of the firmware that data is replaced with 0xFF's... Here is the command file I'm using for the Hex2000 utility:

proj.out
-o proj.hex
-m
-memwidth 16
-romwidth 16
-image
ROMS
{
    FLASH2812:  origin = 0x003d8000, length = 0x00020000, romwidth = 16, fill = 0xffff
}

What gives? I figure it has to be something to do with the conversion process from TI's .out file to a raw binary image of the memory space... I've considered generating this myself by having code that runs a pointer through the entire address space while uploading the data to our PC software... but I'd rather not as that will disrupt all kinds of automatic build tools I've developed.

Thank you for any help!

CHollman82
  • 576
  • 1
  • 8
  • 28
  • The command `FLASH2812: origin = 0x003d8000, length = 0x00020000, romwidth = 16, fill = 0xffff` seems to do exactly what you are facing.... – LPs Dec 13 '19 at 16:10
  • I thought the fill directive was to specify what to write to memory addresses that are not used... instead it's writing 0xFF's to memory addresses that should contain data... When I remove the fill directive those 64 bytes are filled with 0's instead of FF's, which isn't any better. – CHollman82 Dec 13 '19 at 16:15

1 Answers1

0

If anyone finds this years from now I solved this problem by changing the memory section to be in code space rather than data space in both the TCF file and the linker command file. I still used the DATA_SECTION pragma (not the CODE_SECTION pragma) to direct the constant string to that section.

I learned 2 things here: Anything specified as data space is omitted from the firmware image binary file (at least using the method that I used to generate it) and you can use the DATA_SECTION pragma to put data into memory defined as code space.

CHollman82
  • 576
  • 1
  • 8
  • 28