Re: Comment for AVR GitHub issue 16444 and PR 16443

[kr . git]

Thanks to you as well.

I spotted an error in the config posted both in the issue #16444 and PR 
#16443. It is the

CONFIG_RAM_START=0x800100

Unless I overlooked something, the RAM starts at address 0x200 
(0x800200) for AtMega 2560.

Not sure if that's what causing the problem though - as far as I can 
see, that value is actually only used as an input to CONFIG_RAM_END 
calculation and incorrect value in this macro simply reduces heap size.

The symptoms of the bug would match though - the program would be trying 
to use I/O registers as RAM.

Thing is - seeing the bug was narrowed down to heap initialization in 
nx_start - I remember that I ran into pretty much the same issue when 
adding support for AVR DA/DB family... and I can't remember what was the 
problem.

Maybe check the disassembly file? (RAW_DISASSEMBLY needs to be set for 
the file to be generated.) Verify that the .text section starts with jmp 
instructions for interrupt vectors. This is only a vague memory but I 
think that I ran into the issue because the linker removed .vectors 
section, thinking it was unreferenced. (But that should not happen here, 
the linked config shows CONFIG_DEBUG_OPT_UNUSED_SECTIONS is not set.)

Anyway, when that happened, the whole program got "shifted" - except for 
program memory that stored values of initialized variables. The data 
copy loop in initialization code (atmega_head.S) then read the values 
from the shifted location leading to a mismatch - variables were 
populated with wrong data. One of those variables was g_idle_topstack 
which directly sets start of heap. I think it initialized it to zero...?

Again, all of this is based on vague memory. TLDR version is: if able, 
check g_idle_topstack in up_allocate_heap and verify that it is correct.


On 2025-05-27 15:28, Alan C. Assis wrote:
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.