Hi,
I don't think updating the comment can do any harm so why not. And since
I have a fresh experience of trying to add support for new AVR
family/board, I can certainly imagine that I would be confused if I
noticed the discrepancy between the comment about the variable and its
initialization
Hello KR,
No need to apologize! Thank you for all your help on this issue. I actually
didn't know about these "trampoline" sections, I had to look them up after
your email. If you think it might make the code clearer, I can update the
comments about `_eronly` to reflect that it is no longer the en
Well, I think I managed to figure it out.
First, an apology - I didn't read the patch in #16457 properly and
thought it just moves the _eronly assignment while it, in fact, changes
ABSOLUTE to LOADADDR too. Sorry for that.
After spotting this, I went and tried to find out how the change makes
Alright, I looked into the possible bug mentioned in the last paragraph
of my previous message and it seems the code is actually correct. What I
thought was that if register pair Z overflows, subsequent reads would
read from incorrect memory locations. However, that does not seem to be
the case
Hello,
I don't that is a correct fix and in fact, from a quick look at things
it seems to me that it actually introduces another bug. As described in
src/atmega/atmega_head.S, that value is supposed to be "Start of .data
section in FLASH". You changed it to end of .data section in FLASH. It
i
Managed to find a fix here: https://github.com/apache/nuttx/pull/16457
On Tue, May 27, 2025 at 11:24 PM Matteo Golin
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.
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 instruction
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
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, 202
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
10 matches
Mail list logo
