I interact with users of ScanWorks boundary-scan test (BST) tools quite frequently and one issue that comes up often is the topic of in-system NOR and NAND flash programming with boundary scan.
Here are the “Top 10 Reasons” for programming your flash with boundary scan that I hear from users:
- The flash needs to be programmed now, right away, immediately, if not sooner! It can’t be postponed until other channels will be available.
- The flash can’t be programmed via a processor or FPGA because it is not connected to either of these. It is connected to a boundary-scan device.
- The model-based test development of a flash programming operation is really fast with a tool like ScanWorks BST.
- The source code being programmed into the flash is quite small so the speed of boundary-scan is sufficient.
- The MANID and DEVID codes need to be tested as well as the interconnects to the flash.
- Programming flash with boundary scan is fast enough for a certain application when certain shortcuts, such as taking advantage of WE, RDY_BSY, shorter scan chain and others are implemented.
- The flash image needs to be updated in the field or lab.
- Code for functional programming is not available.
- The flash is connected to a secondary processor that is not supported by ScanWorks Processor-Controlled Test (PCT).
- The flash is connected to an FPGA but the user’s company doesn’t own a ScanWorks FPGA-Controlled Test (FCT) license.
We dare you to share your own reason. Add a comment below.