[En-Nut-Discussion] atmega2560 support

Thiago A. Corrêa thiago.correa at gmail.com
Sat Jul 12 01:44:20 CEST 2008


Hi, sorry for the delay.

On Thu, Jul 10, 2008 at 12:05 PM, Chris Gude <cg at tis-net.de> wrote:
>>> I recently worked on some changes to support the ATMega1280, which
>>> should be pretty similar to your work.
>>>
>>
>> Cool. Did you get the other serial ports to work too? I've done the
>> changes in the lua script to add the additional serial ports, but
>> didn't yet add it to the code.
>>
>>
>
> yes I got the other ports to work too, but I made the changes in
> ahdlcavr.c as I need to use PPP for my application.

Nice. I was going to check for HW_MCU_ATMEGA2560 to enable the other
ports, but after knowing that you are using 1280 I moved it to
HW_AVR_HAVE_UART2 and HW_AVR_HAVE_UART3, so we could more easily
support AVR parts with different capabilities. That was suggested in
2006 on the mailling list, so I thought I would go ahead and make it
happen on this port at least.

>>> If you use avr-gcc:
>>> First of all check whether the macro __AVR_3_BYTE_PC__ is activated.(It
>>> is used in arch\avr\os\context_gcc.c)
>>> This Macro is similar to MCU_ATMEGA2561 and makes sure, that the stack
>>> pointer is set correctly, so that the threads can be started.
>>>
>>
>> So, this is set in the Makefiles then? Nutconf.mk or something?
>> I grepped for it but couldn't find where it was set, then I guess this
>> confirms it. It's most likely not set, will try again with it
>> explicitly set on the makefile.
>>
>>
>
> To be honest I don´t know, where exactly the macro __AVR_3_BYTE_PC__ is
> set. I just undefined it if the macro for ATMega1280 is set. That was
> the easiest way for me.
>

Strange, it's not set on the command line when compiling the 2561 and
I don't think it's set on the include/cfg files either. Anyone using
the 2561 port? Does it actually works?

>>> And are you able to debug the Nut/Os code or just your usercode? Because
>>> if you are able to debug the Nut/Os you could set a breakpoint at
>>> NutInit() or NutInitHeap() to see where you get stuck.
>>>
>>>
>>
>> I suppose I could debug ethernut code as well, I'm not quite sure how
>> though. AVRStudio isn't exactly very good at debuging. Idealy, it
>> would have loaded up the debug symbols from ethernut ( I compiled with
>> debug support ), but it didn't.
>>
>>
>
> I also use AVRStudio and I can debug the Nut/Os code. The only thing I
> had to change was adding -gdwarf-2 in Makedefs.avr-gcc. After that I
> could open the code in AVRStudio and a set breakpoint at NutInitHeap(),
> so that I could debug the whole startup of Nut/Os.
>

I've changed it to use Makedefs.avr-gccdbg, so it already have
-gdwarf-2 plus -O0, so I guess it should work right? I've done a
project with my code on AVRStudio and just link against the ethernut
libraries. How do you do it? Is there a trick involved to get
AVRStudio to debug ethernut code?
I'm using the JTAGICE mkII as well, but I had to downgrade AVRStudio
to 4.13.571  Service Pack 2 because latest AVRStudio has a bug when
programming parts that require external reset, and we have some boards
that requires it to be programmed.



More information about the En-Nut-Discussion mailing list