Problem on Aurix Tricore startup

[acornagl]

Hi all,
I'm developing a scholastic multicore application for the Aurix Tricore processor but I have some trouble when I try to debug it with UDE debugger.

An autostart task is assigned for each CPU and the problem is that tasks start their execution before all StartOS methods are called and executed. It seems that system startup is not synchronized between cores.

In my configuration 'oil' file I declared CPU_DATA and MCU_DATA for Aurix Tricore and I defined three different CPU_DATA (like in example files). I found that for others architectures exists the following option: STARTUPSYNC = TRUE, can this declaration help me?

Did I get something wrong? May the debugger have some problems?

Thanks,
Alessandro

[e.guidieri]

Hi Alessandro.

I nerver worked with UDE debugger so I cannot give you precise instructions about it, but what you are telling sounds really weird to me. Which template have you started from?

AUTOSAR's Multicore (so ERIKA's Multicore) is based in a Master/Slave relationship so a slave core cannot start until the in the Master Core (or a slave core already started by the master core, and son on...) call the StartCore API. The StartCore API set up the synchronization the will happens inside StartOs...

The only thing I can immagine could happens is that the debugger would release all the cores in startup, not just the Master, messing up the syncronization. But even in this case no core should be hable to bypass the synchronizzation point inside StartOS and start the autostart scheduling.

There's one more thing that could happens, but for this to happens you should have done something unexpected in OIL file...

Temporarly, to let coexist the old PowerPc (e200zx) multicore startup, that do not implement syncronization, and single core startup with the AUTOSAR multicore synchronized startup, a Macro's combination is checked around the synchronizations point.

So check if in RT-Druid generated makefile and eecfg.h files the __MSRP__ macro is defined and EE_AS_MULTICORE_NO_SYNC in NOT defined

Regards,
Errico

[acornagl]

I'm working on TC277TU and oil configuration is TC27x.
Consider this simple setup:
Master core main:
- calls startCore for cores 1 and 2
- calls startOS
Cores 1 and 2 main:
- Simply calls startOS
In core 1 I defined a custom startupHook that, at the best of my knowledge, should be called by startOS after the first synchronization point (barrier among all cores).
If I try to debug this multi-core setup I get that after the first startCore in the Master's main (note: before both the second startCore and startOS) core 1 enters startupHook. What I expected, instead, was core 1 waiting for all other cores to reach the barrier. Am I wrong? Do you have any clue on this behavior?
I can attach my oil file but there's nothing strange in it.
Thank you for your time,

Alessandro

[paolo.gai]

Dear Alessandro,

the second core is STARTED from the first core after the first core initializes the barrier code.

If your debugger starts the second core BEFORE the first core arrived to barrier initialization, then the system will not work. Could you please check that?

Thanks,

Paolo

[e.guidieri]

To check it, comment the StartCore calls. If core1 start and Reach the StartOs+StartupHook, well the debugger is doing something wrong.

[acornagl]

Sorry, I forgot to tell it in my previous post. The cores are not automatically started by the debugger, they remain inactive if startCore is not called.

Thanks again,
Alessandro

[e.guidieri]

Another hypothesis it's that there's some issues in data initialization in boot code (did you needed to touch linker scripts and/or boot code to use the TC277TU)?

Could you check that EE_as_core_mask and EE_as_core_started values is 1 for both and not 0 at the begin of Master Core main?

Bye

[acornagl]

I applied no changes to the linker script or the boot code.

I checked and EE_as_core_mask and EE_as_core_started are 1 at the beginning of the master's main and are then incremented correctly after each startCore.
To add further details:
- On the master core startupHook is correctly called by startOS
- If I define any task in core 1 or 2 their code is executed before startOS
- On core 1 or 2, after the execution of startupHook or any task, startOS seems to be actually called but fails to correctly set the barrier. Barrier value sticks to 1 (as set by master's startOS)

Something weird is going on. I much appreciate any hint.

Best Regards,
Alessandro

[e.guidieri]

What you are saying sounds as demoniac possession of your board to me...

- On the master core startupHook is correctly called by startOS

This is in contraxt for what you'are sayng after, StartupHook cannot be called before all the cores call StartOs

- If I define any task in core 1 or 2 their code is executed before startOS

Are you activating core1 and core2 task on core0, maybe before calling StartOs in that core?
Otherwise is not even theorically possible that TASK could execute before StartOs... Do you have any ISR configured?

- On core 1 or 2, after the execution of startupHook or any task, startOS seems to be actually called but fails to correctly set the barrier. Barrier value sticks to 1 (as set by master's startOS)

Which variable are you checking?

Best Regards,
Alessandro[/quote][/quote]

[acornagl]

Thanks for your precious and timely support but it seems that the problem is due to UDE debugger. It is not able to flash Pflash1 partition in PMU0, therefore what I saw in my tests was something meaningless.

When I request execution from RAM in configuration oil file all seems to be ok!

I will examine why UDE debugger can't flash Pflash1 (dedicated memory for core 1 and 2).

I have one more question: I'm not sure how StartupHook works in multicore. Is it possible to execute the StartupHook once for each core?

Best regards,
Alessandro

[e.guidieri]

I have one more question: I'm not sure how StartupHook works in multicore. Is it possible to execute the StartupHook once for each core?

It's already and always like that, check the code of the project template

tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test.

Errico