Why use boundary-scan to program flash memory?

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.