[SOLVED] STM32F103ZE 64KB Memory depleted by String class array

Generic boards that are not Maple or Maple mini clones, and don't contain the additional USB reset hardware
gasparobr
Posts: 7
Joined: Tue Jan 17, 2017 4:15 pm

[SOLVED] STM32F103ZE 64KB Memory depleted by String class array

Post by gasparobr » Wed Aug 30, 2017 10:09 pm

Hi... I'm new in this group.
I'm with a problem to handle the 64 Kbytes of my STM32F103ZE with STM32Duino.

I did a simple code, and it just work until it uses 31kb, more then that the system halt before run. Could some one help me?

Code: Select all

String ramtest[2160]; // <= WITH THIS THE SYSTEM WORK
String ramtest[2170]; // <= WITH THIS THE SYSTEM HALT

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);

}

void loop() {
  // put your main code here, to run repeatedly:

  delay(3000);
  Serial.println(SERIAL_TX_BUFFER_SIZE);
}
O sketch usa 18412 bytes (3%) de espaço de armazenamento para programas. O máximo são 524288 bytes.
Variáveis globais usam 30840 bytes de memória dinâmica.
/Users/nancysbinda/Git_Repository_SRM/Arduino/hardware/Arduino_STM32-master/tools/macosx/serial_upload cu.SLAB_USBtoUART {upload.altID} {upload.usbID} /var/folders/72/568_sxq93bl98xpn3my7p1cw0000gn/T/arduino_build_81547/sketch_aug30a.ino.bin
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0414 (High-density)
- RAM : 64KiB (512b reserved by bootloader)
- Flash : 512KiB (sector size: 2x2048)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32F103ZE 64KB Memory Handle Error

Post by victor_pv » Thu Aug 31, 2017 2:49 am

Not sure why you would need so many strings at the same time, but well that's off topic.

It's hard to say why your sketch is crashing, but besides the memory you assign for variables, there is also the Stack and the Heap in RAM.
They grow towards each other, so you can run in a situation where the Stack overwrites variables in the Heap, or the Heap overwrites data in the stack. Either case causes a corruption of memory and likely a crash.
I can't say how much memory you are using in either, but it you use a lot of "new" or "malloc" to alocate space for variables, that will come from the heap and can end up crashing with the stack.

On the other hand, if you have some code that nests functions calls a lot before unwinding it all, that will grow the stack a lot. Also if you declare objects that take a lot of ram, like those strings, as local, they take a lot of memory from the stack.

User avatar
RogerClark
Posts: 7157
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32F103ZE 64KB Memory Handle Error

Post by RogerClark » Thu Aug 31, 2017 7:41 am

I did a quick test on the Maple mini to determine where in RAM these global variables would get allocated.

Code: Select all

String ramtest;
String ramtest2;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.print((int)&ramtest,HEX);
  Serial.print(" ");
  Serial.println((int)&ramtest2,HEX);
  delay(1000);
}
And interestingly I get

20001814 20001820

i.e ramtest is at 0x20001814
ramtest2 is at 0x20001820

There relative positions is OK, as I also did sizeof(ramtest) and it is 12 bytes

I'm not an expert in linker files (Rick can probably help here)


I did however look in the map file, and I can see

.bss 0x200017f8 0x380

and

.bss.ramtest 0x20001814

What I'm not sure about is why bss seems so far from the base of RAM

User avatar
RogerClark
Posts: 7157
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32F103ZE 64KB Memory Handle Error

Post by RogerClark » Thu Aug 31, 2017 7:43 am

Update

I ran the same test on STM32GENERIC and I get

20000E0C 20000E24


So I think potentially there is an issue with the bss location on Libmaple

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZE 64KB Memory Handle Error

Post by Pito » Thu Aug 31, 2017 7:46 am

I saw the issue with F103ZE while running the simple USB TX test. With F103ZE I cannot allocate bigger buffer than 16kB (ie. 32kB did not work).
Pukao Hats Cleaning Services Ltd.

User avatar
RogerClark
Posts: 7157
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32F103ZE 64KB Memory Handle Error

Post by RogerClark » Thu Aug 31, 2017 7:51 am

Pito wrote:
Thu Aug 31, 2017 7:46 am
I saw the issue with F103ZE while running the simple USB TX test. With F103ZE I cannot allocate bigger buffer than 16kB (ie. 32kB).
I think someone who understands linker files needs to look at the libmaple linker files, as there seems to be a big chunk of RAM which can't be used.

I guess this could be for the stack, but I thought thats normally put at the top of ram and moves downwards

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32F103ZE 64KB Memory Handle Error

