TC29X CPU_TC.123 errata

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Darq
Level 1
Level 1
First reply posted First question asked Welcome!
Hello, In errata document for TC29X there is a functional deviation as below: CPU_TC.123 Data Corruption possible when CPU GPR accesses made via SRI slave with CPU running Data corruption may occur when another master accesses a TriCore CPU’s General Purpose Registers (GPRs) via its SRI slave port whilst the CPU is running (i.e. not Idle, Halted or Suspended). The TriCore GPRs are A0-A15 and D0-D15. The scenarios in which data corruption may occur are different for the TC1.6P and TC1.6E processors as described below. TC1.6P - Data corruption may occur when one of the CPU GPRs is written via the SRI slave port whilst the CPU is running. Both AGPR and DGPR writes may be affected. Workaround Writes to a CPU’s GPRs via its SRI slave port must never be performed whilst the CPU is running. If it is necessary for an external master to write to a CPU’s GPR then that CPU must first be placed in Idle, Halt or Suspend mode. Can someone explain in more understandable language and provide some examples? How is writing to core registers possible from a slave port? Is it happening for example when one core is trying to write to another core registers? Is that even possible? Best regards
0 Likes
1 Solution
David_R
Moderator
Moderator
Moderator
100 replies posted 25 solutions authored 10 likes given

Hello  @Darq

What it says basically is the same as you state, 

It may be data corruption if a CPU tries to write another core's GPRS using the SRI bus, to answer you question, if you take a look at the arch of Aurix TC2xx

David_R_0-1706042959071.png

The SRI bus enable the communication between cores, so yes, it's possible to exchange data between cores, as the document remarks, this issues occurs when a specific store instructions is used, according to the instruction set manual

ST.A
Store Word from Address Register

As the Aurix is a RISC system, we just have one store word from address instruction, otherwise we could control the write thru asm, so to try to avoid this issue we have at least two options

1.- Use the workaround, this could be achieve thru a function that put into a no running state the CPU then write the data and getting back the CPU.

2.- Do not write to another core's GPR, in other words, just use one core.

Generally speaking the workaround is used when you're facing  the problem, so once you know that the reason is not firmware nor hardware, then the errata could contain the reason and the solution, but not before, so i'm afraid i cannot give you an example.

Regards! :1

View solution in original post

0 Likes
3 Replies
David_R
Moderator
Moderator
Moderator
100 replies posted 25 solutions authored 10 likes given

Hi @Darq 

Could you please be so kind of put the link of the document, so the workaround did not help you? what are you trying to achieve?, if you please could provide more information it'll be very helpful.

Regards! :1

0 Likes
Darq
Level 1
Level 1
First reply posted First question asked Welcome!

Hello,

Link to the errata:
https://www.infineon.com/dgdl/Infineon-TC29x_BC-step-ErrataSheet-v01_05-EN.pdf?fileId=5546d46269bda8...

First of all, i'm trying to make sure that the errata deviations related to CPU are covered in our software. Since i don't understand what this specific deviation is describing, i need some clarification. The workaround doesn't help without understanding the issue and when it should be applied.
For TC1.6P does it describe a situation when one master (eg. Core 0) tries to write the data to AGPR or DGPR of another master (eg. Core 1)? Is that even possible? How this deviation can be confirmed to be addressed without reviewing all of the compiled assembly code?

Best regards

0 Likes
David_R
Moderator
Moderator
Moderator
100 replies posted 25 solutions authored 10 likes given

Hello  @Darq

What it says basically is the same as you state, 

It may be data corruption if a CPU tries to write another core's GPRS using the SRI bus, to answer you question, if you take a look at the arch of Aurix TC2xx

David_R_0-1706042959071.png

The SRI bus enable the communication between cores, so yes, it's possible to exchange data between cores, as the document remarks, this issues occurs when a specific store instructions is used, according to the instruction set manual

ST.A
Store Word from Address Register

As the Aurix is a RISC system, we just have one store word from address instruction, otherwise we could control the write thru asm, so to try to avoid this issue we have at least two options

1.- Use the workaround, this could be achieve thru a function that put into a no running state the CPU then write the data and getting back the CPU.

2.- Do not write to another core's GPR, in other words, just use one core.

Generally speaking the workaround is used when you're facing  the problem, so once you know that the reason is not firmware nor hardware, then the errata could contain the reason and the solution, but not before, so i'm afraid i cannot give you an example.

Regards! :1

0 Likes