Hello,
as mentioned in one of my previous e-mails to this list (RFC: decoupling
ability to always panic from board_reset), I noticed #16444 and #16443
on GitHub.
I found some time to look into this and I believe I found the reason for
"If you add avr_lowputc calls in the board initialization code, you'll
see that the TX LED stays stuck on indefinitely."
Provided the board initialization code that sentence is talking about is
atmega_boardinitialize() in avr_boot.c, then avr_lowputc() likely does
not work because of the configuration used. According to #16444, the
configuration has:
CONFIG_DEV_CONSOLE=y
CONFIG_CONSOLE_SYSLOG=y
These two are processed in src/atmega/atmega_config.h
#ifndef CONFIG_DEV_CONSOLE
# undef USE_SERIALDRIVER
# undef USE_EARLYSERIALINIT
#else
# if defined(CONFIG_CONSOLE_SYSLOG)
# undef USE_SERIALDRIVER
# undef USE_EARLYSERIALINIT
# elif defined(HAVE_USART_DEVICE)
# define USE_SERIALDRIVER 1
# define USE_EARLYSERIALINIT 1
# else
# undef USE_SERIALDRIVER
# undef USE_EARLYSERIALINIT
# endif
#endif
With the configuration above, the outer ifndef is not true and first if
defined in else block is true, which results into:
undef USE_SERIALDRIVER
undef USE_EARLYSERIALINIT
Since CONFIG_STANDARD_SERIAL is also set, the undef of USE_SERIALDRIVER
is reverted by define USE_SERIALDRIVER 1 later. However,
USE_EARLYSERIALINIT remains unset.
This causes avr_earlyserialinit() to not be built nor called from
avr_lowinit(). Serial port peripheral is therefore not initialized yet
when atmega_boardinitialize() is called. I don't know what exactly
happens when you attempt to transmit data with the port not enabled but
my guess would be that "transmit data register empty" status flag is
just never cleared and the program ends up in a loop waiting for that to
happen.
Other than that - I recently tested NSH on mega1284p-xplained (well, a
breadboard with the chip stuck in it actually) and it worked for me. As
far as I can see, all AtMega devices use the same code for managing
serial ports so it should work out of the box.
Someone somewhere in some forum on the net has or had a footer in his
posts saying something along the lines of that non-functional serial
port is 99% mismatching baud rates, might be worth a re-check.
As for the PR itself (copying from e-mail mentioned at the beginning) -
I would recommend trying to use KEEP(*(.vectors)) as seen in
boards/avr/avrdx/breadxavr/scripts/breadxavr.ld - the default config
should then not need the "# CONFIG_DEBUG_OPT_UNUSED_SECTIONS is not set"
line.
