Use ST Microelectronics's X-CUBE-STL library for CPU/SRAM/Flash error detection

[ethanjli]

ST Microelectronics provides an STM32Cube "Expansion Package" named X-CUBE-STL which includes a safety manual, FMEA for the MCU, failure rates report, as well as the X-CUBE-STL library which we would like to use to detect random hardware failures in the CPU, SRAM, and Flash memory. This package can be used to achieve IEC 61508 SIL2.

I have contacted ST Microelectronics to obtain access to this package; once I receive it, I will upload it to our Google Drive repository and then we can assign this task for further action.

For preliminary analysis, we can review their document for STM32H7, as well as other more general documents. We will need to review about what requirements must be satisfied for integrating each piece of the library into our implementation.

[ethanjli]

I just realized that the RAMECC check is already available through the STM32H7 HAL (page 1167, i.e. section 67, of the STM32H7 HAL manual). So we can at least get RAM SECDED even without X-CUBE-STL. There is a slightly more detailed application note on this, but our repo doesn't yet have the RAMECC header from the STM32H7 HAL provided by STM32Cube MX - although it is available at https://github.com/STMicroelectronics/STM32CubeH7/tree/v1.7.0/Drivers/STM32H7xx_HAL_Driver/Inc and in the local download of the STM32CubeH7 package, it is not in our repo for some reason. We may need to manually copy the files over into our project and manually perform the initialization - it seems it may not be handled by STM32Cube MX.

[ethanjli]

I just finished a call with two people from STMicro. What I learned was:

• The main functionalities which would be provided by X-CUBE-STL are self-test routines for the CPU, SRAM, and Flash memory components to be run during normal operation
• We do not need X-CUBE-STL for SRAM error detection
• In order to know more about the specifics of the self-test routines in X-CUBE-STL, Pez Globo (and/or Bharat Forge?) would need to sign an NDA with STMicro

Based on what we know about regulatory requirements for medical devices (i.e. self-testing of those MCU system-level components may not be necessary), and considering the current state of our software development timeline, my recommendation is that we do not need to pursue obtaining access to X-CUBE-STL; instead, we should just focus on getting using the STM32 HAL's RAMECC library (and its FLASH library for Flash memory fault detection, if applicable) - refer to https://www.st.com/resource/en/application_note/dm00623136-error-correction-code-ecc-management-for-internal-memories-protection-on-stm32h7-series-stmicroelectronics.pdf

[ethanjli]

Due to prioritization of features, RAM error detection/correction logging will not be included in the HFNC release; I think this functionality is only useful for giving insight into ventilator troubleshooting, e.g. like how airplanes log flight data to their black box for post-incident investigation. The way I envisioned this being used was just having a small counter in the FRAM chip which is incremented every time a RAM error was detected, and another counter which is incremented every time a RAM error was both detected and corrected; then whenever a ventilator is serviced, the service technician might use the MCU to copy the FRAM data onto some other data source and send it back to the software team as a valuable snapshot of "telemetry" data. @renjipanicker I'll leave it up to you whether RAM error-related functionality will be added in a future release.