ccs::reset_to_debug causes PORESET

[jasonhendrix]

We're trying to bring up the LS1020a on our custom board.  We're having trouble connecting via JTAG (CWTAP via USB) to the bare board in order to flash our RCWs into QSPI flash.  The sequence fails on "reset_to_debug" before we can even load our RCW override value.  We noticed on the LS1021ATWR dev board, that executing reset_to_debug causes a PORESET pulse.  According to the LS1021a ARM, PORESET should also assert TRST, but not neccessarily vice versa.  My questions are:

Why does "reset_to_debug" cause assertion of PORESET on the LS1021ATWR board?  And, should our design also assert PORESET when we use CCS to execute "reset_to_debug"?

[jasonhendrix]

The big picture - the reason I'm pulling on this thread is that it doesn't seem that we can get past the first jtag reset in order to override the RCW source and configure the RCWs with values over JTAG.  So, I'm trying to figure out what could be causing the "reset_to_debug" to fail.

[ufedor]

> According to the LS1021a ARM, PORESET should also assert TRST

In the QorIQ LS1021A Reference Manual, Rev. 0, 4.4.1 Power-on reset sequence it is written:

“The common on-chip processor (COP) requires the ability to independently assert PORESET_B and TRST_B to fully control the processor. If a JTAG/COP port is used, follow the JTAG/COP interface connection recommendations given in the chip's data sheet.”

Please refer to the QorIQ LS1021A Data Sheet, Rev. 1, Figure 90. JTAG interface connection.

> Why does "reset_to_debug" cause assertion of PORESET on the LS1021ATWR board?

The TWR-LS1021A has CPLD System Controller, which uses the JTAG_RST_B to generate PORESET_B.

>  And, should our design also assert PORESET when we use CCS to execute "reset_to_debug"?

Yes.

[jasonhendrix]

Hi Ufedor, is there any documentation on the signal timing?  For example, should PORESET be de-asserted before TRST, or vice-versa?

Also, looking at Figure 90, I see where PORESET could assert TRST, but not the other way around.  Where could one find more details on this relationship?

[ufedor]

> is there any documentation on the signal timing?

No special timing, the TRST_B just has to be pulsed (asserted low) during the processor power-on sequence.

>For example, should PORESET be de-asserted before TRST, or vice-versa?

There is no requirement concerning mutual timing of the signals because they reset separate parts of the SOC:

- PORESET_B is applied to the processor core and I/Os;

- TRST_B is applied to the JTAG controller.

> I see where PORESET could assert TRST, but not the other way around.

This is in accordance with the Note in the QorIQ LS1021A Reference Manual, Rev. 0, 4.4.1 Power-on reset sequence - please see the first response.

[jasonhendrix]

Thanks ufedor.  However, I still don't see where TRST must assert PORESET.  I've read your referenced material carefully, and It does recommend TRST be asserted when PORESET is asserted.  Not the other way around.  Hence figure 90:  TRST on the chip asserted by PORESET _OR_ TRST from the scan chain.  TRST from the scan chain has no effect on PORESET.

Maybe it's just common knowledge that TRST is supposed to be tied to PORESET.  At any rate, we'll take your word for it and modify our board so that TRST asserts PORESET.  Thanks for the help.

[ufedor]

> I still don't see where TRST must assert PORESET

There is no such requirement from Freescale/NXP.

> Maybe it's just common knowledge that TRST is supposed to be tied to PORESET

In the QorIQ LS1021A Reference Manual, Rev. 0, 4.4.1 Power-on reset sequence it is written:

"If the JTAG interface and COP header are not being used, Freescale recommends that TRST_B be tied to PORESET_B so that TRST_B is asserted when PORESET_B is asserted, ensuring that the JTAG scan chain is initialized during the power-on reset flow."

[jasonhendrix]

Thanks again, Ufedor.  It's probably academic at this point, but regarding 4.4.1 (and Figure 90): PORESET implies TRST, but TRST does not imply PORESET.  However, ccs::reset_to_debug causes PORESET (I assume the CPLD sees the TRST from the jtag chain and asserts PORESET).  This doesn't appear to be an NXP requirement, perhaps just the designer's choice?  Or is it neccessary?

[ufedor]

Sorry, but this is not academic.

In my first response I wrote:

"The TWR-LS1021A has CPLD System Controller, which uses the JTAG_RST_B to generate PORESET_B."

This is the line from the CPLD source code:

assign    poreset_b_18 = pwr_hrst_n && jtag_rst_b_18 && sw_rst_n;

[jasonhendrix]

I saw that, and I also observed that action on the board.  When I observed it on the board, I thought "where does it say that you should assert PORESET when you assert JTAG reset?".  You yourself said that it was not a requirement to assert PORESET when asserting TRST.  I was hoping to get a document that described the JTAG operation in greater detail, or an explanation as to why the LS1021ATWR designer chose to do it.

[ufedor]

There is no TRST_B signal on the JTAG header.

The CPLD code for the TRST_B is:

assign    cpu_trst_b_18 = pwr_hrst_n && k20_trst_b_18;

[jasonhendrix]

Thanks for sticking with me, Ufedor.  Let me digest this latest info and get myself straight on TRST from JTAG (optional) and TRST_B on the processor and the jtag_rst_b from the CPLD code.

[jasonhendrix]

Looking at the schematic and your responses, it looks like TRST from the JTAG connector goes into the CPLD as JTAG_RST_B_18, which asserts PORESET via this code in the CPLD:

poreset_b_18 = pwr_hrst_n && jtag_rst_b_18 && sw_rst_n;

Ergo, JTAG TRST causes assertion of PORESET.  Why?  We don't do that our design.  Is this a requirement?

[ufedor]

> it looks like TRST from the JTAG connector

There is no TRST_B signal on the JTAG header.

[jasonhendrix]

I'm not saying there is.  Are you saying that pin 10 from J12 that is connected JTAG_RST_B_18 is not TRST?  I see in that connector diagram right above it, that it's called nRESET.  Is it a requirement that nRESET cause PORESET?  That's what our discussion has led me to believe.

[ufedor · Accepted solution]

> JTAG_RST_B_18 is not TRST?

Yes.

> Is it a requirement that nRESET cause PORESET?

I've got confirmation from the CodeWarrior support stating:

"For CW/CCS to be able to control the reset sequence, this is required."

[jasonhendrix]

Thanks again, Ufedor.