Build problems with AVR

[raghu.ponuganti]

Hi,

I am sorry, I searched all the forum and read almost all threads relevant to this error but could not resolve this. So I am writing here.

I am trying to run the AVR demo template.
I followed all the steps in the link (of course the link is not up to date)
http://erika.tuxfamily.org/wiki/index.p ... on_Windows

When I try to build the project I get the following error in the cosol :

Code: Select all

01:55:30 **** Build of configuration Default for project SamplePrj ****
"C:\\Users\\Raghu\\workspaceTestosek\\SamplePrj\\Debug\\make_launcher.bat" all 
C:\cygwin\bin\bash found!
Using erika files in /cygdrive/r/MY_PRO~1/Masters/SOFTWA~1/OSEK/ONMICR~1/eclipse/plugins/CO5FA4~1.201/ee_files
makefile:76: /cygdrive/r/MY_PRO~1/Masters/SOFTWA~1/OSEK/ONMICR~1/eclipse/plugins/CO5FA4~1.201/ee_files/pkg/cfg/path_helper.mk: No such file or directory
makefile:112: /cygdrive/r/MY_PRO~1/Masters/SOFTWA~1/OSEK/ONMICR~1/eclipse/plugins/CO5FA4~1.201/ee_files/pkg/cfg/rules.mk: No such file or directory
make: *** No rule to make target `/cygdrive/r/MY_PRO~1/Masters/SOFTWA~1/OSEK/ONMICR~1/eclipse/plugins/CO5FA4~1.201/ee_files/pkg/cfg/rules.mk'.  Stop.

01:55:31 Build Finished (took 849ms)

I tried several option but no success. I have checked all the paths.
I am using the latest version (2.0.0.20121220_2011) of EE and RT-Druid
Path to Erika Enterprise in eclipse is set to Auto and it points to
[location on my filesystem with out any space]\eclipse\plugins\com.eu.evidence.ee_2.0.0.20121220_2011\ee_files
I have checked the paths ee_files/pkg/cfg/path_helper.mk and /pkg/cfg/rules.mk
The files does exist but still I get this error.

I tried changing the tool chain to Cygwin-GCC
in eclipse Project > properties > C/C++ Build > Tool Chain Editor >
Current Tool Chain : Cygwin GCC
Current Builder : GNU Make Builder

I get the following error

Code: Select all

02:14:52 **** Incremental Build of configuration Default for project TestPrj ****
Info: Configuration "Default" uses tool-chain "Cygwin GCC" that is unsupported on this system, attempting to build anyway.
make all 
/usr/bin/sh: cygpath: command not found
/usr/bin/sh: cygpath: command not found
Using erika files in 
makefile:76: /pkg/cfg/path_helper.mk: No such file or directory
makefile:112: /pkg/cfg/rules.mk: No such file or directory
make: *** No rule to make target `/pkg/cfg/rules.mk'.  Stop.

02:14:52 Build Finished (took 158ms)

Cygwin is installed in the path C:\cygwin
ee_files are at : R:\My_Projects\Masters\Softwares\OSEK\OnMicrocontrollers\eclipse\plugins\com.eu.evidence.ee_2.0.0.20121220_2011

Is there any common mistake that I am doing ?
Any other configuration needed .?
Please help me solving this.

Thanks and regards
Raghavendra
http://www.raghu.co.nr

[nicola.serreli]

Dear Raghavendra,

the first feeling is that the make command is not the one of provided by cygwin, i.e. a windows program that is not able to understand cygwin paths like

Code: Select all

makefile:76: /cygdrive/r/MY_PRO~1/Masters/SOFTWA~1/OSEK/ONMICR~1/eclipse/plugins/CO5FA4~1.201/ee_files/pkg/cfg/path_helper.mk

you can
1) try "which make" from a cygwin command line and check if the make program is the cygwin one
2) prepare configuration files with RT-Druid (from Eclipse gui interface or directly from command line) and then run the make from cygwin shell (in the project/Debug folder)

If it is true that the make is not the cygwin one, you should reorder elements in PATH environment variable (at windows preferences, or inside cygwin configurtion files). Depending on the solution you choose, it can be usefull/needed to close and reopen eclipse (or the cygwin console if you are trying to compile from command line).

