Nut/OS On ATmega2561
This document explains how to get Nut/OS running on the ATmega2561. Be aware, that this support is still beta and may not work reliable.
It is assumed that you are familiar with creating Nut/OS applications using the ImageCraft AVR Compiler. Otherwise follow the beginner's tutorial about Using ImageCraft C with Nut/OS first.
The GNU Compiler Collection and the Linux platform are currently not supported. Any help with this is highly appreciated.
When Atmel released the ATmega103 in 1998, an internal flash memory size of 128 kBytes looks like a lot of program space. It even took many months until all compilers and programmers were able to make use of the second half. To that time most applications fit easily in 64 kBytes.
Over the time applications had become more complex. It was easy to foresee, that sooner or later developers will ask for more flash memory.
Later the ATmega103 was replaced by the ATmega128, which mainly offered faster execution speed and more peripherals, but program space was still limited to 128 kBytes. This is due to the 16 Bit address bus of the 8-bit AVR MCUs. Data memory is accessed byte-wise, a total of 64 kBytes of data memory is available. Program memory is accessed word-wise. With a word size of two bytes this results in 128 kBytes total. Breaking this limit and still maintaining binary code compatibility isn't trivial.
Finally Atmel came up with the ATmega256 in two flavors. The ATmega2561 is a pin to pin replacement for the ATmega128, while the ATmeag2560 is packed in a larger package, providing more pins for additional peripherals. The most important difference between the ATmega256 and any previous 8-bit AVR is, that the program counter was extended to three bytes. New instructions had been implemented to modify the most significant byte. Thus, the old instruction set still works in a known manner and many binaries would still work. However, operating systems and compilers at least stumble over the additional byte pushed on the stack during subroutine calls and interrupts.
Assembling an Ethernut with an ATmega2561 was an easy task. We chose the Ethernut 2.1 Rev-B.
The programming adapter provided a problem. Unfortunately the SP Duo, which we typically use for the AVR based boards, refused to program the upper 128k. Fortunately the ATJTAGICE mkII worked.
As mentioned earlier, the expanded program counter let most compilers and operating systems fail to run applications on this new AVR. During the past months several fixes and patches for Nut/OS, runtime libraries, GNU and ImageCraft compilers had been published to support these devices.
At the time of this writing, a first success had been achieved to run applications larger than 128 kBytes on Nut/OS 4.2.1, compiled on ImageCraft's ICCAVR V7.07B.
AVR Studio 4.12.454-rc3 had been used to program the chip via ATJTAGICE mkII. We currently do not know any alternative, thus you are limited to a Windows based desktop.
It is yet unknown, wether a solution exists for Linux. Probably different patches to Nut/OS are required for this.
As stated above, Nut/OS 4.2.1 or any later version is required. Also make sure you installed ICCAVR V7.07B or later.
After having installed Nut/OS, start the Configurator. Follow the standard procedure, but load the specially prepared configuration for the ATmega2561 mounted on an Ethernut 2 Board.
Select Edit -> Settings from the main menu.
On the second page of the settings notebook select the platform avrext-icc.
On the last page you may chose avr-jtagicemkii as the programmer used to upload executables to the board. However, this is required only for running the command line tools. This setting is ignored by the ICCAVR IDE and the AVR Studio GUI.
Click OK to confirm your changes.
In the Configurator's main window make sure, that the correct compiler and CPU had been selected.
Building the system is equal to the procedure used for other devices. Also do not forget to create a sample tree.
Building a Sample Application
Try the httpd sample application. Load the prepared project, which is available in the sample tree, into the ImageCraft IDE.
As this sample had been created for the ATmega128, it will probably fit into the lower half of flash memory on our mega256. To prove, that larger applications are properly running, we simply expand the code with dummy functions, declaring some variables volatile to stop the compiler from optimizing this code away.
The Imagecraft compiler is limited to 64 kBytes of code per module, so we have to add two source files, filler1.c and filler2.c.
Both are filled with about 400 lines, mainly containing simple loops incrementing a volatile variable. To avoid conflicts during linking, either 1 or 2 is added to each symbolic name.
You may have noticed the pragma statement. This is a special fix, which we will explain later. For now you may remove this line.
The settings on the first page of the compiler options are not different from the setting for other CPUs.
Do not get confused by the 4.1.4 path. You should use the paths of your build and sample directories.
The same is true for the second option page.
On the third page select the ATmega2561 device and enter -ucrtnutm256.o C:\ethernut-4.2.1\nutbld-21b256-icc\lib\nutinit.o in the field Other options. Of course your build directory path may differ.
After building the code you can use AVR Studio to program your Ethernut Board.
Your application may still fail for several reasons:
- Parts of Nut/OS are not ATmega256-aware
- Parts of the runtime library are not ATmega256-aware
- The compiler is still buggy
- Parts of your application code are not ATmega256-aware
As far as the compiler contains a bug, you may try to get help from ImageCraft. Note, that the ATmega256 support is still beta.
For the first two problems a simple trick may help. We can instruct the linker to keep Nut/OS and the runtime library in lower program space, followed by the application code in upper memory.
First you need to add a pragma statement at the beginning of each application source code file.
In the compiler settings add -bappcode:0x20000.0x3FFFF in Other Options, keeping all the options we added previously.
We simply need to rebuild the application, rebuilding Nut/OS is not required.
Do always check the map file to get an idea about locations and sizes of all your code. Click here to view the linker map produced with our sample using pragmas.
Not much had been checked until now. At least the following applications of the distributed samples are not working:
This is a very hardware specific tool.
Probably not related to the ATmega2561. Looks like the RAM file system is broken.
Probably the USARTs in the ATmega2561 requires a different handling.
Castrop-Rauxel, July the 9th, 2006.