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:
- Power cycle T1042RDB. Stop auto boot in UBOOT.
- Modify 0xFFDF0017 0x91. (Sets REQ_MD to ‘01’).
- Stop processor execution at the current instruction using breakpoint command in debugger.
- Clear DCFG_CCSR_CRSTSR1 to 0 by performing w1c on all bits (writing 0xFFFFFFFF) using debugger.
- Perform debugger “System.UP” (drives HRESET_REQ)
- Observe DCFG_CCSR_CRSTSR1 value (set to 1 (PORESET) not 2 (HRESET))
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