Regarding the Eclipse toolchains, usually they do not work as they are. You should play a little more then a little with project preferences to set the correct path of all programs involved on the build. You shoud pay attention that you are doing a cross-compilation and that windows programs undestand windows path, while cygwin programs prefer cygwin paths (in both cases white-spaces on paths may be a big problem).
On windows, a standard RT-Druid Project is configured to open a cygwin shell and run the make on the generated makefile, then if the cygwin make is not the first on the path list, something wrong may happen.

Let me know if it helps,
Regards,
Nicola

[raghu.ponuganti]

Hi Nicola,

Thank you very much for the detailed information.
Unfortunately these tools are bit new for me. But with your information, I will try to fix it and update you. Thank you once again.

regards
Raghavendra

[raghu.ponuganti]

Hi Nicola,

The problem is solved, I could successfully build the sample project.
Problem was with my Cygwin. Some some the make package was not installed. I installed it and build was successful.

Now, the port am using is AVR5. I think the port is for the controller Atmega128. But I want to use Atmega328 (arduino board).
For this should I follow the complete sets here for porting
http://erika.tuxfamily.org/wiki/index.p ... controller
or
Just change of Microcontroller name in configurations is sufficient ?

Once again thanks for your support.

regards,
Raghavendra
www.raghu.co.nr

[nicola.serreli]

Dear Raghavendra,

I'm happy to ear that you solve the "make" problem.

Again, I do not know similarities and differences between atmega128 and atmega 328. For sure changing the name in the configuration is not a solution, because current version of RT-Druid does not reconize it (once erika starts to work on it, you/we can add the support, but this is a step that we can do later).

Then, a first try may be compile erika as it is using a compiler for atmega328 and hope :P
I expect that something does not work at compile time:

• if the compiler is really different from the one used time ago for the porting, it may do not recognize some parameters in the makefile
• the compiler may not recognize some keywork
• if there is some assembler code, again it may be a little different and the compiler may reject it
• the code related to the board may use different symbols and may provide different features

If everything compile, good, but still there is something that can go wrong :P

• some low-level code may be incomplete or wrong, like operations of: changing the stack, storing microcontroller's register, enter/exit from interrupts.
• some symbol may exist in both microcontrollers/boards, but they may have a different meaning or they may be used in a different way

Regards,
Nicola

[raghu.ponuganti]

Hello Nicola,

Thanks for the information.
I will work on and update you.

Wish you a happy new year.

regards
Raghavendra
www.raghu.co.nr

[raghu.ponuganti]

Hello Nicola,

As of my knowledge both the controllers Atmega128 and Atmega328 are nearly similar with changes in number of timers, memory etc ..,

Here is my progress and I need your support to proceed further.

I guess my first step compiling the sample project for ATmega328 is success.
I made following changes please review if what I have done is correct.
1. Copied mcu\atmel_atmega128 to mcu\atmel_atmega328 and modified all the references in the header file.
Note : the actual content i.e IO map and others are yet to be mofidied.
2. Copied boards\xbow_mib5x0 to boards\arduino_uno and modified all the references in the header file.
- Content is not yet modified but it is almost the same. I have only one LED on the board. Rest everything is same.
3. Modified in rules.mk
- Added reference to the newly created board.
4. Created rules for the new board
- arch/rules_arduino_uno.mk from rules/rules_xbow_mib5x0.mk
I had just blindly copied the content from rules_xbow_mib5x0.mk to rules_arduino_uno.mk. I doubt if this is correct ?
What changes have to be made in this board make file ?
5. Modified ee.h to include reference to the new controller ATmega328 and the new Board.
6. Modified the makefile .
- Changed the cpu to ATmega328 (AVR5_MODEL := atmega328)
- Changed the board ( EEOPT += __ARDUINO_UNO__ )
7. Modified the eclipse build propertied to use my own make file.

