Interarrival Time Protection (AURIX)

[e.guidieri]

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 controlled way.

Errico

[AlTi]

Ok, tested it with 1s and it worked as expected.

Thank you for your support.

[AlTi]

I have another question about the execution timing protection (I use this thread, if it´s no problem): I configured a task with a execution budget (1ms) and inside the task following code is executed:

Code: Select all

	DisableAllInterrupts();
	EE_tc2Yx_delay(1000000); //1s
	EnableAllInterrupts();

ProtectionHook is called after 1s, that means the error is delayed. Is there a reason to delay the error in this case? With the delayed error I have to use "Lock Time" as well if I want to detect the error within a specific time.

Best regards

[e.guidieri]

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

[AlTi]

Thanks,

the patch worked. This time I got the error immediately after the execution budget expired.

Best regards

[AlTi]

Hi again,

I want to share another user experience I have gained with the timing protection and that might be interesting for you.

In the current implementation, the "CPU Clock Count Register", which is part of the "Core Debug Controller", is used as free running timer. This timer is only running, when a debugger is connected (or let´s say, I have not found a way to activate this timer when the debugger is disconnected). This leads to the unpleasant behavior, that the timing protection will signal an error very fast, if the debugger is disconnected.

Therefore, I am currently using the STM as free running timer. To be compatible with the rest of the implementation, the STM must run at the frequency of the cpu (luckily, ERIKA´s startup code configures the STM that way by default).

Best regards,
Alex

[e.guidieri]

Hi,

in fact i cannot find neither a way to enable by software OCDS (setting DBGSR.DE, the bit is declared as "rh" bit read and hardware set) neither, I found in RM that only micro-boot code set the bit if the debug probing/handshaking protocol succeed.

This surprised me since in the OCDS, enabled by the same bit, in addition to CCNT and breakpoints traps, there are performance counters, that would be really useful even in normal execution, for example to implement an adaptative scheduler for a soft-realtime application (even CCNT would be really helpfulf since could be used ad SWFRT as I did :) ).
It should be asked to infineon if REALLY there is no MCU register (maybe somenthing SCU) that externally from the CPU, can force DBGSR.DE bit to 1, but, since they do never answered to one of may question I won't bother, if you have better contacts than mine it would worth give a try.

The problem to use SMT as SWFRT is that all the clocks peripherals (everithing attacched to SPB...) have a clock that is, at maximum, half of the CPU, and since TPS counters run with CPU frequency, this complicate the handling a little. It's for the reason, and because I would have loved to implement TP with only CPU features, that I configured and used CCNT.

I would try to implement the SWFRT using SMT, but I need you for testing since I cattot access to tricore board right now.

Errico

[AlTi]

Hi,

I don´t see a major problem using the STM. I already have a first and easy implementation which simply replaces the CCNT against the STM. This simple replacement works, because the STM runs at CPU frequency per default (f_stm is not derived from f_spb; instead, it can be configured relatively independent). Of course, the danger exists with this simple replacement, that f_stm differs from f_cpu and in this case, the calculation of "time to ticks" would be incorrect. Therefore, it would make sense to use directly f_stm in the "time to tick"-calculation, which I think is what you have planned. Alternatively, one could add checks to assure that the STM runs at CPU frequency.

Below, you can find the files that I have changed. Maybe, you want to use it as base for your implementation. I think, my implementation is sufficient for my use case, but I would be happy, if you can look over the changes to detect potential side effect that I have not seen.

I could do some tests, but I don´t know the test cases that you need. I already have tested if the inter-arrival time protection triggers an error if a task is activated too early.

Best regards,
Alex