Post by Pito » Thu Aug 31, 2017 7:55 am

We need a simple test sketch to verify/replicate the issue.
For example: http://www.stm32duino.com/viewtopic.php ... 787#p33787
You may combine Stack vs Heap Buffers allocation.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32F103ZE 64KB Memory Handle Error

Post by victor_pv » Thu Aug 31, 2017 1:19 pm

Answering some of the questions above.
BSS are the variables initialized to 0. It goes in memory after the variables initialized with any value, that's why they start higher than 0x2000000

The test Roger did is not the same the OP did though, since the OP used an array of strings, so Roger's doesn't take as much memory.

I just had a quick look at the linker script for the ZE and don't see the problem, the start address looks right and is set to 64KB size, and the linker script, and the startup code that initializes BSS to 0 looks all correct, using 32bit pointers and no masks or anything like that could stop initialization beyond 32KB. Perhaps Rick can find something I missed.

victor_pv
Posts: 1681
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32F103ZE 64KB Memory Handle Error

Post by victor_pv » Thu Aug 31, 2017 1:40 pm

Pito wrote:
Thu Aug 31, 2017 7:46 am
I saw the issue with F103ZE while running the simple USB TX test. With F103ZE I cannot allocate bigger buffer than 16kB (ie. 32kB did not work).
Pito that issue may have been different though, depending how the buffers are managed there may be masks, pointers, etc, smaller than uin32, and so limiting the buffer size that can be managed.
A uint16 would allow 64KB, a int16 would allow 32KB, since negatice numbers probably don't make much sense for a pointer depending how the code is written, so if the are conversions between int and uint, anything larger than 32KB could result in non-sense math, and if there is a division somewhere perhaps that's turning 32KB in 16. Not saying that's the case for sure, but can't say that the issue is the same as the OP's either.
I think much more context to his code is needed. Are his variables global or local? is he using malloc or new accross the sketch for something else? any use of malloc or new will not be accounted for as RAM used in during compilation, neither any local variable.
He may be copying those strings to local ones somewhere in his code, so for every KB in size he increases those variables, there may be several more using in Heap and Stack at runtime...

Just did a compilation of the sketch in the first post, and this is the relevant chunk in the map file.

Code: Select all

 .bss.ramtest   0x20000ddc     0x65b8 .\sloeber.ino.cpp.o
                0x20000ddc                ramtest
 .bss.pbreak.4444
                0x20007394        0x4 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(syscalls.c.o)
 .bss.line_dtr_rts
                0x20007398        0x1 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(usb_cdcacm.c.o)
 .bss.vcomBufferTx
                0x20007399      0x100 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(usb_cdcacm.c.o)
 *fill*         0x20007499        0x3 
 .bss.tx_head   0x2000749c        0x4 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(usb_cdcacm.c.o)
 .bss.rx_hook   0x200074a0        0x4 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(usb_cdcacm.c.o)
 .bss.vcomBufferRx
                0x200074a4      0x100 C:/Users/Victor/workspace/ZE_RAM_ALLOC/Release/arduino.ar(usb_cdcacm.c.o)
 .bss.transmitting
This is the end of BSS (still under 32KB):

Code: Select all

0x20007740                _end = __bss_end__
It's interesting that the USB buffers are placed right after than, so perhaps there is some code with the USB having trouble managing a buffer past a certain address. I have not ran this, just compiled it to see where things were being placed.

gasparobr
Posts: 7
Joined: Tue Jan 17, 2017 4:15 pm

Re: STM32F103ZE 64KB Memory Handle Error

Post by gasparobr » Thu Aug 31, 2017 2:16 pm

I did the RAM TEST and the ANSWER was:

200010B4 200010C0


RogerClark wrote:
Thu Aug 31, 2017 7:41 am
I did a quick test on the Maple mini to determine where in RAM these global variables would get allocated.

Code: Select all

String ramtest;
String ramtest2;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.print((int)&ramtest,HEX);
  Serial.print(" ");
  Serial.println((int)&ramtest2,HEX);
  delay(1000);
}
And interestingly I get

20001814 20001820

i.e ramtest is at 0x20001814
ramtest2 is at 0x20001820

There relative positions is OK, as I also did sizeof(ramtest) and it is 12 bytes

I'm not an expert in linker files (Rick can probably help here)


I did however look in the map file, and I can see

.bss 0x200017f8 0x380

and

.bss.ramtest 0x20001814

What I'm not sure about is why bss seems so far from the base of RAM

Post Reply