Uninitialized variable

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm developing in C language for the AT32UC3C2512C compiling with a makefile and using the avr32-gcc.exe (AVR_32_bit_GNU_Toolchain_3.4.3_820) 4.4.7

I'ld like to have a global variable not initialised at startup when the a reset occurs(watchdog reset for instance).

 

I've read this tuto: https://www.avrfreaks.net/forum/...

 

and tried to declared my variable like this:

board_flag board_flags __attribute__((section(".noinit")));

Seeing the map file generated by the toolchain, I can see that this variable is well put in the noinit section (not in bss).

Map file generated:

.noinit         0x0000015c       0x5a load address 0x8000d5c0
 .noinit        0x0000015c       0x58 src/adc.o
 .noinit        0x000001b4        0x2 src/driver/board.o
                0x000001b4                board_flags

.data1
 *(.data1)

.balign         0x000001b6        0x2 load address 0x8000d61a
                0x000001b8                . = ALIGN (0x8)
 *fill*         0x000001b6        0x2
                0x000001b8                _edata = .
                0x000001b8                _edata = .
                0x000001b8                PROVIDE (edata, .)
                0x000001b8                __bss_start = .

.bss            0x000001b8     0x2b58 load address 0x8000d61c

 

However this variable is still cleared during startup. Having seen the ld file I've noticed that the noinit section is not declared anywhere.

 

Is there a way to tell the toolchain to not initialize this variable at startup? If possible without modifying the ld file (currently using the default provided with the toolchain).

 

Thank you very much for your help.

 

Louis

This topic has a solution.
Last Edited: Fri. Oct 23, 2020 - 05:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

louis.heche wrote:
I've read this tuto:
That tutorial is for AVR8 not AVR32 ? Are you sure that AVR32 has support for .noinit ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As clawson suggests, this is very much depended on the specific toolchain you're using - not a "General" question.

 

https://www.avrfreaks.net/forum/how-declare-noinit-section-linker-file-avr32-gcc

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the answer I'm indeed using AVR32-gcc toolchain. I didn't see that the thread was about AVR8, sorry.

 

Thanks for the link. Ideally I'ld like to not modify the ld file for maintenance purpose, is there another way to do it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

louis.heche wrote:
is there another way to do it?
Well that kind of depends on what the LD is already doing. Is there any part of the RAM "not accounted for". If there is just put whatever needs to remain into your own __attribute__((section(".my_own_private_noinit"))) and then later --section-start=.my_own_private_noinit=<some address away from everything else> and that will position these variables "out of the way". The only variables the C runtime will be "messing with" are those in .bss (which the CRT will wipe to 0 before main) and those in .data (which the CRT will copy initial values to before main). If you have your own positioned variables then simply the fact they are not in .bss or .data means they won't be touched by any C library supplied CRT code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

louis.heche wrote:
Ideally I'ld like to not modify the ld file for maintenance purpose,

But what you're doing is giving instructions to the Linker to modify its behaviour - which is exactly the purpose of the .ld file.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Does your model UC3 have GPLP registers?

 

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for your answer. Now we are using the .ld provided for our target with the toolchain. Modifying it, makes our code more difficult to maintain between the different developers and less portable to new targets (now we just need to notify the toolchain the new target and the good ld file is taken).

 

After doubling checking, our UC3 does have a GPLP register, it is probably the best solution in our context as we just want to save a status variable. Thanks for your help, I didn't know the existence of such a register.

Last Edited: Fri. Oct 23, 2020 - 02:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

louis.heche wrote:
it is probably the best solution in our context

If that's resolved the issue, please mark the solution - see Tip #5 in my signature, below, for instructions:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...