Difference between revisions of "IWDG internal peripheral"

[quality revision] [quality revision]
m
 

1 Peripheral overview[edit]

The IWDG peripheral is a watchdog unit that can be used to protect application frameworks running on Cortex-A7 from endless loops. This peripheral supports an independent clocking source in order to be able to continue running even when the rest of the system is in low power mode (STOP, STANDBY). Another important feature of this block is the early interrupt feature that allows to trigger an interrupt at a given power supply threshold before reaching the final reset: this gives the opportunity to run a recovery mechanism that will try to revive the system with minimum impact.

1.1 Features[edit]

Refer to STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to see which features are implemented.

1.2 Security support[edit]

IWDG1 is secure-aware (under ETZPC control).
IWDG2 is non-secure.

2 Peripheral usage and associated software[edit]

2.1 Boot time[edit]

Pay attention to the fact that IWDG can be configured to be automatically active at startup (without any software intervention) via BSEC. When this is the case, the watchdog is anyway frozen during ROM code execution but it will start to decrement its counter as soon as the ROM code is left so it is important to reload the watchdog from the boot chain in this case. This behavior is implemented for IWDG2 only in STMicroelectronics distribution via the trusted boot chain only.
Notice also that BSEC features some freeze bits that allow to freeze IWDG during platform STOP and STANDBY low power periods, avoiding to have to wake up (via RTC) for the only purpose of reloading the watchdog.

2.2 Runtime[edit]

2.2.1 Overview[edit]

IWDG1 can be allocated to the Cortex-A7 secure to be used in the secure context by the customer application: this instance is not supported in STMicrolectronics distribution.
IWDG2 can be allocated to the Cortex-A7 non-secure to be used with Linux watchdog framework. In this configuration, the secure monitor (from OP-TEE -if present- or TF-A) is able to receive IWDG early interrupts that can be used in a tentative to reset the Cortex-A7 without interfering with Cortex-M4 execution.

2.2.2 Software frameworks[edit]

Domain Peripheral Software frameworks Comment
Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Cortex-M4

(STM32Cube)
Core/Watchdog IWDG TF-A Linux watchdog framework

2.2.3 Peripheral configuration[edit]

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

2.2.4 Peripheral assignment[edit]

Internal peripherals

Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:

  • means that the peripheral can be assigned () to the given runtime context.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

Refer to How to assign an internal peripheral to a runtime context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possiblities might be described in STM32MP15 reference manuals.

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Cortex-M4

(STM32Cube)
Core/Watchdog IWDG IWDG1
IWDG2 Shared (none or both):
  • Cortex-A7 non secure for reload
  • Cortex-A7 secure for early interrupt handling



==Peripheral overview==
The '''IWDG''' peripheral is a watchdog unit that can be used to protect application frameworks running on Cortex-A7 from endless loops. This peripheral supports an '''independent''' clocking source in order to be able to continue running even when the rest of the system is in [[Power overview|low power mode]] (STOP, STANDBY). Another important feature of this block is the '''early interrupt''' feature that allows to trigger an interrupt at a given power supply threshold before reaching the final reset: this gives the opportunity to run a recovery mechanism that will try to revive the system with minimum impact.<br />


