Can't compile for target F072 (cannot move location counter backwards)

[piv3rt]

Hello,

When trying to compile this project for NanoVNA-H (TARGET=F072), the build fails with this error:

user@linux$ make TARGET=F072
[...]
Compiling vna_math.c
Linking build/ch.elf
/usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld:rules_data.ld:270 cannot move location counter backwards (from 0000000020004098 to 0000000020004000)
collect2: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
The command '/bin/sh -c make TARGET=F072' returned a non-zero code: 2

I should add that I commented out the following line in the Makefile to not encounter the problem described in this issue:
#UDEFS+= -DVNA_AUTO_SELECT_RTC_SOURCE

[lx0758]

+1

[lx0758]

Tested modified STM32F072xB.ld can be compiled through, But this does not seem to be the optimal solution.

[piv3rt]

How did you do this? Did you adjust the size of flash0 and flash7?

[lx0758]

I adjusted falsh0 and falsh7, but the total amount is limited to 128k, which is not a big problem. But to compile, I have to adjust ram0, which is obviously a problem. I wonder, how does @hugen79 do it?

[piv3rt]

Just trying to guess, I could be entirely wrong but maybe @hugen79 is using a compiler on a different platform which produces an image with a slightly smaller RAM footprint which doesn't exceed the size specified in the file you linked.
I'm building on Linux, I tried on a destkop Fedora and inside an Ubuntu Docker container. Both produced the same result.
@lx0758, are you building on Linux too?

[piv3rt]

I added a linker arg to dump the memory usage and it shows that both flash and ram regions overflow when building the project for STM32F072xB with default options enabled. Removing SD card support allows to save a little flash and I will now analyse how we can save RAM.

make TARGET=F072 USE_LDOPT=--print-memory-usage

For anyone wanting to help diagnose this issue, you can virtually increase ram0 to 32k on line 30 of STM32F072xB.ld so the linker doesn't crash. This will print memory usage but obviously it's just for debug purposes as the hardware RAM won't magically increase.

[lx0758]

I've tried it on Windows/Linux/Docker and it always ends the same.

[lx0758]

The latest news! I use https://github.com/DiSlord/NanoVNA-D ChibiOS folder to replace after successful compilation.

[piv3rt]

Just to be sure: did you replace the ChibiOS directory in this project with the one in DiSlord's project and compile again?
There's an alignment difference for .text sections that helps save a little space in flash but after looking at the diff between those folders, I'm not sure what makes it save RAM.

Well, thanks, this workaround is a bit dirty but it works and even solves the hal_lld_backup_domain_init issue.

Edit: it compiles but does not run 😔

[lx0758]

I burned and verified the compiled firmware. Unfortunately, it worked but the measurement function was basically broken.

[tjozwiak]

Hi, don't know is still valid, but the last commit, which can be compilable for me is:

commit 2efd945 (tag: 1.0.70)
Author: hugen79 [email protected]
Date: Fri Oct 8 23:11:50 2021 +0800

To do that, some feature blocking is needed (base on analysis - what has been added during merge from
source code of DiSlord version 1.0.69).

The limit is the size of RAM and Flash, which is not changable w/o uC changing :)

The status after the build:

text data bss dec hex filename
79036 392 16184 95612 1757c build/ch.elf

If someone is interested in - patch attached.
Haven't had possibility to test this on NanoVna-H (HW platform 3.6). Still waiting for it :)

Hopefully will help you.

Br, Tomek (SP7TEP)

0001-Build-adjust-configuration-to-make-code-compilable-f.zip

[tjozwiak]

just one info from USE_LDOPT=--print-memory-usage:

Linking build/ch.elf
Memory region Used Size Region Size %age Used
flash0: 79428 B 96 KB 80.80%
flash1: 0 GB 0 GB -nan%
flash2: 0 GB 0 GB -nan%
flash3: 0 GB 0 GB -nan%
flash4: 0 GB 0 GB -nan%
flash5: 0 GB 0 GB -nan%
flash6: 0 GB 0 GB -nan%
flash7: 0 GB 32 KB 0.00%
ram0: 16 KB 16 KB 100.00%
ram1: 0 GB 0 GB -nan%
ram2: 0 GB 0 GB -nan%
ram3: 0 GB 0 GB -nan%
ram4: 0 GB 0 GB -nan%
ram5: 0 GB 0 GB -nan%
ram6: 0 GB 0 GB -nan%
ram7: 0 GB 0 GB -nan

[tjozwiak]

Ok, finally found a solution.

To optimize a RAM memory usage there's only one way just to reduce the sweep point a bit off. any reduction is multiply by 16,
so when you reduce from 101 points to 99 points -> there's 32bytes less :)

Also I've switched off the SERIAL CONSOLE to keep SD CARD and all measure module enabled.
Now I manage to compile on HEAD of master branch.

New patch attached.

ALSO: Haven't had possibility to test this on NanoVna-H (HW platform 3.6) , like prev. one

Cheers Tomek

0002-Build-adjust-configuration-to-make-code-compilable-f.zip

[piv3rt]

Thank you, Tomasz!
I had disabled some features but hadn't thought about reducing the number of sweep points, which saves quite some RAM...
Nice trick!