On the T1042RDB, we believe our test equipment (Lauterbach debugger) to assert an HRESET_REQ when the SYSTEM.UP command is processed. If we first clear the DCFG_CCSR_CRSTSR1 (CCSR_BASE+E0400) by writing 1’s to it, subsequently we see its value is 0. Then a SYSTEM.UP is performed. Afterword, the DCFG_CCSR_CRSTSR1 reports a value of 0x1 (RST_PORST). We are expecting a value of 0x2 (RST_HRESET). This leads us to believe PORESET is being asserted to the T1042 not HRESET when the HRESET_REQ is made by the debugger.
The T1042RDB CPLD has a miscellaneous control and status register MISCCSR at address 0x17 from the base address of the CPLD. UBOOT maps the CPLD base address at 0xFFDF0000. A memory dump of FFDF0017 shows a value of 0xB1. The ‘B’ sets the REQ_MD bit field to ‘11’, which states “PORESET occurs when HRESET_REQ triggered”. We changed this value to 0x91, using UBOOT mw command, “HRESET occurs when HRESET_REQ triggered” and follow the above procedure. We still do not get the HRESET we are expecting. In summary:
Sequence:
Is there a way to get the system behavior to act as expected (HRESET_REQ drives HRESET to T1042)? Do we need to reprogram the CPLD on the T1042RDB or is there some other method?
Regards,
Kurt Ehrhardt
已解决! 转到解答。
> we believe our test equipment (Lauterbach debugger) to assert an
> HRESET_REQ when the SYSTEM.UP command is processed.
This assumption is not correct.
The T1024RDB JTAG connection is implemented in accordance with the AN4971 - QorIQ T1024 Family Design Checklist, Figure 23. JTAG interface connection - i.e. COP_HRESET_B is connected to the processor's PORESET_B.
> we believe our test equipment (Lauterbach debugger) to assert an
> HRESET_REQ when the SYSTEM.UP command is processed.
This assumption is not correct.
The T1024RDB JTAG connection is implemented in accordance with the AN4971 - QorIQ T1024 Family Design Checklist, Figure 23. JTAG interface connection - i.e. COP_HRESET_B is connected to the processor's PORESET_B.