Recent

Author Topic: [SOLVED] Variable addresses in SRAM  (Read 6522 times)

dseligo

  • Hero Member
  • *****
  • Posts: 1221
[SOLVED] Variable addresses in SRAM
« on: September 24, 2022, 11:22:20 am »
I have project working on a ATmega2561.
I only use one timer and digital I/O pins.

When I run it on a ATmega32U4 I have problem like random restarts or garbled text shown on LCD.
Lazarus says '...22080 bytes code, 1047 bytes data', so it should fit into ATmega32U4's 32KB flash.

What I suspect is that variables in SRAM are overwritten with stack.

So finally my question: how can I see last location used with variables?

I can see current SP value in debugger, so last variable location would help me estimate how much space I have to 'free'.
« Last Edit: September 25, 2022, 02:54:25 pm by dseligo »

d.ioannidis

  • Full Member
  • ***
  • Posts: 221
    • Nephelae
Re: Variable addresses in SRAM
« Reply #1 on: September 24, 2022, 11:40:40 am »
Hi,

  if you suspect heap and stack collision, you can find some information here [AVR] Investigating stack and heap management.  Also in AVR Freaks you can find information ( c only ) for stack painting to determine if you have stack problem ( I think I have something like that written in Free Pascal. I'll take a look tomorrow when I return home .... )

  Do you use the heap manager and/or recursive function/procedures ?

EDIT: Fixed url ....

regards,
« Last Edit: September 24, 2022, 11:43:44 am by Dimitrios Chr. Ioannidis »

dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #2 on: September 24, 2022, 12:01:37 pm »
  if you suspect heap and stack collision, you can find some information here [AVR] Investigating stack and heap management.  Also in AVR Freaks you can find information ( c only ) for stack painting to determine if you have stack problem ( I think I have something like that written in Free Pascal. I'll take a look tomorrow when I return home .... )

Thank you for information.

Quote
  Do you use the heap manager and/or recursive function/procedures ?

No recursive functions, only consts, vars, arrays, records.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6686
Re: Variable addresses in SRAM
« Reply #3 on: September 24, 2022, 12:31:24 pm »
No recursive functions, only consts, vars, arrays, records.

Any strings (as distinct from shortstrings) or dynamic arrays?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

d.ioannidis

  • Full Member
  • ***
  • Posts: 221
    • Nephelae
Re: Variable addresses in SRAM
« Reply #4 on: September 24, 2022, 02:43:07 pm »
Hi,


< snip >

So finally my question: how can I see last location used with variables?

I can see current SP value in debugger, so last variable location would help me estimate how much space I have to 'free'.

can you share your AVR development setup ?

OS, FPC version ?

How do you debug your AVR project ?

AVRSim, hardware debugger ( snap, medbg, atmel ICE ), Microchip( Atmel ) Studio's ATBackend, gdb version ?

No recursive functions, only consts, vars, arrays, records.

Also, if you use objects, IMHO, I recommend to switch to advancedrecords. I wasn't able to successfully debug objects when they're in different units ( I suspect bugs in dwarf  information ).

regards,

dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #5 on: September 24, 2022, 02:52:22 pm »
No recursive functions, only consts, vars, arrays, records.

Any strings (as distinct from shortstrings) or dynamic arrays?

MarkMLl

In all units I have {$H-} on the top. Additionally, all strings are declared as String[10], String[16] or String[20].

All arrays are with defined boundaries, but I have types declared like this:
Code: Pascal  [Select][+][-]
  1. TInt16_array = array of Int16;

I use to access this array:
Code: Pascal  [Select][+][-]
  1. var vars_Int16: array [0 .. vars_Int16_num - 1] of Int16;

like this (Fvars_Int16 is pointer to vars_Int16):
Code: Pascal  [Select][+][-]
  1. editInt16 := TInt16_array(Fvars_Int16)[FCurrentItem.miVar];

MarkMLl

  • Hero Member
  • *****
  • Posts: 6686
Re: Variable addresses in SRAM
« Reply #6 on: September 24, 2022, 02:54:43 pm »
So your TInt16_array is dynamic and goes on the heap, and is possibly reallocated (possibly resulting in fragmentation) during operation.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

d.ioannidis

  • Full Member
  • ***
  • Posts: 221
    • Nephelae
Re: Variable addresses in SRAM
« Reply #7 on: September 24, 2022, 02:58:31 pm »
Hi,

All arrays are with defined boundaries, but I have types declared like this:
Code: Pascal  [Select][+][-]
  1. TInt16_array = array of Int16;

i don't think that you can use dynamic array's without using the heapmgr unit ...

regards,


dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #8 on: September 24, 2022, 03:10:25 pm »
can you share your AVR development setup ?
OS, FPC version ?

How do you debug your AVR project ?

AVRSim, hardware debugger ( snap, medbg, atmel ICE ), Microchip( Atmel ) Studio's ATBackend, gdb version ?

Lazarus 2.3.0 (rev main-2_3-2515-g008af994c1) FPC 3.3.1 i386-win32-win32/win64 under Windows 11. Debug using atbackend.exe simulator described in your post here https://forum.lazarus.freepascal.org/index.php/topic,53342.0.html (btw. thanks for that :)).

Lazarus 2.3.0 (rev main-2_3-2551-g402c6a3c09) FPC 3.3.1 x86_64-linux-gtk2 under Debian 5.10.140-1 (virtual machine). Debugging using simavr described here https://wiki.freepascal.org/Remote_Debugging#Using_avr-gdb (thanks @ccrause).

Quote
Also, if you use objects, IMHO, I recommend to switch to advancedrecords. I wasn't able to successfully debug objects when they're in different units ( I suspect bugs in dwarf  information ).

I use objects. Is there any other advantages/disadvantages of switching to advanced records (in regarding to AVR development)?

dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #9 on: September 24, 2022, 03:19:36 pm »
So your TInt16_array is dynamic and goes on the heap, and is possibly reallocated (possibly resulting in fragmentation) during operation.

All arrays are with defined boundaries, but I have types declared like this:
Code: Pascal  [Select][+][-]
  1. TInt16_array = array of Int16;

i don't think that you can use dynamic array's without using the heapmgr unit ...

I must check in assembler, but I don't think it is used as dynamic array. Array is not declared as dynamic array, I just use this type so in my other unit I don't have to know size of the array.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6686
Re: Variable addresses in SRAM
« Reply #10 on: September 24, 2022, 03:48:12 pm »
I use objects. Is there any other advantages/disadvantages of switching to advanced records (in regarding to AVR development)?

Objects or instances of classes? :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #11 on: September 24, 2022, 03:55:27 pm »
I use objects. Is there any other advantages/disadvantages of switching to advanced records (in regarding to AVR development)?

Objects or instances of classes? :-)

Old style object, like this:
Code: Pascal  [Select][+][-]
  1.   TMenu = object
  2.   private
  3. ...
  4.  

MarkMLl

  • Hero Member
  • *****
  • Posts: 6686
Re: Variable addresses in SRAM
« Reply #12 on: September 24, 2022, 04:02:58 pm »
Old style object, like this:

Just checking, because of the naming ambiguity :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dseligo

  • Hero Member
  • *****
  • Posts: 1221
Re: Variable addresses in SRAM
« Reply #13 on: September 24, 2022, 04:31:55 pm »
I noticed one thing with constants: although I have {$WRITEABLECONST OFF} if I use typed constant like below they go into SRAM.

Code: Pascal  [Select][+][-]
  1. const
  2.   KrugAport: Byte = {%H-}Byte(@PORTB);
  3.   KrugApin: Byte = 1 shl 7;

I guess I won't use type with constants to save SRAM.

d.ioannidis

  • Full Member
  • ***
  • Posts: 221
    • Nephelae
Re: Variable addresses in SRAM
« Reply #14 on: September 24, 2022, 05:50:03 pm »
Hi,

< snip >
Also, if you use objects, IMHO, I recommend to switch to advancedrecords. I wasn't able to successfully debug objects when they're in different units ( I suspect bugs in dwarf  information ).

I use objects. Is there any other advantages/disadvantages of switching to advanced records (in regarding to AVR development)?


I don't know anything more than one can read here. Debugging is the main reason I use advancedrecords for AVR ( maybe for other mcu's is the same regarding objects and debugging, I don't know ).


Lazarus 2.3.0 (rev main-2_3-2515-g008af994c1) FPC 3.3.1 i386-win32-win32/win64 under Windows 11. Debug using atbackend.exe simulator described in your post here https://forum.lazarus.freepascal.org/index.php/topic,53342.0.html (btw. thanks for that :)).

Thx ! Glad you find it useful.

regards,

 

TinyPortal © 2005-2018