AnsweredAssumed Answered

T1042RDB CPLD RESET configuration

Question asked by Kurt Ehrhardt on Apr 20, 2017
Latest reply on Apr 20, 2017 by ufedor

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:


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


Kurt Ehrhardt