Nov 05, 2019
02:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 05, 2019
02:31 AM
Hi AURIX Community,
Is CPU watchdog and Safety watchdog the same for TC23x MCU?
Thank you and best regards
Christine
#8042000 19643
Is CPU watchdog and Safety watchdog the same for TC23x MCU?
Thank you and best regards
Christine
#8042000 19643
- Tags:
- IFX
5 Replies
Nov 05, 2019
07:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 05, 2019
07:11 AM
Hi Christine,
No, both watchdogs are different.
The Safety Watchdog Timer provides an overall system level watchdog which is independent from the CPU watchdogs and also provides temporal protection against unintended writes to critical system registers which could have impact on safety-critical systems.
The individual CPU Watchdog Timers provide the ability to monitor separate CPU execution threads without the need for software to co-ordinate the shared use of a common watchdog.
Each CPUx watchdog timer also incorporates a local CPUx_Endinit feature which provides temporal protection against unintended writes to critical local CPU registers and also some system registers which require protection but are not already covered by the Safety ENDINIT.
Best regards
Mr. AURIX™
No, both watchdogs are different.
The Safety Watchdog Timer provides an overall system level watchdog which is independent from the CPU watchdogs and also provides temporal protection against unintended writes to critical system registers which could have impact on safety-critical systems.
The individual CPU Watchdog Timers provide the ability to monitor separate CPU execution threads without the need for software to co-ordinate the shared use of a common watchdog.
Each CPUx watchdog timer also incorporates a local CPUx_Endinit feature which provides temporal protection against unintended writes to critical local CPU registers and also some system registers which require protection but are not already covered by the Safety ENDINIT.
Best regards
Mr. AURIX™
Dec 15, 2019
11:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 15, 2019
11:02 AM
Hello Support,
So for devices like TC297,
Can one core write to Safety Watchdog Register address space while another core writes to it's own CPU Watchdog without any Peripheral Address Semaphore?
If Semaphore is not used, then because it is in the same Peripheral Address Block I suppose, will there be any race condition while performing simultaneous write access?
Thank you.
Regards
Pashan
So for devices like TC297,
Can one core write to Safety Watchdog Register address space while another core writes to it's own CPU Watchdog without any Peripheral Address Semaphore?
If Semaphore is not used, then because it is in the same Peripheral Address Block I suppose, will there be any race condition while performing simultaneous write access?
Thank you.
Regards
Pashan
Dec 16, 2019
08:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 16, 2019
08:14 AM
The Safety Watchdog registers and the CPU watchdog registers are different addresses. There's no need for a semaphore.
Dec 30, 2019
04:21 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 30, 2019
04:21 PM
Hello Support,
If you look within TC297 User Manual Revision 1.3 the following table, you will see that for each Peripheral there is a effectively a chip-select like 256byte blocks [peripheral frame select] are there in the address map of Segment 15
"Table 3-3 On Chip Bus Address Map of Segment 15" -- Page 233/5791 in Acrobat
Because all the watchdog registers are in the same Chip Select range of "System Control Unit (SCU)", same peripheral frame address, so I thought you need semaphore across core. Because otherwise chip-select/frame-select will collide from simultaneous access.
Nowhere in the user manual I could find a clear description of simultaneous Peripheral Frame Select access related material.
Let me know what do you think.
Is semaphore needed only when the exact 32-bit address collision occurs or it is needed for peripheral frame select address range related collision also?
What is the exact boundary of address collision?
Thank you.
Regards
If you look within TC297 User Manual Revision 1.3 the following table, you will see that for each Peripheral there is a effectively a chip-select like 256byte blocks [peripheral frame select] are there in the address map of Segment 15
"Table 3-3 On Chip Bus Address Map of Segment 15" -- Page 233/5791 in Acrobat
Because all the watchdog registers are in the same Chip Select range of "System Control Unit (SCU)", same peripheral frame address, so I thought you need semaphore across core. Because otherwise chip-select/frame-select will collide from simultaneous access.
Nowhere in the user manual I could find a clear description of simultaneous Peripheral Frame Select access related material.
Let me know what do you think.
Is semaphore needed only when the exact 32-bit address collision occurs or it is needed for peripheral frame select address range related collision also?
What is the exact boundary of address collision?
Thank you.
Regards
Dec 31, 2019
02:02 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 31, 2019
02:02 PM
The addressing doesn't imply any restriction on access timing. The addressing grouping often does reflect the Access Enable safety mechanism that lets you restrict which bus masters have access to each peripheral (see ACCEN0 and ACCEN1). By default, access by all bus masters is permitted.
In general: even if two CPUs are accessing the same address in the same clock cycle, the SRI and SPB arbitration will resolve the conflict and make the second CPU wait.
You can control the priority level of each bus master, but in general, you don't have to.
That said, controlling the Safety Watchdog from two different CPUs is not a best practice - it can make the system very difficult to debug, and lead to unexpected stalls on the CPUs involved. You are free to prove me wrong 😉
In general: even if two CPUs are accessing the same address in the same clock cycle, the SRI and SPB arbitration will resolve the conflict and make the second CPU wait.
You can control the priority level of each bus master, but in general, you don't have to.
That said, controlling the Safety Watchdog from two different CPUs is not a best practice - it can make the system very difficult to debug, and lead to unexpected stalls on the CPUs involved. You are free to prove me wrong 😉
This widget could not be displayed.