SCANSTA112: unecpected behaviour

Hi Chris,

We don't have any errata for this device, and its undergone no recent changes or revisions. 

The failure with 6 devices sounds like a cumulative timing issue, either due to loading or to skew. A marginal timing threshold would also be the type of thing that could go unnoticed for a while until a process variation in a device reveals it. 

What mode is your device in and what TCK Frequency are you operating at?  If you cut down the target TCK frequency as a test, do you see a pass instead of a failure?

Best Regards,
Brandon Fisher

Hi  Brandon, thanks for getting back to me.

have run the test as low as 1MHZ no difference. Here is summary of tests so far

HEADLINE FINDING — for the TI support query

On the faulty board, a non-zero mode register 1 causes mode register 0's port selection to be ignored. Both registers read back correctly. Another board of the same design, same silicon revision, does not do this.

Measured with the original 2023 production sequence, recovered from ...\19234 XJTAG A03 20230829 modded chain\ScanSta112.xje:

address slot 1 -> IDCODE check -> CONTROLSEL 0x04

-> MODESEL0 (once) -> MODESEL1 (once) -> TRANSPREN

MODESEL0 MODESEL1 Ports intended Devices reached Verified by

0x01 0x00 LSP0 1 correct XJTAG native check, IDCODE verified

0x03 0x00 LSP0–1 3 correct native check

0x07 0x00 LSP0–2 8 correct native check, IDCODEs verified, stops cleanly at device 9

0x27 0x00 LSP0–3 13 correct native check, stops cleanly at device 14

0x67 0x00 LSP0–4 18 correct native check, stops cleanly at device 19

0x67 0x01 LSP0–5 5 — only the LSP5 chain native check reads 5x 0x100A20CB, "broken 5 devices before TDO"

0x01 0x01 LSP0 + LSP5 5 — LSP0 dropped expected 6

0x00 0x01 LSP5 5 correct

A second board returns 6 from the LSP0+LSP5 case, i.e. it combines the two registers correctly. Both boards read silicon revision 0 (IDCODE 0x0FC2501F).

AN-1259 Table 8 lists MR0 = X110X111 / MR1 = XXXXX001 as stitching all six ports in series, so the observed behaviour contradicts the documentation.

Eliminated

· Reset sequence — the authentic 2023 original, an exact replica of it, and a reconstruction all behave identically

· UNPARK — adding it per AN-1259 and TI E2E thread 1093694 changes nothing

· Single vs double mode register writes — identical

· Write order — MODESEL1 before MODESEL0 makes no difference

· Clock speed — same at 25 MHz and 1 MHz (though speed does matter, see below)

· Transparent mode variant — full transparent (TRANSPREN) and transparent LSP (MODESEL1 bit 7) both fail the same way

· Mode register 2 — bits are LSP/GPIO function selects, not port selectors; setting bit 5 destabilises the chain. Leave at 0x00.

· U10 itself — replaced, no change. Possibly a same-batch replacement; a part from different stock is the outstanding test.

· Board power connections — all ten VCC and ten GND pins at U10 checked good

· Running code — flash erased so nothing boots, no change

· Silicon revision — uniform revision 0 across all boards tested

Still outstanding

· A U10 from genuinely different stock (different date code / supplier batch)

· TI support response

Hi Chris,

The behavior you're describing with the mode select registers seems to me like the MR0 port selection is not being applied for some reason. Is the failure consistent (I.e. you always fail at 5 devices and not 4)? 

To clarify, did the failing boards you identified work initially and then start failing over time, or did they never work? Has anything changed on these boards and are they in the same configuration (i.e. same passives/alternate components populated). Did these PCBs came from the same batch, and how did you rule out soldering/assembly issues? 

chris nash said:

· Board power connections — all ten VCC and ten GND pins at U10 checked good

This is a good check, is it possible for you to verify the supply voltage during a scan attempt? I want to be sure the voltage isn't sagging in operation.

Best Regards,
Brandon Fisher

hi brandon, faulty boards not all, fail between chain 4 and 5 from the scansta112. detect no power droop when run full test.. The failing boards never worked scan so could still have hardware faults but checked power and scanst112 pull up/straps are ok and of course my special bridge and localised chain by chain tests all work. We have boards from same batch some work others not

6052.Desktop.raroriginal full scan test and a modified one to run individual scan chains and bridge only test. the original test has normally worked for all boardsup till recent problems, no hardware

build change

Hey Chris,

Brandon is out of office currently, but he'll return next week. Thanks for your patience.

-Ethan

Hi Chris,

Given your scan chain tests, and the that there are no hardware/build changes between these boards, an A-B-A swap between a working and failing device/board seems like the most revealing next step.

I know you tried directly replacing a failing part already, but I'd like to see if the failure follows a failing device to a passing board, and if a previously good device can be made to fail by placing it on a currently failing board. 

Best Regards,
Brandon Fisher

Thanks Brandon,, understood... It may take a while to get a passing board as i work off site from our factory. can we leave this active for a while.

best regards

Chris

Hi Chris,

Yes no worries, we will leave the thread open and once you have an update please let me know.

Best Regards,
Brandon Fisher