Attachments are accessible only for community members.
Aug 03, 2021
06:58 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 03, 2021
06:58 PM
Hi all,
This is Rocky,
I am testing the TC234 board.
I am trying to enable the CPU lockstep function.
Then, I tried to modify the code
To
const uint32 BootModeHeader_0[] = {
0x80000020u, /* STADBM first user code at 0x8000 0020h */
0xb3590170u, /* BMI = 0170h BMHDID = B359h */
0x00000000u, /* ChkStart */
0x00000000u, /* ChkEnd */
0x00000000u, /* CRCrange */
0x00000000u, /* !CRCrange */
0x791eb864u, /* CRChead */
0x86e1479bu /* !CRChead */
};
Is it enough to enable the lockstep function?
In addition, for the other parameter such as the ChkStart, CRCrange and CRChead, are they required to define value in order to enable the lockstep function? and how to define those values?
Thank you for your reading, looking forward to discussing with you.
Best regards,
Rocky
This is Rocky,
I am testing the TC234 board.
I am trying to enable the CPU lockstep function.
Then, I tried to modify the code
To
const uint32 BootModeHeader_0[] = {
0x80000020u, /* STADBM first user code at 0x8000 0020h */
0xb3590170u, /* BMI = 0170h BMHDID = B359h */
0x00000000u, /* ChkStart */
0x00000000u, /* ChkEnd */
0x00000000u, /* CRCrange */
0x00000000u, /* !CRCrange */
0x791eb864u, /* CRChead */
0x86e1479bu /* !CRChead */
};
Is it enough to enable the lockstep function?
In addition, for the other parameter such as the ChkStart, CRCrange and CRChead, are they required to define value in order to enable the lockstep function? and how to define those values?
Thank you for your reading, looking forward to discussing with you.
Best regards,
Rocky
Solved! Go to Solution.
1 Solution
Aug 09, 2021
09:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2021
09:14 AM
ChkStart/End and CRCrange are only required for alternate boot mode headers, where the BootROM checks a defined range of PFLASH before jumping to it.
CRChead is the CRC-32 of the first 24 bytes of the structure, while !CRChead is the inverse (xor 0xFFFFFFFF).
Here's a quick link to a calculator that might help, with data from the structure above:
https://crccalc.com/?crc=a0000020b359017000000000000000000000000000000000&method=crc32&datatype=hex&...
CRChead is the CRC-32 of the first 24 bytes of the structure, while !CRChead is the inverse (xor 0xFFFFFFFF).
Here's a quick link to a calculator that might help, with data from the structure above:
https://crccalc.com/?crc=a0000020b359017000000000000000000000000000000000&method=crc32&datatype=hex&...
8 Replies
Aug 04, 2021
03:23 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2021
03:23 AM
You must recalculate CRChead and !CRChead for your new values used.
Aug 04, 2021
08:53 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2021
08:53 PM
Hi MoD,
Thank you for your reply.
I search the CRChead and !CRChead in the datasheet; CRC calculation is based on IEEE 802.3, the CRC32 ethernet polynomial used is (04C11DB71)h.
CRChead means "Check Result for the ABM Header (offset 00H..17H)"
Is this meaning that to check the CRC of the value shown below? If yes, how to calculate these values? Any material will be required for this calculation?
0x80000020u, /* STADBM first user code at 0x8000 0020h */
0xb3590170u, /* BMI = 0170h BMHDID = B359h */
0x00000000u, /* ChkStart */
0x00000000u, /* ChkEnd */
0x00000000u, /* CRCrange */
0x00000000u, /* !CRCrange */
!CRChead means "Inverted Check Result for the ABM Header"
Is this meaning that inverted value of CRChead?
Thank you for your reading.
Thank you for your reply.
I search the CRChead and !CRChead in the datasheet; CRC calculation is based on IEEE 802.3, the CRC32 ethernet polynomial used is (04C11DB71)h.
CRChead means "Check Result for the ABM Header (offset 00H..17H)"
Is this meaning that to check the CRC of the value shown below? If yes, how to calculate these values? Any material will be required for this calculation?
0x80000020u, /* STADBM first user code at 0x8000 0020h */
0xb3590170u, /* BMI = 0170h BMHDID = B359h */
0x00000000u, /* ChkStart */
0x00000000u, /* ChkEnd */
0x00000000u, /* CRCrange */
0x00000000u, /* !CRCrange */
!CRChead means "Inverted Check Result for the ABM Header"
Is this meaning that inverted value of CRChead?
Thank you for your reading.
Aug 05, 2021
09:49 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 05, 2021
09:49 AM
When BMI.HWCFG=internal start from flash, the start address is fixed at 0xA0000020.
This is probably what you're after:
This is probably what you're after:
const uint32 BootModeHeader_0[] = {
0xA0000020u, /**< \brief 0x000: .stad: User Code start address*/
0xB3590170u, /**< \brief 0x004: .bmhdid: Boot Mode Header ID (CODE) = B359H*/
0x00000000u, /**< \brief 0x008: ChkStart */
0x00000000u, /**< \brief 0x00C: ChkEnd */
0x00000000u, /**< \brief 0x010: CRCrange */
0x00000000u, /**< \brief 0x014: !CRCrange */
0xB2EB204Du, /**< \brief 0x018: CRChead */
0x4D14DFB2u, /**< \brief 0x01C: !CRChead*/
};
Aug 08, 2021
07:49 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 08, 2021
07:49 PM
UC_wrangler wrote:
When BMI.HWCFG=internal start from flash, the start address is fixed at 0xA0000020.
This is probably what you're after:const uint32 BootModeHeader_0[] = {
0xA0000020u, /**< \brief 0x000: .stad: User Code start address*/
0xB3590170u, /**< \brief 0x004: .bmhdid: Boot Mode Header ID (CODE) = B359H*/
0x00000000u, /**< \brief 0x008: ChkStart */
0x00000000u, /**< \brief 0x00C: ChkEnd */
0x00000000u, /**< \brief 0x010: CRCrange */
0x00000000u, /**< \brief 0x014: !CRCrange */
0xB2EB204Du, /**< \brief 0x018: CRChead */
0x4D14DFB2u, /**< \brief 0x01C: !CRChead*/
};
Hi UC_wrangler,
For the other parameters such as ChkStart, ChkEnd and CRCrange, they are not required to set when internal start from flash?
In addition, how to calculate the CRChead and !CRChead.
Thank you for you reading and reply.
Best regards,
Rocky
Aug 09, 2021
09:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2021
09:14 AM
ChkStart/End and CRCrange are only required for alternate boot mode headers, where the BootROM checks a defined range of PFLASH before jumping to it.
CRChead is the CRC-32 of the first 24 bytes of the structure, while !CRChead is the inverse (xor 0xFFFFFFFF).
Here's a quick link to a calculator that might help, with data from the structure above:
https://crccalc.com/?crc=a0000020b359017000000000000000000000000000000000&method=crc32&datatype=hex&...
CRChead is the CRC-32 of the first 24 bytes of the structure, while !CRChead is the inverse (xor 0xFFFFFFFF).
Here's a quick link to a calculator that might help, with data from the structure above:
https://crccalc.com/?crc=a0000020b359017000000000000000000000000000000000&method=crc32&datatype=hex&...
Aug 09, 2021
07:48 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2021
07:48 PM
UC_wrangler wrote:
ChkStart/End and CRCrange are only required for alternate boot mode headers, where the BootROM checks a defined range of PFLASH before jumping to it.
CRChead is the CRC-32 of the first 24 bytes of the structure, while !CRChead is the inverse (xor 0xFFFFFFFF).
Here's a quick link to a calculator that might help, with data from the structure above:
https://crccalc.com/?crc=a0000020b359017000000000000000000000000000000000&method=crc32&datatype=hex&...
Thanks UC_wrangler, the lockstep function is enabled.
Then, I tried to test its self test function, which will generate a fault to the CPU0 or CPU1, I write the code like below
IfxScuWdt_clearSafetyEndinit(IfxScuWdt_getSafetyWatchdogPasswordInline()); /* Clear Safety WDG Endinit. */
SCU_LCLTEST.B.LCLT0 = 1; /* Fault Injection */
IfxScuWdt_setSafetyEndinit(IfxScuWdt_getSafetyWatchdogPasswordInline()); /* Set Safety WDG Endinit */
Is it enough?
After injection, I tried to see the register of SMU_AG0 and SMU_AD0 to see if the injection is successful. However, status flag does not report a fault condition. Are the SMU_AG0 and SMU_AD0 register related?
Thank you for your reading and reply.
Best regards,
Rocky
Aug 10, 2021
01:50 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 10, 2021
01:50 PM
The safety endinit sequence isn't necessary - no harm done though.
Looking at the SafeTlib documentation, the lockstep test is performed in the pre-run phase, when the SMU is in RUN state (not START), but before the SMU configuration is locked. The fault should stay latched in SMU_AG0[0] until it's cleared.
Per 10.4.5.5 Alarm Debug Registers, SMU_ADx is only updated when the SMU causes a reset, or when the SMU transitions to the FAULT state.
Looking at the SafeTlib documentation, the lockstep test is performed in the pre-run phase, when the SMU is in RUN state (not START), but before the SMU configuration is locked. The fault should stay latched in SMU_AG0[0] until it's cleared.
Per 10.4.5.5 Alarm Debug Registers, SMU_ADx is only updated when the SMU causes a reset, or when the SMU transitions to the FAULT state.
Aug 10, 2021
09:20 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 10, 2021
09:20 PM
UC_wrangler wrote:
The safety endinit sequence isn't necessary - no harm done though.
Looking at the SafeTlib documentation, the lockstep test is performed in the pre-run phase, when the SMU is in RUN state (not START), but before the SMU configuration is locked. The fault should stay latched in SMU_AG0[0] until it's cleared.
Per 10.4.5.5 Alarm Debug Registers, SMU_ADx is only updated when the SMU causes a reset, or when the SMU transitions to the FAULT state.
Thank you for your reply.
Thank you for your reading.