Thank you for your help KR!
I also noticed this CONFIG_RAM_START=0x800100. Unfortunately, changing that
value to the proper 0x800200 did not really help the issue.
I went ahead and generated the disassembly like you suggested, and it does
appear that the .text section starts with jump instructions for all the
interrupt vectors:
00000000 <_stext>:
0: 0c 94 72 00 jmp 0xe4 ; 0xe4 <__start>
4: 0c 94 95 00 jmp 0x12a ; 0x12a <atmega_int0>
8: 0c 94 98 00 jmp 0x130 ; 0x130 <atmega_int1>
c: 0c 94 9b 00 jmp 0x136 ; 0x136 <atmega_int2>
10: 0c 94 9e 00 jmp 0x13c ; 0x13c <atmega_int3>
14: 0c 94 a1 00 jmp 0x142 ; 0x142 <atmega_int4>
18: 0c 94 a4 00 jmp 0x148 ; 0x148 <atmega_int5>
1c: 0c 94 a7 00 jmp 0x14e ; 0x14e <atmega_int6>
20: 0c 94 aa 00 jmp 0x154 ; 0x154 <atmega_int7>
24: 0c 94 ad 00 jmp 0x15a ; 0x15a <atmega_pcint0>
28: 0c 94 b0 00 jmp 0x160 ; 0x160 <atmega_pcint1>
2c: 0c 94 b3 00 jmp 0x166 ; 0x166 <atmega_pcint2>
30: 0c 94 b6 00 jmp 0x16c ; 0x16c <atmega_wdt>
34: 0c 94 b9 00 jmp 0x172 ; 0x172 <atmega_tim2_compa>
38: 0c 94 bc 00 jmp 0x178 ; 0x178 <atmega_tim2_compb>
3c: 0c 94 bf 00 jmp 0x17e ; 0x17e <atmega_tim2_ovf>
40: 0c 94 c2 00 jmp 0x184 ; 0x184 <atmega_tim1_capt>
44: 0c 94 c5 00 jmp 0x18a ; 0x18a <atmega_tim1_compa>
48: 0c 94 c8 00 jmp 0x190 ; 0x190 <atmega_tim1_compb>
...and so on...
`g_idle_topstack` is 0x800e2b in the disassembly. With RAM_START being
0x800200, and a size of 8192 bytes, that gives a `heap_size` of 5076 bytes.
That all seems fine.
However, printing out the value of `g_idle_topstack` (in binary using
`up_putc`) I can see that the value does not match. The printed value is
"1000011001110110" while the binary representation of 0x800e2b is
"100000000000111000101011".
Printing out the `heap_size` tells me it's "1111100111001101", which is not
5076.
It seems your suspicion about a mismatch is probably correct, although it's
not due to a misplaced vector table it seems.
I did, for fun, try enabling `CONFIG_DEBUG_OPT_UNUSED_SECTIONS` and it did
remove the vectors at the start of the assembly file. That image didn't
work.
Then I kept `CONFIG_DEBUG_OPT_UNUSED_SECTIONS` enabled and put the
`KEEP(*(.vectors))` suggestion in the linker script. Vectors are kept in
the image, and `g_idle_topstack` changes to 0x800be4. This image didn't
work either.
That got me thinking if there was another section getting unexpectedly
tossed, so I put `KEEP(...)` around basically everything in the linker
script. That didn't produce a different result, and still had the
`g_idle_topstack` of 0x800e2b.
I will continue to debug this, but if you have any other suggestions please
let me know. Thank you very much for all your help so far!
Matteo
On Tue, May 27, 2025 at 7:33 PM <kr....@kerogit.eu> wrote:
> 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.
> >>
>
