ERIKA Enterprise Forums

Hi,

I'm using a global resource in two tasks, assigned to two different cores (TriCore Tc27x). In the OIL file the OS object has the following attributes (among others):
I also defined a RESOURCE object using it as a global mutex and assigned it to a task on the master and slave core.

Now generating the ErikaOS config files with RT_Druid ends up with the following error: "com.eu.evidence.rtdruid.internal.modules.oil.exceptions.OilCodeWriterException: Global resources are not allowed"
The oscfg make works fine with the attribute "SPINLOCKS = QUEUED" disabled, i.e. using the trivial implementation.
Is this a bug in ErikaOS or do I do something wrong using the resource as a global mutex.

regards,
a.wall

Hi,

I´m using a TriCore TC27x in a multicore configuration, too. Global resources aren´t available in ERIKA Autosar OS with the RPC implementation (please read in http://erika.tuxfamily.org/wiki/index.p ... ementation for more information).

The intended mechanism for mutual exclusion between different cores is the spinlock mechanism. Therefore, just replace your global resource with a spinlock.

I hope, this helps.

Yes, correct. Note that the "original" implementation with the "global resources" that i did in 2002 is still available on the Nios II port in the wiki.

Unfortunately it is somehow not easy to port the global resources and the queuing spin-locks to the AUTOSAR OS implementation, because:
- AUTOSAR has its own spinlocks, so no global resources...
- queuing spin-locks are out of the AUTOSAR OS standard, and in any case the G-T implementation I used is not much applicable because when an OS Application terminates all threads doing a spin-lock must be stopped... which is not implementable in an easy way with G-T.

G-T --> G. Graunke and S. Thakkar, Synchronization algorithms for shared memory multiprocessors. IEEE Computer, 23(6):60-69, June 1990

Ciao,

PJ

Thank you for your anwers.

Now, using Spinlocks I've got another problem, which I believe might be a bug in the OS. As long as I had code with only a view spinlocks declared in the oil file everything worked well.
As soon as I declared more spinlocks than the sum of tasks and ISR2 on one core, I noticed impermissible writes to some completely different variables linked next to the following array declared in eecfg.c.
In my code I've declared 8 tasks and one ISR2 for core 0 and 23 spinlocks. Hence, this array has a size of 9 in my example.
In ee_as_spinlocks.c I found this line of code
When I try to lock the spinlock with SpinlockId=11 I have very unexpected behavior of the OS.

Is there an intended restriction on the amount of spinlocks or is this a bug?

thanks,
AW

Sorry to say but... bug.

The array should have the dimension of the spinlocks and not of the tasks. We are going to fix both the code and the RT-Druid configurator.

PJ

great!

when can I expect a new release with this bugfix?

We are rather busy in the latest days, but we'll try in 1-2 weeks time.

PJ

One possible workaround for now:
1- adding dummy tasks in the system. in this way, the array will become bigger and you'll not have that problem
2- generate the code, then hand-modify the generated code, then disable the OIL generator and build again to compile again the system without recompiling the OIL file.

PJ

Hello,

the last nightly build contains the fix.

You can update your installation using the update site: http://www.evidence.eu.com/erika-builds ... uid_250_nb

best regards,
Nicola