F4 - Update boards.txt

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

F4 - Update boards.txt

Post by RogerClark » Mon Jul 03, 2017 6:58 am

https://github.com/rogerclarkmelbourne/ ... 2/pull/238

Changes to max sized etc in boards.txt on F4 boards. Probably OK but I have not had time to check

stevestrong
Posts: 1829
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: F4 - Update boards.txt

Post by stevestrong » Mon Jul 03, 2017 7:19 pm

It seems to work fine:

Code: Select all

Sketch uses 21,548 bytes (4%) of program storage space. Maximum is 514,288 bytes.
Global variables use 12,064 bytes (6%) of dynamic memory, leaving 184,544 bytes for local variables. Maximum is 196,608 bytes.

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

Re: F4 - Update boards.txt

Post by Pito » Mon Jul 03, 2017 7:25 pm

Is that just info taken from boards.txt or you can really allocate 192kB of ram??
Pukao Hats Cleaning Services Ltd.

stevestrong
Posts: 1829
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: F4 - Update boards.txt

Post by stevestrong » Mon Jul 03, 2017 8:00 pm

Just info taken from boards.txt.
Usable (theoretically) 128kB normal RAM + 64kB CCMRAM.

zmemw16
Posts: 1490
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: F4 - Update boards.txt

Post by zmemw16 » Mon Jul 03, 2017 8:05 pm

i'm pretty sure its split up 128k & ccram is 64k, at least one chip has a 4k chunk out of 196k reserved as well

from my collection of assorted f4 linker files, grep for -i ccmram|grep -i origin

Code: Select all

Debug_STM32F407VG_FLASH.ld:  CCMRAM (rw)     : ORIGIN = 0x10000000, LENGTH = 64K
Debug_STM32F407VG_RAM.ld:  CCMRAM (rw)     : ORIGIN = 0x10000000, LENGTH = 64K
STM32F407VETx_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F407VG_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F407VGTx_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F407ZGTx_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F417ZGTx_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F429ZI_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
STM32F429ZITx_FLASH.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
stm32f4_flash.ld:  CCMRAM (rw)     : ORIGIN = 0x10000000, LENGTH = 64K
stm32f4zgt.ld:CCMRAM (rw)      : ORIGIN = 0x10000000, LENGTH = 64K
with all grep -i origin i get the attached

stephen
Attachments
fred.txt
(4.48 KiB) Downloaded 9 times

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

Re: F4 - Update boards.txt

Post by victor_pv » Mon Jul 03, 2017 9:08 pm

Most our linker scripts do not have the CCM declared. I have done it for a couple of boards just for testing, but you can not use it all as single block since the addresses dont line up, and on top CCM in F4 can't be used for code or DMA, while it can be used for code in the F3...
But the ram is there, since those changes only affect the IDE reporting the size and what not, and do not cause any change to the linker scripts, I think't it's ok to keep them like that.
If we decide to add the CCM to the linker scripts in the future, then we can actually use that RAM.

Another option is to change those values to what we currently have in the linker scripts (like 112KB for some F4 and so on) and leave the CCM amount of of the total since we currently dont use it.

BTW if anyone is interested in using the CCM I modified the libmaple linker scripts for both the F3 and the F4 for testing and can pass them on.
I think I once placed the F4 USB buffers in CCM, since the USB doesn't use DMA, it's a good way to get a large buffer with 0 cost in RAM, and faster speed due to not being shared.
Last edited by victor_pv on Mon Jul 03, 2017 9:11 pm, edited 1 time in total.

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

Re: F4 - Update boards.txt

Post by Pito » Mon Jul 03, 2017 9:09 pm

If there is not a relevant change in the linker file such it really allocates 192kB I would stay with 128kB in the info taken from boards.txt..
Pukao Hats Cleaning Services Ltd.

zmemw16
Posts: 1490
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: F4 - Update boards.txt

Post by zmemw16 » Mon Jul 03, 2017 11:17 pm

steve's post shows way more than 128k available.
do mean set it to an appropriate 'memory directly accessible' value in boards.txt
stephen

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

Re: F4 - Update boards.txt

Post by victor_pv » Mon Jul 03, 2017 11:55 pm

zmemw16 wrote:
Mon Jul 03, 2017 11:17 pm
steve's post shows way more than 128k available.
do mean set it to an appropriate 'memory directly accessible' value in boards.txt
stephen
The memory set in boards.txt is the one the IDE uses to show how much RAM you have total and left, but is not used by the linker script to allocate memory. What Steve's post shows is what the IDE reads from boards.txt.
You could set boards to 512MB of RAM, and the linker would still not care about that and use what's in the linker scripts.

Currently the CCM memory is not used by the linker scripts in any way, so although available, is not usable. There are several changes needed to the linker script and the startup code to make it usable, but even then there are several caveats, that's why most people won't use it.

I kind of agree with Pito that unless we decide to go ahead with changes to the scripts and startup to use, it would be better to report only the main RAM in boards.txt.
The side effects of reporting 192KB while the linker allocates only 128KB is that the IDE may be telling you that you allocated 128KB of RAM and still have 64KB available for local variables (and stack), while in reallity your code will crash because there is no free space for even the stack.

stevestrong
Posts: 1829
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: F4 - Update boards.txt

Post by stevestrong » Tue Jul 04, 2017 5:09 am

Pito wrote:
Mon Jul 03, 2017 9:09 pm
If there is not a relevant change in the linker file such it really allocates 192kB I would stay with 128kB in the info taken from boards.txt..
Me too.
But lets include this feature, it is nice to have it.

Post Reply