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.
Another thing I’ve noticed is that we’re all short on time. Many users just want to get past flash programming and move on to the next big thing. That’s where the ScanWorks platform for embedded instruments with its many boundary-scan tools as well as other validation, test and debug tools comes into play. But first, ScanWorks can help you get past flash programming.
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.
