Dear avr-libc developers, I was just pointed out that, unlike for ARM targets, the RIOT build system does not check for overflow of RAM and ROM. Manual checking confirms that I'm using 8443B out of 8192B :-(
Sorry for disturbing with a stupid question. Kind regards, Marian ------------------------------------------------------------- M.Sc. Marian Buschsieweke Dept. Communication and Networked Systems (ComSys) Institute for Intelligent Cooperating Systems (IKS) Otto-von-Guericke-University of Magdeburg Universitätsplatz 2, Building 29, Room 314 39106 Magdeburg Germany http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html Tel.: +49 - 391 - 67 - 52673 Fax: +49 - 391 - 67 - 41161 ------------------------------------------------------------- On Mon, 23 Jul 2018 21:11:19 +0200 Marian Buschsieweke <marian.buschsiew...@ovgu.de> wrote: > Dear avr-libc developers, > > tl;dr: Does anyone know what could be the problem when the .bss section is > uninitialized? > > I'm trying to build RIOT [1] using avr-libc 2.0.0 and GCC 6.4.0 for the > Arduino UNO (ATmega328p) and the Arduino Mega2560 (ATmega2560), but I ran > into a > bunch of strange bugs. Upon investigation with AVaRICE and an AVR Dragon it > seems that the .bss section (or at least part of it) remains uninitialized, as > at least the variables I investigated on contained random values before they > were first used. > > I have to admit that I have trouble to get AVaRICE working reliable. (E.g. > setting breakpoints through gdb doesn't seem to work for me, but inline > assembly using `asm("break");` statements seem to work reliable for me.) So > maybe the problem is completely different and reading random values is caused > by my fragile AVaRICE setup... At least when reading the same variable > multiple > times without rebooting the Arduino I consistently get the same value, which > gives me some confidence in the results. > > How to reproduce: > - Clone git://github.com/RIOT-OS/RIOT > - cd into examples/default > - Add the following lines to the Makefile after assignment of the > BOARD_PROVIDES_NETIF variable: > > CFLAGS += -std=gnu99 # <-- Only required if asm("break"); is used > BOARD_PROVIDES_NETIF += arduino-mega2560 > USEMODULE += w5100 > CFLAGS += -DW5100_PARAM_CS=ARDUINO_PIN_10 > CFLAGS += -DW5100_PARAM_EVT=ARDUINO_PIN_2 > > - Run "make BOARD=arduino-mega2560" > - Add a breakpoint in file sys/net/gnrc/pktbuf_static/gnrc_pktbuf_static.c in > line 84 before `mutex_lock(&_mutex);` in function > `void gnrc_pktbuf_init(void)`. > - You could insert `asm("break");` into the code (and run > make BOARD=arduino-mega2560 again) > - Investigate the contents of _mutex. It contains a random value, even though > it should contain `NULL` > - Btw: "make BOARD=arduino-mega2560 flash" runs avrdude for you to flash the > board > > Compiling with other toolchains (other versions of GCC or/and avr-libc) result > in binaries that have similar issues. > > Does someone know what the problem could be? > > Kind regards, > Marian > > [1]: http://riot-os.org/ > > ------------------------------------------------------------- > M.Sc. Marian Buschsieweke > Dept. Communication and Networked Systems (ComSys) > Institute for Intelligent Cooperating Systems (IKS) > Otto-von-Guericke-University of Magdeburg > Universitätsplatz 2, Building 29, Room 314 > 39106 Magdeburg > Germany > > http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html > Tel.: +49 - 391 - 67 - 52673 > Fax: +49 - 391 - 67 - 41161
pgpc77fWgSaoc.pgp
Description: OpenPGP digital signature
_______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
