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.
>

Reply via email to