TC297 CPU1 Lockstep injection Test, register set failed

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

cross mob
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Hi,
I am new user of TC297 and I want to integrate lockstep function into my application. But when I want to test the lockstep injection, I met a problem.
According to user manual, I can write SCU_LCLTEST.LCLT1 to trigger lockstep error, then I set register just like below:

IfxScuWdt_clearSafetyEndinit(IfxScuWdt_getSafetyWatchdogPasswordInline()); /* Clear Safety WDG Endinit. */
SCU_LCLTEST.B.LCLT1 = 1; /* Fault Injection, failed!!! */
IfxScuWdt_setSafetyEndinit(IfxScuWdt_getSafetyWatchdogPasswordInline()); /* Set Safety WDG Endinit */


I debugged my codes, and all of these lines reached, but register SCU_LCLTEST cannot be set successfully.
Whether I missing anything? Or how should I write my code for SCU_LCLTEST register writing.

Thank you~~
0 Likes
15 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
If you look at table 7-28, the register overview table for the SCU, you can see that the register is marked "P", which means it is access protected. Please check your SCU_ACCEN0 register to see if the tag of the master you are using to access the register is in fact allowed to write to it.

Please also check the error capture registers in the XBAR if this is not the issue, as the additional information captured if the write is causing a bus error may help to debug it further.
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Darren Galpin wrote:
If you look at table 7-28, the register overview table for the SCU, you can see that the register is marked "P", which means it is access protected. Please check your SCU_ACCEN0 register to see if the tag of the master you are using to access the register is in fact allowed to write to it.

Please also check the error capture registers in the XBAR if this is not the issue, as the additional information captured if the write is causing a bus error may help to debug it further.

Thanks so much for your answer!
I have read the SCU_ACCEN0 register content in user manual, all of the bits for enable or disable. But how can I know the bit mapping for every bit in it? Means which bit mapping to which register access for which bus master(CPUs)?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hi Jevins. The bus master IDs are listed in Table 2-15 On Chip Bus Master TAG Assignments on page 220 of tc29xB_um_v1.3.pdf.

As an example: if your code is running on CPU0, and PSW.S=0, it's using tag ID 0. (DMI.NonSafe TAG ID).

Another reason your code might not be working is if you haven't enabled the lockstep in the Boot Mode Header. Check whether SCU_LCLCON1.LSEN=1. If it's not, change your boot mode header so that BMI.LCL1LSEN=1 (see BMI on page 254).
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
UC_wrangler wrote:
Hi Jevins. The bus master IDs are listed in Table 2-15 On Chip Bus Master TAG Assignments on page 220 of tc29xB_um_v1.3.pdf.

As an example: if your code is running on CPU0, and PSW.S=0, it's using tag ID 0. (DMI.NonSafe TAG ID).

Another reason your code might not be working is if you haven't enabled the lockstep in the Boot Mode Header. Check whether SCU_LCLCON1.LSEN=1. If it's not, change your boot mode header so that BMI.LCL1LSEN=1 (see BMI on page 254).


I confirm that I have enable the Lockstep function successfully, due to I have seen both LS and LSEN are set. Only thing I cannot confirm is the access right. I will try to set the ACCEN register according to your guidence.
Thank you~
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
UC_wrangler wrote:
Hi Jevins. The bus master IDs are listed in Table 2-15 On Chip Bus Master TAG Assignments on page 220 of tc29xB_um_v1.3.pdf.

As an example: if your code is running on CPU0, and PSW.S=0, it's using tag ID 0. (DMI.NonSafe TAG ID).

Another reason your code might not be working is if you haven't enabled the lockstep in the Boot Mode Header. Check whether SCU_LCLCON1.LSEN=1. If it's not, change your boot mode header so that BMI.LCL1LSEN=1 (see BMI on page 254).


Hi,
I read the related chapter in user manual, and set both PSW.S and PSW.PRS to 1, set PSW.IO to 2(supervisor mode), but it still cannot work. (this step finished in CPU1)
Then, now, I don't know what should I do to enable CPU1 as bus master? Means which register I should set with Table 2-15 values?
Thank you~
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Jevins - the simplest solution is to set SCU_ACCEN0 and SCU_ACCEN1 to all 1's, which enables all tag values, so will allow all CPUs to do the write. You can then restrict it back for production afterwards,
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Darren Galpin wrote:
Hi Jevins - the simplest solution is to set SCU_ACCEN0 and SCU_ACCEN1 to all 1's, which enables all tag values, so will allow all CPUs to do the write. You can then restrict it back for production afterwards,


