LDR file

Anyone?

120 viewers and no one can answer the question?!

Do you mean that you want to change a LDR file rather than change and rebuild the application?

Editing the LDR image itself is not recommended nor supported. If you overwrite the content of the tools-generated LDR file, you will be corrupting the boot image that is guaranteed to be accurate by virtue of being generated appropriately by the tool chain. I realize the date string you provided is just an example of what you wish to do, but I will use it to formulate the response. Whether or not you have full confidence that this date string is the very first piece of payload data (immediately after the block 0 header at offset 0x10) AND is the exact same size as whatever data elements you are replacing, it is recommended to change the string in the source code and rebuild the project such that the LDR file is correct for the modified application. If you absolutely want to manually modify your LDR file, then you'd need to edit the binary image directly. However, there is no guarantee that the application will function properly if the LDR image is post-modified in this fashion.

I don't want to change the LDR file manually. I mean, I want to write some values on an address, where I can find the value in the LDR file that has been generated.

In my application I write this:

const char data[] = "some useful stuff";

memcpy((char *)0x8000010, data, sizeof (data));

but when I look at the ldr file at address 0x800010, the values is not written.

A runtime initialization isn't going to affect the memory that is loaded.

Instead you can define an initialized global array in C that you resolve to the required specific address in the LDF.

Here's the example I tried:

#pragma retain_name // a good idea is not used
extern char myData[] = "test passed";

int main() {
return 0;
}

In the LDF I added a use of RESOLVE for the C linkage mangled name (_ prefix) for myData:

PROCESSOR p0 {
OUTPUT( $COMMAND_LINE_OUTPUT_FILE )

// Resolve the CRT start symbol to the reset address.
RESOLVE(START_SYM, START_ADDR)
RESOLVE(_myData, 0x8000010) // Added

KEEP(START_SYM, _main)

#if !defined(NO_UTILITY_ROM)
#include "ADSP-BF707-LDF.h"

This results in myData being mapped to the address chosen and that will be updated in the loader file.

Regards,
Stuart.

I don't think you are using the LDR term correctly. The LDR image is the boot image that gets resolved to whatever the source of your boot stream is, whether it is an external host, serial SPI memory, etc. This image is static in nature and isn't written to during runtime. The memcpy command you furnished is dynamically writing to L2 SRAM when the application is run. It is NOT modifying the LDR file boot image itself, which initializes all the L1 and L2 memory when the processor first boots. You'd need to view the L2 memory space in a debug view after running this code sequence to see the result of the memcpy operation.

It didn't work for me.

[Error li1173] Failed to extract symbol '_myData' needed for absolute placement.
Symbol is embedded in object (.epcdata, .epcdata.end).

Linker finished with 1 error
cc3089: fatal error: Link failed (code:1)

Ah, smaller variables get collected into bss data blocks and that wouldn't allow absolute placement of a variable within such a block. If you put #pragma symbolic_ref before the variable definition that should avoid the problem.

Regards,
Stuart.

It works, but the ldr file is not running anymore in my board.

I changed the address and it works now.

Thanks for your help.

Regards

SVA