Aug 03, 2020
12:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
12:16 AM
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~~
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~~
15 Replies
Aug 03, 2020
12:59 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
12:59 AM
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.
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.
Aug 03, 2020
05:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
05:41 AM
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)?
Aug 03, 2020
06:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
06:03 AM
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).
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).
Aug 03, 2020
08:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
08:09 AM
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~
Aug 03, 2020
07:13 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2020
07:13 PM
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~
Aug 04, 2020
01:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
01:05 AM
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,
Aug 04, 2020
01:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
01:10 AM
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.:(
Aug 04, 2020
01:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
01:50 AM
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.
Aug 04, 2020
01:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
01:55 AM
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.
Aug 04, 2020
02:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
02:38 AM
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:
I don't know you means these register or not?
Aug 04, 2020
02:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
02:55 AM
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:
Register value window just like below:
Aug 04, 2020
03:42 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
03:42 AM
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.
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.
Aug 04, 2020
06:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
06:10 AM
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:
Can you help to test the demo project on your side?
Thank you so much for your support~~
Aug 04, 2020
06:32 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2020
06:32 AM
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?
I don't have access to the boards - not my area of expertise. Maybe there is someone else around here who can chip in?
Aug 13, 2020
01:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 13, 2020
01:08 AM
What are the values of INTSAT and IDINTSAT?
The content of ERRADDRx and ERRx are set before to this values?
The content of ERRADDRx and ERRx are set before to this values?