acassis commented on issue #16444: URL: https://github.com/apache/nuttx/issues/16444#issuecomment-2912501535
@linguini1 I'm copying KR message here (since he doesn't use 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. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
