Other Parts Discussed in Thread: DM3730
Hello.
I posted this question in the TPS659xx PMU forum (see http://e2e.ti.com/support/power_management/pmu/f/43/t/377147.aspx) and was referred here.
We have a system with a DM3730 + TPS65920 companion chip.
Referring to the document:
Powering OMAP™3 With TPS65930/20:
Design-In Guide (swcu059b.pdf)
I read in section 3.1.1.1 Power On and Reset Management...
The TPS65930/20 companion IC is the system power on and reset manager:
....
· It controls the reset release of the OMAP3530.
· It controls the warm reset steps when instructed to do so by the OMAP3530 or the user.
....
and in section 4.3.1.3 nWARMRESET
nRESWARM is an active low input reset signal to the device. Depending on the application, this signal can
be connected to a reset button, an RC cell, or the warm reset output of the OMAP application processor.
This reset signal can be used to put the device into a known stable state. For the warm reset signal to be
functional there should be a predefined sequence programmed in the device memory. For details about
this sequence,see the TRM.
So we want the nRESWARM signal to start this "predefined sequence programmed in the device memory".
If I refer to the TRM e.g.
TPS65930/TPS65920 OMAP™
Power-Management
and System Companion Devices
Silicon Revision 1.2
Version D
(SWCU052D)
I read in section
5.3.2 Resets and Power Management
5.3.2.1 Resets
Warm reset: The device can be configured to perform a warm reset of the system to bring the system
to a known defined state. The device detects a request for a warm reset on the nRESWARM pin. The
SmartReflex I2C accesses are canceled. The minimum duration of the pulse on the nRESWARM pin is
two 32-kHz clock cycles.
A warm-reset sequence can be programmed in device spare memory spaces by writing to the
MEMORY_DATA and MEMORY_ADDRESS registers. The starting address of this sequence can then
be programmed in the SEQ_ADD_WARM register.
A table follows which is marked as "Table 5-3. Sample Warm Reset Sequence".
So it looks very much as if I should be able to program the sequence "by writing to the MEMORY_DATA and MEMORY_ADDRESS registers" and that the sequence in the table is only a "sample" sequence.
By patching our Linux kernel in a similar way to here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251571.html
we can observe that the warm reset sequence is being started.
Our sequence looks like this (my comments added):
{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2 }, /* Triton off */
{ MSG_SINGULAR(DEV_GRP_P1, 0x0f, RES_STATE_WRST), 15 }, /* VDD1 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15 }, /* VDD2 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x07, RES_STATE_WRST), 96 }, /* VPLL1 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2 }, /* HFCLKOUT active */
{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2 }, /* Triton active */
Although we can observe the power supply rails and can confirm that we have implemented this sequence correctly we still see occasional hangups after a reset (thousands instead of hundreds of resets). However, for our application this is still not reliable enough.
When the problem occurs we see that the sys_nrespwron signal (CPU input) is pulled active and is subsequently released. But the sys_nreswarm signal (used as an output from the CPU as input to the TPS) remains in the active state instead of going inactive. The CPU will then not boot.
Note: a cold reset of the system is reliable.
My questions are:
(1) Is the sample really to be used as a generic warm reset sequence and, specifically, is it valid for DM3730 CPUs?
(2) The used sequence brings a vast improvement for us; but would it make sense to experiment with the length of the delays within the sequence to try to improve things even more?
(3) What other suggestions to improve the sequence (for DM3730) can be made?
Thanks very much in advanced.
--
Howard
