• Seems like hotmail /outlook is blocking emails from here so please refrain from using one of these accounts as you may not receive your authorization email.. many thanks

Feature Preview: BOUNDARY SCAN PROGRAMMER

Pantheon

Active Member
Developer
FlashcatUSB Professional can be used to program a parallel NOR flash that is connected to a MCU, CPLD, or FPGA with a JTAG interface. This can be accomplished by using a little-known process called 'boundary scan programming', where the JTAG host controller puts the target device into an interconnect test (EXTEST) mode and continually updates all of the pins on the device to “simulate” the NOR programming interface.

boundary_scan_board.png

The benefits of using this feature is that the external hardware does not need any special configuration or specific JTAG registers in order to program the memory and is considered the most versatile and universal method. However there are drawbacks. First, data transfer speeds are going to be slow. For example, with the JTAG clock set to 20MHz you should expect a read speed of 5KB/s and a write speed of 2.5KB/s.

To use this feature, first you need to obtain the 'Target' BSDL file. This is a plain-text file that describes all of the physical pins for a particular IC and all of the internal pins and registers.

In the BSDL file, look for the line “attribute BOUNDARY_LENGTH” and at the end of this it will say “entity is <NUMBER>; This number is the number of bits that the boundary scan register is.

Next, the file will then list all of the bits in the boundary scan register, starting with the bit index and then several parameter. The second parameter will be the pin description. Using this, you need to make a map of all the pins that connect to the Flash.

A typical NOR flash will have address pins, data pins, and control pins. You need to correctly create a list of all the pin indexes that are associated with the NOR flash pins.

For example, a 2mbit bootrom will have 20 address pins (labeled AD0 to AD19), 16 data pins (labeled DQ0 to DQ16) and 6 control pins labeled CE# (chip-enable), OE# (output-enable), WE# (write-enable), BYTE# (Byte/Word select), WP# (write-protect), and RESET#. RB# is also listed but you can ignore that as its not used. Some PCB designs may hardwire CE# to GND and RESET# and WP# to VCC, in which case you can ignore those too. But if they are wired to the Target IC, you need to include them. Note: datasheets will often vary on the pin terminology, some might use G instead of OE, A0 instead of AD, D0 instead of DQ0, etc.

With a map of all the TAGET IC pins to the NOR FLASH pins, you need to create a text file (and name it with the .FCS extension indicating it is a FlashcatUSB script file) and put the following script commands:

BoundaryScan.Setup(664)
BoundaryScan.AddPin(331, "DQ0")
BoundaryScan.AddPin(259, "DQ1")
….
BoundaryScan.Detect()

The BoundaryScan.Setup command inputs the total number of bits of the boundary scan register (BSR). This is the number you got early from the BSDL file.
The BoundaryScan.AppPin command specifies which BSR bit is associated with each NOR FLASH pin. Make sure you use these pin terminology:
Data pins: “DQ0” – “DQ15” (note: for X8 devices, only specify up to DQ7)
Address pins: “AD0” – “AD25” (note: you only need specify up to the number of address pins you will use)
Control pins: “WE#”, “OE#”, “BYTE#”, “WP#”, “RESET#”, “CE#”
Finally the BoundaryScan.Detect command will initiate the software and attempt to detect the NOR flash, if it is successful, you will see this:

BDR_DETECT_FLASH.png

BDR_CONSOLE.png

Enclosed is an actual BSDL file for the LCMXO2 and the sample script used to create the above memory interface.

As you can see, it took approx. 1 hour to program a 8MB file. So this is only a viable solution if there is no other way.
 

Attachments

Asherk

New Member
The BSDL file I have for an Actel Proasic3 shows for the BOUNDARY_REGISTER the pin connected to the CE pin on the attached Spansion S29AL016J NOR Flash as
--BSR H6 R2AB051_CSFLASH_CE. Scan Cell 40
" 120 (BC_1, R2AB051_CSFLASH_CE, output3, X, 121, 0, Z), "&
" 121 (BC_1, *, control, 0), "&
" 122 (BC_1, R2AB051_CSFLASH_CE, input, X), "&
There are similar entries for the address, data, etc. lines.
Am I correct that to do the Boundary Scan programming on the S29AL016J I will need to enter
BoundaryScan.AddPin(120, "CE") in the script file instead of one of the other indexes?
 

Attachments

Asherk

New Member
To read the Spansion S29AL016J NOR Flash, will I need to specify the input indexes?
For the data lines
--BSR A11 TRA1R0AT125_DQ0. Scan Cell 180
" 540 (BC_1, TRA1R0AT125_DQ0, output3, X, 541, 0, Z), "&
" 541 (BC_1, *, control, 0), "&
" 542 (BC_1, TRA1R0AT125_DQ0, input, X), "&
will I need both
BoundaryScan.AddPin(540, "DQ0") and
BoundaryScan.AddPin(542, "DQ0") in scripts?
 

Pantheon

Active Member
Developer
No. From looking at your BSDL it appears the chip uses multiple bits to store/load INPUT/OUTPUT instead of using one cell. The software would need to be modified to accommodate for this.
 

Pantheon

Active Member
Developer
I am looking at the code now to see how to accommodate for this. First change, will be to make the .AddPin routine take output cell, control cell, then input cell. So for example: BoundaryScan.AddPin("DQ0", 540, 541, 542)
 

Pantheon

Active Member
Developer
@Asherk When you finish the script file, post it here for me to check it. Also, you have FlashcatUSB Professional 4.0?
 

Asherk

New Member
@Asherk When you finish the script file, post it here for me to check it. Also, you have FlashcatUSB Professional 4.0?
Yes, we have the FlashcatUSB Professional 4.0. In fact I wanted to ask, does Boundary Scan have to use the ARM-JTAG connector instead of the IO Port? Is there a way to use the IO Port instead? We have another device that has a cable that would fit the IO Port.
 
Last edited:

Asherk

New Member
The BSDL file I posted was based upon the base file obtained from Microsemi BSDL Models: ProASIC3 A3P250-FG144 which was modified according to these schematics. We cannot locate the post-development BSDL.
Since our only concern currently is modifying the data in the flash eeprom, those were the only pins we noted in the BSDL. Should we have been concerned with any others?
BTW, the flash is hard-wired in word mode while the FPGA and the microprocessor addresses are by byte so our data resides only in the odd bytes.
How may this affect us?
1187
 

Attachments

Top