Thank you KR, I posted your message in that issue for reference.
I have a BK-AVR128 board: https://aliexpress.com/item/1005006234334573.html and will test NuttX on it to confirm. If everything is working as expected I will submit the board support to the mainline. BR, Alan On Tue, May 27, 2025 at 6:39 AM <kr....@kerogit.eu> wrote: > 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. >