Reset sequence while using JTAG on LS1028A

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Reset sequence while using JTAG on LS1028A

787 次查看
pb3
Contributor II

Hi I've got a question regarding reset sequence while using JTAG on LS1028A-RDB.

Below are my insights on how this is implemented on LS1028A-RDB, I would be grateful if you could confirm or correct my observations:

- JTAG RST (CWJTAG_RST_B) is connected to CPLD input called CWJTAG_RST_B

- while calling ccs::reset_to_debug, the CWJTAG_RST_B is asserted which is handled by CPLD, which in the response asserts JTAG logic of LS1028A (DUT_TRST_B) and asserts PORESET causing the usuaull PORESET events to happen (like zeroing the registers and so on)

- once the CWJTAG_RST_B is deasserted both DUT_TRST_B and PORESET are deasserted

Is above true?

Suppose that we do not have a similar signal like CWJTAG_RST_B on our CPLD, but when the CWJTAG_RST_B is asserted, we reset JTAG logic but our CPLD does not assert PORESET. Is there any workaround for this? What would happen if (based on e.g.LS1028A-RDB design), instead of the current solution we would connect  CWJTAG_RST_B with DUT_TRST_B and REQSET_REQ (in order to trigger RESET sequence when CWJTAG_RST_B is asserted)?

0 项奖励
回复
6 回复数

599 次查看
GMilliorn
Contributor I

To be clear:

"CWJTAG_RST_B is asserted which is handled by CPLD, which in the response asserts JTAG logic of LS1028A (DUT_TRST_B) and asserts PORESET "

never assert TRST to the processor when the target reset pin (10) is asserted, this breaks the ability to take control of the DUT.  TRST should be asserted on power-up only, generally.

0 项奖励
回复

588 次查看
June_Lu
NXP TechSupport
NXP TechSupport

Should always distinguish TRST and PORESET_n.

TRST_B is asserted during power-on reset flow to ensure that the JTAG boundary logic does not
interfere with normal chip operation.

PORESET_B is  power-on reset(POR) inputs, When PORESET_B de-asserts, the configuration pins
are sampled and latched into registers.

Please follow the checklist to connect the both signals.

0 项奖励
回复

572 次查看
pb3
Contributor II
Yeah, we solved it. It turned out that we have a bug in our system controller that was resseting JTAG logic when it was not needed.
0 项奖励
回复

754 次查看
June_Lu
NXP TechSupport
NXP TechSupport

If CWJTAG_RST_B  is not connect to PORESET_B, the CodeWarrrior TAP could not reset the LS1028A.

RESET_REQ_B is an output signal, could not connect a input signal to this pin.

Maybe you could try to link the two signal follow the FRWY-LS1046A which is no CPLD on the board.

( https://www.nxp.com/design/design-center/development-boards-and-designs/FRWY-LS1046A).

0 项奖励
回复

751 次查看
pb3
Contributor II
Thanks, we managed to solve the problem with reset, we also have CPLD on our board but we didn't not connect JTAG reset to CPLD, thus we basically were doing invalid reset sequence when JTAG wanted to reset the board. But now it's working fine.
We've been struggling with some more severe problems though, would be glad if you could have a look at this: https://community.nxp.com/t5/Layerscape/DDR-initialization-fails-on-a-cusotom-board-based-on-LS1028A...
0 项奖励
回复

749 次查看
June_Lu
NXP TechSupport
NXP TechSupport

Yiping will supporting you for that issue.

0 项奖励
回复