After the kernel boots, seeing instability with frequent reboots on LS1043ARDB on idle. Need to check reset status register and see if this is a known issue on any QorIQ platform and what is the root cause if open defect or fixed.
How do we read the Reset Request Status Register (DCFG_CCSR_RSTRQSR1)? Need the section of kernel code where reads should be done and an example needed.
See section 12.3.14 Reset Request Status Register (DCFG_CCSR_RSTRQSR1) in chapter 12 Device Configuration and Pin Control. QorIQ LS1043A Reference Manual rev. 1 8/16. See LS1021A Reset Reason
Solved! Go to Solution.
Codewarrior tap was connected to CPU Jtag with 10 pin gray cable. We measured with a scope, Tektronix TPS 2024. There was a short reset pulse estimated at about 10ms at TP6. This is the same issue as DTCCS-148 and described below.
Lauterbach has good description of the ARM JTAG see:
http://www2.lauterbach.com/pdf/app_arm_jtag.pdf
also see note below on page 6:
“The debugger drives it open-drain. A 47 k pull-up is within the debug cable.
There might be the need to place a pull-up (1 k - 47 k) on target side to avoid
unintentional resets when the debugger is not connected and probably to strengthen
the weak 47 k pull-up in the debug cable”
Per the tools team this is a known issue:
see DTCCS-148
This was a problem with the CPLD on the LS1043ardb boards, it is fixed by updating the programming of the CPLD or a hardware rework. Boards replaced for CPLD update or hardware rework. Takes five days if replaced with already updated/reworked boards.
This can be closed as resolved.
Not able to get the CPLD update instructions yet, but trying. NXP wanting to exchange the boards takes 5 days.
Codewarrior tap was connected to CPU Jtag with 10 pin gray cable. We measured with a scope, Tektronix TPS 2024. There was a short reset pulse estimated at about 10ms at TP6. This is the same issue as DTCCS-148 and described below.
Lauterbach has good description of the ARM JTAG see:
http://www2.lauterbach.com/pdf/app_arm_jtag.pdf
also see note below on page 6:
“The debugger drives it open-drain. A 47 k pull-up is within the debug cable.
There might be the need to place a pull-up (1 k - 47 k) on target side to avoid
unintentional resets when the debugger is not connected and probably to strengthen
the weak 47 k pull-up in the debug cable”
Per the tools team this is a known issue:
see DTCCS-148
This was a problem with the CPLD on the LS1043ardb boards, it is fixed by updating the programming of the CPLD or a hardware rework. Boards replaced for CPLD update or hardware rework. Takes five days if replaced with already updated/reworked boards.
This can be closed as resolved.
Thanks Tracy for making this info available here, it will surely save lots of time in the future. The text mentions a CPLD fix, is this fix explained any where ?
Thanks and best regards
Sinan Akman
Hi Tracy
You mentioned that the reset happens when CW TAP is configured. I assume your CW TAP is
connected to your board over JTAG at the time of the reboot. If this is the case, what is the debug state ? Are the resets/reboots happening during HALT ?
Regards
Sinan Akman
On two separate LS1043A running SDK 2.0 1609, Codewarrior was not running at the time of the boots. Started CW4 initially on first power up merely to resume and CW was showing disconnected when checked, then reboots occur.
This problem appears on SDK 2.0 1609 when Code Warrior TAP is configured. What is causing reboots?