placing data in an absolute address in flash(ROM)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

placing data in an absolute address in flash(ROM)

Jump to solution
3,261 Views
hajianik
Senior Contributor I

Hi,

I'm trying to place a variable called my_checksum in an absolute flash location. Target is S32K144EVB and I'm using design studio 1.3. Here is what I did:

In the linker file used for this project which is attached.I added  m_chksum to memory areas:

 

/* Specify the memory areas */

MEMORY

{

/* Flash */

m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400

m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010

m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x00070000/*0x0007FBF0*/

/*this was added*/

m_chksum (RX) : ORIGIN = 0x00070410, LENGTH = 0x00000008

/* SRAM_L */

m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00008000

 

/* SRAM_U */

m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00007000

}

 

and added the section below:

 

/* koor added*/

.myBufBlock :

{

. = ALIGN(4);

KEEP(*(.myBufBlock)) /* keep my variable even if not referenced */

. = ALIGN(4);

} > m_chksum

 

In the main.c I added the line below, just before main()

 

__attribute__((section (".myBufBlock"))) unsigned long my_chksum=0X12345678 ;

 

looking at the MAP file it places my_chksum at  0x1fff8400                my_chksum

which is the start of the code _ram in .data section .

 

Any idea why is it doing that?

The target is a 512k part and I am not exceeding that .when I build the code and run , everything seems normal except the address of my_chksum variable.

 

Thanks,

Koorosh Hajiani

Original Attachment has been moved to: S32K1xx_flash.ld.zip

Labels (1)
0 Kudos
1 Solution
2,721 Views
martin_kovar
NXP Employee
NXP Employee

Hello,

linker file you shared does not contain the code you have written in your post, but when I tested the code you wrote above, map file is correct and variable my_chksum is placed at address 0x00070410.

Please see the files in the attachment.

Regards,

Martin

View solution in original post

0 Kudos
8 Replies
2,721 Views
johnadriaan
Contributor III

May I recommend that you change the variable definition to include the const modifier?

__attribute__((section (".myBufBlock"))) const unsigned long my_chksum=0X12345678 ;

Because your declaration was non-const, the compiler wants to put it in ROM as an initialised variable, and then copy it into RAM at boot for you to modify it. By declaring a linker section for it this process is altered, but you're still making it hard for the compiler.

By making it const, it makes more sense to whoever reads the code, as well as the compiler.

As for the "accessed via 0x5064" issue, that has to do with the ARM assembly language. Every ARM instruction is exactly 32 bits (16 bits for Thumb/Thumb2, but that's another topic). That means that it cannot encode a 32-bit offset into an instruction - there'd be no room left for the actual op-code! So instead what the compiler does is encode an instruction like "Load a register with the 32-bit contents of memory that is 128 bytes away from here":

ldr    r13,(pc+0x80)

The value 0x80 is easily stored as part of the rest of the op-code - the maximum is ±4095 bytes - but it means that the compiler has to also store the 32-bit address in the code somewhere nearby, rather than explicitly as part of the instruction.

0 Kudos
2,722 Views
martin_kovar
NXP Employee
NXP Employee

Hello,

linker file you shared does not contain the code you have written in your post, but when I tested the code you wrote above, map file is correct and variable my_chksum is placed at address 0x00070410.

Please see the files in the attachment.

Regards,

Martin

0 Kudos
2,722 Views
hajianik
Senior Contributor I

Hi,

Something peculiar about this that I can't explain,

When I look at the hex file generated for this, the address 0x70410 does not exist and yet the variable "my-chksum" that I placed at that address appears in the Map file correctly.

I also print the address of this variable correctly.

Furthermore when examining the disassembly of the code, It appears that the address is fetched from location 0x5064 which is in the main.o memory region and looking at that location in the hex file ,it in fact contains the address 0x70410.

Can you shed some light on this? 

why this location is not in .hex file and why it is accessed via  location 0x5064?

Thanks,

Koorosh Hajiani

0 Kudos
2,722 Views
martin_kovar
NXP Employee
NXP Employee

Hello,

I used your code and works correct on my side. Please see figures below:

pastedImage_1.png

Here is map file:

pastedImage_2.png

I am attaching you the project I used.

Regards,

Martin

2,722 Views
hajianik
Senior Contributor I

Hi Martin,

Thank you for your response.

I noticed that in your project you've selected the "S-RECORD" for the flash image .

this works for me too however when I select the "INTEL HEX" , it will place 0X 70410 at location 0x5064(as if 0x5064 is a pointer which points to location 0x70410 and yet this section shows correctly in the MAP file.

This is a bit strange. I've been googling this and can't find any answers. the  image of hex file is attached.

Keep in mind the Endianess of Intel vs. Motorola.

Thanks,

Koorosh Hajiani hex_capture.PNG

0 Kudos
2,722 Views
ummerkunnummalk
Contributor III

Please share the complete hex file. Probably the section you have created is appended at the end.

0 Kudos
2,722 Views
hajianik
Senior Contributor I

So I KNOW WHAT THE ISSUE WAS NOW , THANKS FOR POINTING THAT OUT.

In my project folder in Design Studio under  Project_Setting/Linker_Files/  , there are seceral .ld files :

S32K144_100_flash.ld ....and also S32K1xx_flash.ld. Cheking the project property just now ,I realized that this one

"S32K1xx_flash.ld" is used as the Linker Script file for this project and this is the one I attached yesterday.

However when I was doing this yesterday, I was under the impression that "S32K144_100_flash.ld" is the file used for the project and did modify this file which was not used by the project.

So I did not mean to attach "S32K1xx_flash.ld" but I did  by mistake (Go Figure)which led to the solution.

Thanks,

Koorosh Hajiani

0 Kudos
2,722 Views
hajianik
Senior Contributor I

Hi,

Thanks for the reply.

Sorry

where are the attachment you are talking about. I don't see them.

I'm totally confused now.

Thanks,

Koorosh Hajiani

0 Kudos