S32Kのトピックplacing data in an absolute address in flash(ROM)

placing data in an absolute address in flash(ROM)

hajianik — Wed, 21 Jun 2017 20:26:01 GMT

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

Re: placing data in an absolute address in flash(ROM)

martin_kovar — Thu, 22 Jun 2017 13:49:34 GMT

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

Re: placing data in an absolute address in flash(ROM)

hajianik — Thu, 22 Jun 2017 14:32:10 GMT

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

Re: placing data in an absolute address in flash(ROM)

hajianik — Thu, 22 Jun 2017 15:14:49 GMT

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

Re: placing data in an absolute address in flash(ROM)

hajianik — Fri, 23 Jun 2017 14:49:24 GMT

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

Re: placing data in an absolute address in flash(ROM)

martin_kovar — Mon, 26 Jun 2017 11:43:02 GMT

Hello,

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

Here is map file:

I am attaching you the project I used.

Regards,

Martin

Re: placing data in an absolute address in flash(ROM)

hajianik — Mon, 26 Jun 2017 14:46:04 GMT

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

Re: placing data in an absolute address in flash(ROM)

ummerkunnummalk — Mon, 09 Sep 2019 12:46:26 GMT

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

Re: placing data in an absolute address in flash(ROM)

johnadriaan — Fri, 31 Jul 2020 04:47:07 GMT

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.