linker: section .bss' is not within region data'

[apws]

hi all, kindly please, what means this probably?? I am trying to figure out why on DxCore and megaTinyCore build fails with this message from linker. I am trying on avr128db28 and on tiny3226 with code size 10kb and ram size 2kb - everything works on Leonardo and also to some extent (at least build/upload - execution hangs after while, probably something with types/pointers) on Infineon XMC2Go, which is Cortex-M0. I know that to unify sketch for both will require some careful defining of types probably (8bit, vs 32bit) and some other defines. This mostly works. But on DXC/MTC it is the same linker error - what may be the cause probably ?? Or how to better see verbose output from linker, its not much specific ...

I am trying to isolate in quite lot of code what causes this, then I can post the code, but ... at least some point can help me; for me its weird it fails on 8-bit AVR on something :-(

there is verbose linker output (notice also twice ld.exe ??):

Linking everything together...

"C:\\Users\\petra\\AppData\\Local\\Arduino15\\packages\\DxCore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b/bin/avr-gcc" -Wall -Os -g -flto -fuse-linker-plugin -mrelax -Wl,--gc-sections,--section-start=.text=0x0,--section-start=.FLMAP_SECTION1=0x8000,--section-start=.FLMAP_SECTION2=0x10000,--section-start=.FLMAP_SECTION3=0x18000 -mmcu=avr128db28 -o "w:\\~prj\\220116-vscode-arduino-test\\SALLY_COMPILERS_TESTING\\build/sally-00.ino.elf" "w:\\~prj\\220116-vscode-arduino-test\\SALLY_COMPILERS_TESTING\\build\\sketch\\sally-00.ino.cpp.o" "w:\\~prj\\220116-vscode-arduino-test\\SALLY_COMPILERS_TESTING\\build/core\\core.a" "-Lw:\\~prj\\220116-vscode-arduino-test\\SALLY_COMPILERS_TESTING\\build" -lm

c:/users/petra/appdata/local/arduino15/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: address 0x80bcb3 of w:\~prj\220116-vscode-arduino-test\SALLY_COMPILERS_TESTING\build/sally-00.ino.elf section `.bss' is not within region `data'

c:/users/petra/appdata/local/arduino15/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: address 0x80bcb3 of w:\~prj\220116-vscode-arduino-test\SALLY_COMPILERS_TESTING\build/sally-00.ino.elf section `.bss' is not within region `data'

collect2.exe: error: ld returned 1 exit status
exit status 1

Thanks,
Petr

[apws]

well, I forced to redefine RAMEND to something withing SRAM range and it helped!!

weird is I now see also this in verbose output:
#define RAMEND INTERNAL_SRAM_END

BTW, would be nice some preprocessor #warning with possibility to output value of macro, but I didnt found it, I dont know the value of INTERNAL_SRAM_END and mostly why this #ifndef failed, respectivelly, why default RAMEND was too big ??:

#ifndef RAMEND
    #define RAMEND (4096-1)
#endif
//#define RAMEND (17000)
#define RAMEND (4000)

[apws]

okay, I found INTERNAL_SRAM_END in your packages and finally realized I treated RAMEND as RAMSIZE, so thinking helped ))

[SpenceKonde]

Very curious about what the code that broke this was! IT sounds to me like you were doing something unholy relating to memory sections...

And - also note that you can view the IO headers (the ones from microchip) for parts supported by DxCore here: https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/ioheaders/README.md

[apws]

It was really MY FAULT, I expected RAMSIZE but used RAMEND, like if RAM starts at 0 ... this was obvious after searching INTERNAL_SRAM_END value in entire DxCore subfolder in those io headers - some OTHER arduino implementations even doesnt containt such defines of RAMEND, RAMSIZE etc...

but would be great to emit macros values somehow to the log at least ... isnt this possible? tried something but no success...

[SpenceKonde]

Well, which macros would you emit? That's the problem: It's something like 300kb of text.....

DxCore and megaTinyCore contain an extra copy of the io headers in an accessible place. (only in the manual installation, and in the github repo - not board manager installations because nobody is going to dig around in their arduino15 folder looking for docs... so we don't include any docs or pinmap images (the images on DxCore are tens of mb) with board manager installation. Just the README (that's why all the links on README.md are full URLs, not relative URLs - so you can open the readme and get URLs to all the doc pages ;-))
The copies of the headers in /extras/ioheaders are not used. Those are copies of the ones contained in the compiler toolchain packages that I periodically build from the latest ATpacks from Microchip and which gets automatically installed by board manager, and used in preference to the older version that Arduino comes with (in Arduino installation location)/hardware/tools/avr/ ), which hasn't been updated in over 18 months.

IMO, on the modern AVRs, because the names of all the registers are so much longer, you need to have 3 windows open at all times to program them - your IDE, your PDF viewer with the datasheet, and a text editor with the IO header so you know how the names of all the bitfields and registers are spelled (as opposed to classic AVRs, where you could do i with just the IDE and PDF viewer)

That said - I have only used RAMSIZE for one thing: conditionally compiled code to set buffer sizes. I'm of the opinion that if you are using RAMSIZE or RAMEND for something other than that, you're in dangerous waters....

[apws]

no no, I mean to emit for example value of RAMSIZE to build log, some #warning or #pragma message or what, but I didnt found way how to output the VALUE of symbol RAMSIZE .... soooo simple thing, but nothing found

ya, I expected that it must go from somewhere if INTERNAL_SRAM_SIZE was noted in log, ... .okay now I understand things around RAM definition better - in fact, when I tried to search RAMEND in arduino installed packages too I found this definition in your tiny HardwareSerial.cpp or TinySoftwareSerial.h (and HardwareSerial.h uses RAMED-RAMSTART, so RAMSIZE too:

(I had in code something like that, using RAMEND, but it seems here for safety will be also better to have RAMSIZE ?? compare to twi.cpp somewhere) - I just needed to declare single large buffer to max value and that value was BAD based on RAMEND treated as RAMSIZE ...)

#if (RAMEND < 1000)
  #define SERIAL_BUFFER_SIZE 16
#else
  #define SERIAL_BUFFER_SIZE 64
#endif 

for example in twi.h you use THIS, so RAMSIZE ...:

#ifndef BUFFER_LENGTH
  #if (RAMSIZE < 256)
    #define BUFFER_LENGTH 16
  #elif (RAMSIZE < 4096)
    #define BUFFER_LENGTH 32
  #else
    #define BUFFER_LENGTH 130
  #endif
#endif 

and in UART.h is comment like this:
/* Use INTERNAL_SRAM_SIZE instead of RAMEND - RAMSTART, which is vulnerable to a fencepost error. */
(this "fencepost" interested me what it means, so I will persist description here ))))
fencepost error - wikipedia

(my single big BUFFER is used to store interpreted program, I am testing some sketch and modifying it to make things even smaller...)

ya... for the headers opened, I would definitely let IDE/intellisense/autocompletion to help with them :-) fortunately I am only playing in arduino playfield now, for simple things on smallest devices say from 8kB of flash and few pins for simple things, without any complex peripherals - I already understood that the new avr2 have FAR more complex peripherals, similar to Cortex-M ARM ... which is THE reason people still liked 8bit MCUs, for general simplicity )))