===Features===
Refer to [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for the complete list of features, and to the software components, introduced below, to see which features are implemented.<br>


===Security support===
IWDG1 is '''secure-aware''' (under [[ETZPC_internal_peripheral|ETZPC]] control).<br />

IWDG2 is '''non-secure'''.

==Peripheral usage and associated software==
===Boot time===
Pay attention to the fact that IWDG can be configured to be '''automatically active''' at startup (without any software intervention) via [[BSEC internal peripheral|BSEC]]. When this is the case, the watchdog is anyway frozen during [[STM32MP15 ROM code overview|ROM code]] execution but it will start to decrement its counter as soon as the ROM code is left so it is important to reload the watchdog from the [[Boot chainschain overview|boot chain]] in this case. This behavior is implemented for '''IWDG2 only''' in STMicroelectronics distribution via the [[Boot chainschain overview#STM32MP boot chainssequence|trusted boot chain]] only.<br />

Notice also that [[BSEC internal peripheral|BSEC]] features some freeze bits that allow to '''freeze IWDG''' during platform STOP and STANDBY [[Power overview|low power]] periods, avoiding to have to wake up (via [[RTC internal peripheral|RTC]]) for the only purpose of reloading the watchdog.

===Runtime===
====Overview====
IWDG1 can be allocated to the Cortex-A7 secure to be used in the secure context by the customer application: this instance is not supported in STMicrolectronics distribution.<br />

IWDG2 can be allocated to the Cortex-A7 non-secure to be used with Linux [[Watchdog overview|watchdog]] framework. In this configuration, the secure monitor (from [[OP-TEE overview|OP-TEE]] -if present- or [[TF-A overview|TF-A]]) is able to receive IWDG early interrupts that can be used in a tentative to reset the Cortex-A7 without interfering with Cortex-M4 execution.

====Software frameworks====
{{:Internal_peripherals_software_table_template}}
 | Core/Watchdog
 | [[IWDG internal peripheral|IWDG]]
 | [[TF-A overview#BL32|TF-A]]
 | [[Watchdog overview|Linux watchdog framework]]
 |
 |
 |-
 |}

====Peripheral configuration====
The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the [[STM32CubeMX]] tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

====Peripheral assignment====
{{:Internal_peripherals_assignment_table_template}}<onlyinclude>

 | rowspan="2" | Core/Watchdog
 | rowspan="2" | [[IWDG internal peripheral|IWDG]]
 | IWDG1
 | <span title="assignable peripheral" style="font-size:21px"></span>

 |
 |
 |
 |-
 | IWDG2
 | <span title="assignable peripheral" style="font-size:21px"></span>

 | <span title="assignable peripheral" style="font-size:21px"></span>

 | 
 | Shared (none or both):
* Cortex-A7 non secure for reload
* Cortex-A7 secure for early interrupt handling
 |-</onlyinclude>

 |}
<noinclude>

[[Category:Watchdog peripherals]]
{{PublicationRequestId | 8856 | 2018-09-21 | BrunoB}}
{{ArticleBasedOnModel| Internal peripheral article model}}
{{ReviewsComments|JCT 1840: alignment needed with the last version of the model [[Contributors:Internal peripheral article model]]<br>

[[Category:ToBeAlignedWithModel]]
}}</noinclude>
Line 11: Line 11:
 
==Peripheral usage and associated software==
 
==Peripheral usage and associated software==
 
===Boot time===
 
===Boot time===
Pay attention to the fact that IWDG can be configured to be '''automatically active''' at startup (without any software intervention) via [[BSEC internal peripheral|BSEC]]. When this is the case, the watchdog is anyway frozen during [[STM32MP15 ROM code overview|ROM code]] execution but it will start to decrement its counter as soon as the ROM code is left so it is important to reload the watchdog from the [[Boot chains overview|boot chain]] in this case. This behavior is implemented for '''IWDG2 only''' in STMicroelectronics distribution via the [[Boot chains overview#STM32MP boot chains|trusted boot chain]] only.<br />
+
Pay attention to the fact that IWDG can be configured to be '''automatically active''' at startup (without any software intervention) via [[BSEC internal peripheral|BSEC]]. When this is the case, the watchdog is anyway frozen during [[STM32MP15 ROM code overview|ROM code]] execution but it will start to decrement its counter as soon as the ROM code is left so it is important to reload the watchdog from the [[Boot chain overview|boot chain]] in this case. This behavior is implemented for '''IWDG2 only''' in STMicroelectronics distribution via the [[Boot chain overview#STM32MP boot sequence|trusted boot chain]] only.<br />
 
Notice also that [[BSEC internal peripheral|BSEC]] features some freeze bits that allow to '''freeze IWDG''' during platform STOP and STANDBY [[Power overview|low power]] periods, avoiding to have to wake up (via [[RTC internal peripheral|RTC]]) for the only purpose of reloading the watchdog.
 
Notice also that [[BSEC internal peripheral|BSEC]] features some freeze bits that allow to '''freeze IWDG''' during platform STOP and STANDBY [[Power overview|low power]] periods, avoiding to have to wake up (via [[RTC internal peripheral|RTC]]) for the only purpose of reloading the watchdog.