Can not use __attribute__ ((section(".noinit"))) , is there any other ways to deploy a none initial value at a certain RAM address after reset when using S32DS IDE?

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

Can not use __attribute__ ((section(".noinit"))) , is there any other ways to deploy a none initial value at a certain RAM address after reset when using S32DS IDE?

Jump to solution
4,175 Views
13761826501
Contributor III

Some values defined in project are not allowed to be set to 0 after reset (not power off) in some occasions. But I could not find a keyword to define such type of values when using S32DS IDE. I try to use the clause __attribute__ ((section(".noinit"))) which can be use in IAR IDE, but the result is there isn't any definitions in S32K1xx_flash.ld file which provided by S32DS initialize project. 

Any solutions would be very appriciated !!  

Labels (1)
Tags (3)
0 Kudos
Reply
1 Solution
3,265 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

it looks that startup code uses default address for Vector table in RAM. The vector table is properly copied to _RAM_START - in example case to address 0x1FFF800C, but into VTOR register is stored address of RAM beginning 0x1FFF8000:

pastedImage_1.png

I missed that VTOR value must be align to 128 bytes. Quick dirty fix is just align your .noinit section to 128 bytes in linker file. With this you can use default startup code. 

 .noinit :
{
KEEP(*(.noinit))
. = ALIGN(128);
} > m_data

pastedImage_2.png

 

In this case RAM vector table is moved to address 0x1FFF8080. For more celean solution you need modify startup which is always cleaning RAM from __RAM_START to __RAM_END. 

So, thank you for finding this bug. I'll update the example. 

Jiri

View solution in original post

0 Kudos
Reply
3 Replies
3,265 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

I added example for .noinit section usage - https://community.nxp.com/docs/DOC-342136 

Hope it helps. 

Jiri 

0 Kudos
Reply
3,265 Views
13761826501
Contributor III

Hi Jiri,

     Thank you so much for your prompt reply.  I've followed the example and added .noinit section before _RAM_START is defined, but ERROR happened after I add '__attribute__ ((section(".noinit"))) int noinit_data[3];' into the C code file,. The target is S32K142 (I only have this in hand) and I created two types of S32DS project for testing it. one is built on PE platform code, the other is not. here is the results:

1. Handwriting project without using PE.

        No error would happen if I just use single step debuging,And 'noinit_data[]' remained unchanged after reset .

        but if I clicked  the Run in debug mode, then error happened, the executation went into default ISR, see below:

bl.PNG 

2. Project built on PE platform code:

        Inifinite executation ERROR occured during initialize CPU after power up or reset.  I tried to debug step by step , found an error happened while reading EDMA Status which locked execution on this part and can not step over it  sine an unwanted status returnd that causing the executation would not go further.

PE.PNG

I pretty sure that all project got no problems before add "__attribute__ ((section(".noinit"))) int noinit_data[3];". and I have check again and again about  the S32K142_32_flash.ld file.

ld.PNG

Any solutions ?

0 Kudos
Reply
3,266 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

it looks that startup code uses default address for Vector table in RAM. The vector table is properly copied to _RAM_START - in example case to address 0x1FFF800C, but into VTOR register is stored address of RAM beginning 0x1FFF8000:

pastedImage_1.png

I missed that VTOR value must be align to 128 bytes. Quick dirty fix is just align your .noinit section to 128 bytes in linker file. With this you can use default startup code. 

 .noinit :
{
KEEP(*(.noinit))
. = ALIGN(128);
} > m_data

pastedImage_2.png

 

In this case RAM vector table is moved to address 0x1FFF8080. For more celean solution you need modify startup which is always cleaning RAM from __RAM_START to __RAM_END. 

So, thank you for finding this bug. I'll update the example. 

Jiri

0 Kudos
Reply