Now, all bits in SCU_ACCEN0 are 1, and SCU_ACCEN0 is reserved, so all bits in it are 0. But lockstep injection still cannot work.:(
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Jevins - ok, so that would seem to indicate that there was not an access protection issue. Perhaps the next step is to see whether the register access was errored in the system, i.e. did one actually go out into the interconnect. Please could you look at the error capture/status registers in SRI XBAR0, and the SPB BCU. These will show whether a transaction generated a bus error, and give details about that transaction. We can then check whether the access has anything else incorrect.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
One further question - how do you know that the LCLTEST.LCLT1 bit writing has failed? Note that if you write 1 to it, you can never read back 1 - it always reads 0. You only know that the write happened correctly because a fault was injected into the next valid transaction affected.
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Darren Galpin wrote:
Hi Jevins - ok, so that would seem to indicate that there was not an access protection issue. Perhaps the next step is to see whether the register access was errored in the system, i.e. did one actually go out into the interconnect. Please could you look at the error capture/status registers in SRI XBAR0, and the SPB BCU. These will show whether a transaction generated a bus error, and give details about that transaction. We can then check whether the access has anything else incorrect.


Hi Darren, I debugged my source code ,and found that there are 2 XBAR_ERR register have error information, see picture below for detail:
4540.attach
I don't know you means these register or not?
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Darren Galpin wrote:
One further question - how do you know that the LCLTEST.LCLT1 bit writing has failed? Note that if you write 1 to it, you can never read back 1 - it always reads 0. You only know that the write happened correctly because a fault was injected into the next valid transaction affected.

I set a breakpoint at line 45 and running one step, then view the value of SCU_LCLTEST register, LCLT1 bit value is 0 at this time. Just like below:
4541.attach
Register value window just like below:
4542.attach
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Jevins - the debugger is seeing the correct behaviour. The bits is write only, always read as 0, hence although you wrote in 1, the register won't store 1 and is always read as 0.

Your two ERR registers are showing that there were two different register reads which generated errors - you also need to take a look at the ERRADDRx register to find the address of the transaction which generated the error. However, it was a read in both cases, not a write - so either an earlier read errored (the capture registers only store the first error), or the write to the LCLTEST didn't in fact error and a later read did.
0 Likes
User19859
Level 1
Level 1
10 replies posted 5 replies posted First question asked
Darren Galpin wrote:
Hi Jevins - the debugger is seeing the correct behaviour. The bits is write only, always read as 0, hence although you wrote in 1, the register won't store 1 and is always read as 0.

Your two ERR registers are showing that there were two different register reads which generated errors - you also need to take a look at the ERRADDRx register to find the address of the transaction which generated the error. However, it was a read in both cases, not a write - so either an earlier read errored (the capture registers only store the first error), or the write to the LCLTEST didn't in fact error and a later read did.


Hi Darren,
you are right. The lockstep fault has been injected successfully. I cannot get the lockstep error alarm just because of I fill an error parameter "IfxSmu_Alarm_Cpu0LockstepComparatorError" in SMU interface.
And in TC297, only CPU1 has lockstep function. Now I can get CPU1 lockstep error alarm interrupt from SMU module.
But, a new phenomenon occurs. It looks like that the lockstep error injection cause my system reset.

Another thing, about the XBAR ERR register. I tried the "Blinky_LED_1_KIT_TC297_TFT" demo project which from Infineon official website on the TFT board which also come from Infineon official side. I can also get these 2 errors in XBAR_ERR6 and XBAR_ERR7 register.
The error information please check following pictures:
4543.attach4544.attach
Can you help to test the demo project on your side?
Thank you so much for your support~~
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
So in ERRADDR6, there was an error reading the BootROM (using a BTR4 (opc=9)), and in ERRADDR7 an error reading PFlash0 with an SDTW (opc=2). Currently can't tell you more than that...…

I don't have access to the boards - not my area of expertise. Maybe there is someone else around here who can chip in?
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
What are the values of INTSAT and IDINTSAT?
The content of ERRADDRx and ERRx are set before to this values?
0 Likes