Porting Erika to Arm Cortex R4

[prosith]

Hey

I want to port Erika for a TI TMS570 (Arm Cortex R4) and I am having problems with the Xslt - Transformations.
According to the RT-Droid-Oil-XSLT Tutorial i created a Transformation file. It works in general, but the code for the
Makefile is generated at the beginning of the Makefile - I need to have it behind the Erika path part, where I want to set the Compilerpath (Code Composer Studio).
How can I add code at the ending of the Makefile via the xslt file?

Regards, Chris

[paolo.gai]

Hi!

This is very interesting!

About the XSLT: I'll ask Nicola to give you help, but please post some snippet of code to better highlight the problem you are having...

Thanks!

PJ

[prosith]

Here are the two makefiles and the Xsl Transformation file:
One is from a Cortex M4 example, where the Compilerpath is set at the ending.
In the XSLT Transformed Version, the Compilerpath is either not set, or overwritten -
I am trying to find out why its not working.
If i move

Code: Select all

-include $(EEBASE)/pkg/cfg/path_helper.mk
APPBASE := ..
OUTBASE := Debug
$(eval $(call check_and_set_cygwin_compiler_path,CCS_INSTALL_ROOT,C:\Program Files (x86)\Texas Instruments\ccsv4))

at the ending of the file it works..

Regards Chris

[prosith]

Update:

I found my mistake!
The include needs the Erika path $(EEBASE) which is not set yet.

Code: Select all

-include $(EEBASE)/pkg/cfg/path_helper.mk
APPBASE := ..
OUTBASE := Debug
$(eval $(call check_and_set_cygwin_compiler_path,CCS_INSTALL_ROOT,C:\Program Files (x86)\Texas Instruments\ccsv4))

If i directly add

Code: Select all

CCS_INSTALL_ROOT := C:\Program Files (x86)\Texas Instruments\ccsv4

instead, it works.

I still wonder if it is possible to add some code after the Erika Path definitions?

Regards, Chris

[paolo.gai]

Good you solved it... Nicola typically reads the forum e-mail late evening.

Aboy the other question, we'll let you know soon!

Btw, are you going to release the patch publicly? If you want we can package it after the 2.3.0 release planned these days...

PJ

[nicola.serreli]

Hi,

I just updated the wiki page.

The execution of all writers (including xslt ones) is ordered using two properties.
The first one is the generation phase, then, writers with the same phase, are ordered by priority.
Writers with the same phase and priority are not sorted (the first loaded by eclipse framework is the first executed).

I committed two small changes in RT-Druid:
- allow to specify the END phase in the plugin.xml
- change the Makefile generator priority. It was MaxInteger, now is 1.000.000

So, if you want to generate your code at the end of the makefile, you can set the phase value to END or use a priority greater than 1.000.000 (note this last will work only with the next build).

But, at this moment, it is not possible to to add some code after the Erika path definition and before the include of $(EEBASE)/pkg/cfg/rules.mk

Let me know if it solve (or not) your problem.
Best regards,
Nicola

[prosith]

Thank you!

Ill set the CCS_INSTALL_ROOT as i wrote, for i cant use the path_helper.mk.
I cant find how the path was set in the java writer, should I set the path already in
the conf.oil? or can i read it in the xslt writer?

@PJ I will release it if I get it working ;)
But Im afraid that wont be in a few days..

Regards, Chris

[paolo.gai]

Ciao!

No problem for the timings... when you have something to share just send it to us and we'll integrate it...

PJ

[nicola.serreli]

Hi,

the compiler path is set through the common_oil.pref or using the eclipse settings GUI
(see http://erika.tuxfamily.org/wiki/index.p ... iler_paths)

Another limitation of xslt transformation is that there is no way to retrive that value during the transformation. The only values available to the xslt are the ones contained in the oil file.

note that for some compilers there is a default path.

Nicola

[prosith]

Hi

I am still trying to port Erika to a Cortex R4 and have some difficulties concerning context changes.
I am using the Cortex M4 as template but the vectored interrupt controller of the M4 does a lot, concerning register save and restore, the R4 simply isn't able to.
So i would appreciate it, if someone could give me some hints on how to implement the interrupt stub with the context change implementation :)
I am currently trying to use the AVR8 files as a template, but they differ a little bit.. ;) Are there other ressources that could help me?

BTW the monostack examples EEtest0-EEtest4 are running fine already.

My main questions are:
Where does the M4 save the old Task before changing to the new one?
The R4 has an own IRQ stack, which the M4 doesnt have - Is this already meaning that a multistack implementation is necessary?
When and where are the Stackframes for the Tasks created? I cannot find it in the M4 implementation. - If I understand it right,
the context change function creates a new frame for the new Task with a different Programcounter and Linkregister to jump back and then deletes the frame.
Is it necessary to port counter/timer functions too? Is Erika using them?

Best Regards, Chris

[paolo.gai]

Hi, I did not look at the cortex R4 in detail.

If it does not save all the context as done in the M4, but it is mor similar to a "traditional" microcontroller, then you probably could look at how the context change is implemented in simpler microcontrollers, like mico32 (if I remember well is relatively simple, and in general to the "common" subdirectory which should contain some information on how to perform the porting.

About your questions:

So i would appreciate it, if someone could give me some hints on how to implement the interrupt stub with the context change implementation :)
I am currently trying to use the AVR8 files as a template, but they differ a little bit.. ;) Are there other ressources that could help me?

look at the other CPU implementations. in general start from a simple one without too much assembler. the Cortex-M4 does not help, maybe MICO32 could be better

BTW the monostack examples EEtest0-EEtest4 are running fine already.

those have the interrupts... or I'm recalling wrong?

Where does the M4 save the old Task before changing to the new one?

typically by saving registers on the stack, this is done by function calls or by the IRQ stub for callee/caller saved registers

The R4 has an own IRQ stack, which the M4 doesnt have - Is this already meaning that a multistack implementation is necessary?

no... you can still have a single stack for all threads

When and where are the Stackframes for the Tasks created? I cannot find it in the M4 implementation. - If I understand it right,
the context change function creates a new frame for the new Task with a different Programcounter and Linkregister to jump back and then deletes the frame.
Is it necessary to port counter/timer functions too? Is Erika using them?

they are created in what initially was called the "ready2stacked" function (now it has a different name). look in the "common" CPU implementation when a new task is activated. I suggest you to follow the execution of the ActivateTask with the debugger to better understand.

I hope it helps...

Ciao,

PJ

[chris.kreuzberger]

I finally got the monostack version working on the Cortex R4.
The problem was, that the CPU saves and hides the linkregister and stackpointer from the systemmode
when changing into interruptmode to handle the ISR.
Now the whole program runs in systemmode.

Is Erika using different modes like user/system/svc/irq mode in any controller?
The purpose is that a Task cannot change settings like enable or disable interrupts.

Thank you for the help
Best regards,
Chris (formerly prosith)

i will upload my code to the SVN the next few days

[e.guidieri]

Is Erika using different modes like user/system/svc/irq mode in any controller?
The purpose is that a Task cannot change settings like enable or disable interrupts.

Yes, but only in TriCore with full AUTOSAR Memory/Service Protection Enabled*. Normally all porting runs in "supervisor mode", without any restrictions.


*Neither the original, now obsolete, ERIKA's PowerPC Memory Protection implementation supported partion between "supervisor" and "user" modes

[paolo.gai]

I suggest to start in supervisor mode only.

I did not look yet at the R4, but the hiding of the LR and PC seems similar to what was once upon a time the ATM7TDMI architecture. The code should still be in the repository for ARM7.

PJ