SPRACA7A October 2017 – September 2022 TMS320F28075 , TMS320F28075-Q1 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-EP , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S
The length of time it takes to run a minimum-sized micro-run varies between device families, so you should refer to the profiling data for the STL_HWBIST_runMicro() function provided in the SDL User's Guide. In general, it takes approximately 2.5 µs on 200-MHz SYSCLK devices and approximately 4 µs on 100-MHz SYSCLK devices. These values were measured with the HWBIST functions running from 0-wait-state SRAM and takes longer with the wait-states of the Flash memory. This brings up the following points to consider:
Think in terms of interrupts that want to shut down the control operation due to an identified system fault. If there are, then these interrupts must be rerouted to another processor or a DMA channel for emergency processing while the HWBIST micro-run owns the CPU circuitry. Additionally, the system critical interrupt or task may be mapped to the NMI, which would stop the HWBIST micro-run execution.
If so, do not start the HWBIST until after this update is completed and you have adequate time before the next update, or manage the update with a DMA channel.
If yes, then this may be a suitable time slot to perform a HWBIST micro-run.