ERIKA Enterprise Forums

Whole File ${ERIKA_FILES}/pkg/mcu/infineon_common_tc2Yx/src/ee_tc2Yx_system.c /* ###*B*### * ERIKA Enterprise - a tiny RTOS for small microcontrollers * * Copyright (C) 2002-2012 Evidence Srl * * This file is part of ERIKA Enterprise. * * ERIKA Enterprise is free software; you can redistribute it * ...

The only thing that can happen is that, from some reason, maybe for other interrupts or critical sections, the next tick comparison is evaluated in the past; this is a problem in common with all the upper counting system timers, the best you could do, without complicate too much the tick handling co...

The best will just remove the resource from ISR2 and handle mutual exclusion in the ISR with less priority, with Suspend/Resume OsInterrupts. Let me know

Could you try to use the Suspend/Resume AllInterrupts primitives, instead of Get/Release Resource (or just remove ISR2 as you said even though I don't understand how you will handle CAN...). If the behaviour change and after the change and everything will working it could menas that the problem is i...

As you said I think that the reason for the behaviour you observe is tied to the use of the resource, but you are looking at the wrong side. From your OIL I see that TaskERSIn and TaskERSOut TASKs use the CAN resourse. these means, because immediate priority ceiling protocol, that the priority of th...

The code fix has been committed, so you could update your repository working copy and test it. If you have local modifications and don't want to risk conflits this is the patch: --- a/pkg/kernel/oo/inc/ee_oo_common.h +++ b/pkg/kernel/oo/inc/ee_oo_common.h @@ -449,11 +449,11 @@ extern EE_UREG EE_reso...

Could you please copy and paste your OIL too? I have an idea for what it's going on, I think its tied to the fact that you are using Spinlocks with resorces shared with ISR2 (I suspect that there is not a automatic test with this scenario), but still there's things that I do not understand, as EE_MA...

That MCU that you are using it's not officially suupported so there could be some issues like that. Which Borad are you using? If it is APPKIT_TC2X5 you need to define in your OIL. EE_OPT = "EE_APPKIT_TC2X5"; and remove BOARD_DATA = TRIBOARD_TC2X5; In any case instead of elimate the code you said (t...

Using a lock time budget would be better, but in this way you got a tricky behaviour, because the system shall behave as you said.

Try this patch (provided as the one before).

Errico

The solution implemented cannot handle a wrap around of the timer inside a critical section, so you have to assure that the lenght of your test do not exceed that amount of time (that for tricore is 31 bit at your clock frequence). You can use EE_tc2Yx_delay function to generete your delay in contro...

OK, we try this way.

I had to rename .zip the file because some forum policies, but actually is a .c file

Try this and let me know. I'm still using git diff to create the patch because I don't want commit (even locally), if I'm not sure that everything is working. Bye diff --git a/pkg/kernel/as/src/ee_as_mem_prot.c b/pkg/kernel/as/src/ee_as_mem_prot.c index 92397c4..d82bdee 100644 --- a/pkg/kernel/as/sr...

Yes the requirement should be supported, and If the exception really happens after seconds the problem can be only in the return from a Interarrival frame recollection procedure, that's the only event that has that periodicity. Interarrival frame recollection it's tied to a core exception (shared wi...

Yup, that was exactly the problem (sorry, bug happens). And sorry for the patch, I didn't understood how to generate patch with git yet... I'm gonna to commit on the repository, but to use the head of the repository you will need to upgrade RT-Druid with an update site (and I'm not sure if it is alr...

Hi, I could replicate the problem seems tied to the driver of system timer that in some particular situation can raise more interrupts than you would expect (Infineon STM perpherial it is really complicated to be easiest timer that they have ^^). Could you please test this patch too in your environm...