Fortunately build is successful for the new controller.
Now,
1. Is it correct what I have done ?
2. Is board mandatory to be used ? (with out board configuration build is unsuccessful)
3. Is there an easy way to generate the content in mcu\atmel_atmega328 ? or we have to manually create it using the Datasheet as reference ?
- Because this is the next big and major step :(
4. Is it possible to generate the makefile from RT-Druid automatically during build process ?
- I tried using MCU_DATA = AVR_5{
MODEL = ATMEGA32; };
But, it says AVR_5 is invalid enum and it showed some error while using MODEL also.

If these are fine, I will proceed with analysis on modifying the stack data, interrupts etc .,

Thanks a lot for your support.

regards
Raghavendra
http://www.raghu.co.nr

[paolo.gai]

Hi!

The two microcontrollers have the same core CPU, so I expect they differ mainly for the memory size, something maybe on the interrupt controller, and for the available peripherals.

If the system already compiles for you, I do not expect major modifications (but check the IRQ part that will be the most sensitive).

Please note that the CPU part for AVR was one of the first ones we did, and we did it before we inserted the "MCU" settings... for that reason some of the OIL attributes in the AVR5 CPU are actually better suited for the MCU part. We are open to suggestions here...

Moreover, soon or later we'll need to port the AVR port to the "common" infrastructure now user for the newest portings (see http://erika.tuxfamily.org/wiki/index.p ... or_the_HAL )...

As you can see there are various possibilities for improvements...

Let us know if you have specific questions on the porting examples or on other topics!

PJ

[raghu.ponuganti]

Hi Paola,
Thank you very much for your reply.

I have few questions regarding debugging which is very important for application development and test my porting as well.

From the wiki pages I got to know that RT-Druid development supports debugging. Also there is a statement in http://erika.tuxfamily.org/wiki/index.p ... Enterprise which says about the tutorial that explains compiling and debugging the application. I got link to only this tutorial http://erika.tuxfamily.org/wiki/index.p ... on_Windows but this not address about debugging.

Does this development environment natively support debugging or should we use external tools like "Open OCD" ?

Note : I have STK500 compatible device to communicate with AVR over JTAG.

Thank you very much for your support.

regards
Raghavendra
http://www.raghu.co.nr

[paolo.gai]

Most microcontrollers have their own debugging systems, either via jtag/serial line/usb/...

What we basically provide with ERIKA is:
- makefiles to compile an application and get an ELF/COFF file with debug symbols
- debugging scripts for a limited number of plaforms, typically these scripts are for Lauterbach Trace32 (because it is the most used in Automotive)
- then sometimes we provide instructions on how to load the ELF/COF file on a specific board.

In most cases, given the evlopment environment which arrives with the board/microcontroller, it is sufficient to import the COF/ELF file and program/debug it...

Ciao,

PJ

[nicola.serreli]

I guess my first step compiling the sample project for ATmega328 is success.

Good.

I made following changes please review if what I have done is correct.
1. Copied mcu\atmel_atmega128 to mcu\atmel_atmega328 and modified all the references in the header file.
Note : the actual content i.e IO map and others are yet to be mofidied.
2. Copied boards\xbow_mib5x0 to boards\arduino_uno and modified all the references in the header file.
- Content is not yet modified but it is almost the same. I have only one LED on the board. Rest everything is same.
3. Modified in rules.mk
- Added reference to the newly created board.
4. Created rules for the new board
- arch/rules_arduino_uno.mk from rules/rules_xbow_mib5x0.mk
I had just blindly copied the content from rules_xbow_mib5x0.mk to rules_arduino_uno.mk. I doubt if this is correct ?
What changes have to be made in this board make file ?
5. Modified ee.h to include reference to the new controller ATmega328 and the new Board.
6. Modified the makefile .
- Changed the cpu to ATmega328 (AVR5_MODEL := atmega328)
- Changed the board ( EEOPT += __ARDUINO_UNO__ )
7. Modified the eclipse build propertied to use my own make file.

I think is ok. Few notes:
4 -> changes may be related to missing dependences or command line parameters, but if it already compile, it may be enough as it is. Pay attention to windows/linux path.
6 -> as it is know, AVR5_MODEL := atmega128 is hard coded when the cpu type is AVR5. To solve it, we need to update RT-Druid or to add a specific support for arduino. We can think to it later.

Fortunately build is successful for the new controller.
Now,
1. Is it correct what I have done ?
2. Is board mandatory to be used ? (with out board configuration build is unsuccessful)
3. Is there an easy way to generate the content in mcu\atmel_atmega328 ? or we have to manually create it using the Datasheet as reference ?
- Because this is the next big and major step :(
4. Is it possible to generate the makefile from RT-Druid automatically during build process ?
- I tried using MCU_DATA = AVR_5{
MODEL = ATMEGA32; };
But, it says AVR_5 is invalid enum and it showed some error while using MODEL also.

If these are fine, I will proceed with analysis on modifying the stack data, interrupts etc .,

1 ok
2 -> you can use NO_BOARD and use EE_OPT to add your freshly new EE_OPTS (like __ARDUINO_UNO__ )
3 -> as far I know, you have to do manually from the Datasheet
4 -> as told by Paolo, the support of AVR5 was done before the introdution of MCU_DATA section.

One note regarding interrupts: again, the support of avr5 was done a long time before the introduction of a new (and more generic) way to handle interrupts. This has two impacts, the first is that you have to set them inside the cpu section, the second is that the list of interrupts (and their simbols) is hard coded and may not be the same set provided by atmega328

I hope is not too late to wish you a happy new year.

Regards,
Nicola

[paolo.gai]

Hi!

I have just missed your previous e-mail... about your questions:

point 4 - about the changes in rules_xbow_mib5x0.mk - This file contains the main compiling rules... I do not expect big changes for it. The name was given because at the beginning there was just 1 board supported

If you find out that all these files can be factorized out, we could think then in a more generic rules_avr5.mk that supports all these boards... We will be happy to accept such a patch

Questions:
1) Yes!

2) The board section is not mandatory at all. The idea is that if you have to control a pin or a peripheral (UART, ..) then it will go in MCU. But if you have the third led soldered on pin E4, then the wiring is really specific to the board you are using, and thus for the supported boards we inserted the board "concept"

