Managed to find a fix here: https://github.com/apache/nuttx/pull/16457
On Tue, May 27, 2025 at 11:24 PM Matteo Golin <matteo.go...@gmail.com> wrote: > 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. >> >> >> >
