4.3 SPI Master Programming
(Ask a Question)When the system controller SPI is configured as a master, a device can program itself. In SPI master programming, the programming images are stored in the external SPI Flash memory using the SPI directory. For more information about the SPI directory and about programming the external SPI Flash memory, see Programming the External SPI Flash.
SPI master programming supports auto update and IAP. In auto update programming, if the version of the update image is found to be different from the currently programmed version, the system controller reads the update image bitstream from the external SPI Flash memory and programs the device on power-up. In IAP, the user application initiates the device program, and the system controller reads the bitstream from the external SPI Flash memory to program the device. The auto update and IAP operations are atomic and cannot be interrupted by JTAG or SPI slave commands.
The Auto Update feature is not enabled by default and if required, this needs to be enabled using Libero SoC. SPI Master mode also supports Auto Programming and Auto Recovery, see Table 4-5. These two features are enabled by default and do not require user configuration.
For information about the I/O states during SPI master programming, see I/O States During Programming.
The following table lists the initiation sources for the features supported by SPI master programming.
| Programming Feature | Description | Initiation Source |
|---|---|---|
| Auto programming | Programs a blank device | Device reset or power-cycle |
| Auto update | Updates device contents automatically | Device reset, power-cycle, or system service request |
| IAP | Updates device contents upon user request | System service request |
| Auto recovery | Automatically recovers the device from programming failure | Device power failure during programming |
For information about implementing auto-update and IAP, see AC466: PolarFire FPGA Auto Update and In-Application Programming Application Note.
Field updates performed in unpredictable conditions carry associated risks of programming failures. Example risks include a power brownout/outage event or internal system controller Single Event Upsets (SEUs) when re-programmed in high altitude or space applications. The following table shows IAP/auto-update recommendations to minimize these risks for various bitstream components when performing field updates to RT PolarFire devices. If SEUs are a concern, see RT PolarFire radiation test reports for SEU rates.
| Device | Security Only Bitstream | Fabric + sNVM Bitstream |
|---|---|---|
| RTPF500T | No1 | See 2. |
| RTPF500ZT | No1 | Yes3 |
- Reprogramming security settings, where power interruption or SEUs are possible, is not recommended to prevent the risk of accidental device lock-out. Device security settings and locks must be programmed in a terrestrial environment. The ability to perform field or in-flight updates of user cryptographic keys will be provided in a future tool release to enable the “key rolling” functionality.
- Microchip recommends using
RTPF500ZT for in-flight re-programming via IAP and auto-update modes as
described in Note 3. For RTPF500T devices, in-flight reprogramming via JTAG and
SPI target modes are recommended using an external device running DirectC
REPROGRAM_INFLIGHTaction. See the RTPF500T radiation test reports to understand the SEE performance of in-flight reprogramming without the enhancements described in the following note. This helps you determine if the results meet your application reliability requirements. - Device has enhanced IAP and auto-update algorithms that perform a standalone verify action and programming digest checks before enabling the device operation for in-flight reprogramming. This includes FPGA fabric and sNVM clients configured as read-only.
The following figure shows the recommended board configuration for SPI master programming. The VDDI3 must match the voltage specified in the datasheet associated with the external SPI Flash.
