IMX6 GPIO_1 not asserting as specified by JTAG boundary scan

[OptoJeff]

Hello NXP support (and any other internet travelers)!

I'm working on setting up some JTAG tests on some previously released products (each using imx6 processors), and am running into some struggles on a particular one. In this particular product, we are using a MCIMX6Q5EYM10AC (one of the 6Dual/6Quad imx6's).

We configure the internal watchdog (WDOG2) in U-boot, and setup it's output on the GPIO_1 pin to trigger our reset logic. The issue I am currently running into occurs before U-boot is loaded, and/or despite U-boot being wiped, so that shouldn't be the issue (just providing hardware context). 

For the boundary scan test I use the PRELOAD command to prepare GPIO_1 for a high assertion (watchdog output disabled high), then run an EXTEST again specifying a high assertion. But, after the EXTEST, it asserts low, triggering reset and breaking the JTAG chain. Removing the GPIO_1 path to reset logic on the board, I can still maintain a JTAG chain and see that regardless of what high/low outputs and sequence I try driving, GPIO_1 remains asserted low. Additionally, I've tried modifying the BSDL to swap pin cell references, and I see that the control works as intended on other physical pins with the same software/test, just not on GPIO_1. I've also of course verified through a digital analyzer that communication is correct.

I found several similar forum posts, including this one https://community.nxp.com/t5/i-MX-Processors/Boundary-Scan-on-IMX6/m-p/351855 from XJTAG (who I am using the test development tools of for this test). And all of them seem to come down to the configuration of the pins. After contacting XJTAG, that sent me over a file with some extra setup they've used previously, which adds a write to an undocumented (at least publicly) ExtraDebug register. This test didn't help me, but I'm hoping maybe someone could provide any other register information/write process that might help/provide me access to GPIO_1's pin configuration?

Alternatively, I see two other options. Access the memory location of GPIO_1 pad configuration through the OnCE/SDMA over the JTAG chain. Or, creating a custom U-boot specifically for our production-test use (we never plan to change the first stage of U-boot in production). I've been pursuing the former option for the moment, since no one in my company has messed with U-boot for several years, and I would need to figure out the build system/resources from scratch.

After adding the SDMA to the JTAG chain, enabling debug mode software trigger routing to the SDMA, and attempting to enter debug mode through the SJC, the SDMA remains a single cell in the chain (as if in bypass), which I've tested with opcodes (opcodes for sdma = instruction register values for SJC) for both rstatus and dmov registers. I also never see the debug mode ack from SDMA, regardless of how long I wait in ENTER_DEBUG, before swapping back to reading ack bit through ExtraDebug registers.

If anyone has any suggestions/help you can provide, or would like any additional information from me, please let me know! Thank you in advance!

[OptoJeff]

Ahhh, I'm realizing I may have misinterpreted the wording on one thing regarding the SDMA, which made me think the SDMA could be dynamically loaded/unloaded using the TAP Select instruction. I'm now thinking that it rather meant it could by dynamically chosen whether it is bypassed or not when it is already enabled (by JTAG MODE). Whoops! I did a bit of experimentation through an abstracted interface which had led me to conclude the JTAG instruction register chain was extended, when it was not! My bad.

Since there are no BSDL files for the SDMA and DAP. If anyone has a BSDL already made for either of them, please let me know. Otherwise I guess I'll make one from scratch for each of them, and hopefully get it right based on documentation.

[OptoJeff]

Just for reference, I'm in the process of figuring out how to handle the SDMA/DAP with our JTAG software toolset provider. In the normal case their system expects every device in the chain to have a single BSDL file associated with every chip and device in chain, and it automatically identifies the three different devices (TAP, SDMA and DAP). I'm not sure how that identification process works and/or whether there is a way to bypass the BSDL (containing IDCODE, SAMPLE...etc instructions), or include all three in one big BSDL without needing different instructions for every combination...etc

Long story short, we're working out the SDMA diagnosis approach on that end.

If there is a better way to diagnose or an obvious explanation for why these GPIO_1 low assertions are happening, I expect anyone reading this is more likely to be able to help (or be after help in the future) with that.

[OptoJeff]

Status update:
Figured out the peculiarities of my tooling well enough to perform setup/other tests in advance of first EXTEST/reset issue. But, I find that enabling the SDMA and DAP, then entering certain instructions into the TAP (such as EXTEST or TAP_SELECT) zeros out all TDO values. I tried using the reset sequence suggested in the SDMA section of the reference manual, but that didn't appear to have any effect.

If anyone has any suggestions on setup I may be missing please let me know. I'm sure it's something super simple, but I'm pretty far off the beaten path and my original goal (of preventing GPIO_1 from asserting low) as it is. So if I can't make any progress soon I'll just wait and see if anyone has any recommendations. Thank you in advance!