3) I do not have a recipe for the MCU part... you can start just adding the peripherals/register you use...

4) About customizing the OIL file... As said, the AVR5 was one of the first portings done, and it needs for sure a refresh

Currently you can find all the OIL specification interpreted by RT-Druid in the "Active OIL Implementation" available on Window/Show View/Other/RT-Druid/Active OIl Implementation.

As Nicola said, you can start adding EE_OPT. when the work is done and committed, then we could add some OIL flavour to make the configuration simpler...

Btw, if we should restructure the AVR porting, the needed things should be various, and are in random order:
- porting the AVR5 COU port to the "common" infrastructure
- moving the MCU-specific things away of the CPU object (currently the IRQ Handlers and Timers are in the CPU...)
- using the IRQ templates used for other architectures also for AVR5
- adding the boards specific sections if needed
- documenting it on the Wiki...

I hope this clears out some of your doubts...

And... thanks for supporting ERIKA Enterprise!

and Finally... Happy New Year!

PJ

[raghu.ponuganti]

Hello Paolo and Hello Nicola,

Thank you very much for your continuous supports. I am sorry for the delay in my response, I was on vacation. I wish you a very happy new year.
As of now I do not have much update on this port. I will update you once I move further.
I have one question in this statement by Nicola

One note regarding interrupts: again, the support of avr5 was done a long time before the introduction of a new (and more generic) way to handle interrupts. This has two impacts, the first is that you have to set them inside the cpu section, the second is that the list of interrupts (and their simbols) is hard coded and may not be the same set provided by atmega328

Interrupts and their symbols are hard coded, does this mean I can not modify these things specific to Atmega328 ?

Please provide little more information on this.

Also I would like to you update you that there might be a delay in my response because of my semester exams :( .

Thank you.

regards
Raghavendra
http://www.raghu.co.nr

[paolo.gai]

Hi,

It means that each microcontroller way has its own "typical" way of handling the interrupt table. For example, Microchip put the IRQ function names in the linker scripts, whether other does nothing.

What we did in the past for AVR was to map the CPU interrupts directly in the OIL (there was no other way to do that, and we did not have yet the MCU part.

My suggestion is the following: We should restructure theAVR interrupt part giving a more "generic" way similar to what has been done for other microcontrollers such as PPC. The configuration files should come first. When we have a first draft of the configuration files, then we can draft the OIL part in a way that it generates the needed files.

In other words yes, the OIL file needs to be changed moving the IRQ handlers in the MCU part. But we'll do that only when there is an example (written by hand without OIL) working

Ciao,

PJ