• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 399 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: Main Domain Warm Reset usage

Gunter Schmer
Genius 14107 points
Part Number: AM6442

Hi,

two cases:

[1] No separate Main Domain reset needed

In this case we use MCU_PORz for power on reset of both MCU domain and Main Domain.

We use MCU_RESETz as warm reset for both MCU domain and Main Domain

MCU_RESETSTAT shows the warm reset status of the MCU domain

Questions

How do we need to handle MAIN_RESETz_REQ (warm reset pin for Main Domain)? The TRM says in 5.3.5.2.4 MCU_RESETz Reset

"In order for the MAIN domain to come out of reset, MAIN RESETz_REQ must also be de-asserted."

Does this mean, when we de-assert MCU_RESETz, we also have MAIN_RESETz_REQ de-asserted, i.e. have it pulled high through the whole reset sequence?

If MCU_RESETSTAT reports the MCU domain reset, during this reset sequence, does the RESETSTATz pin report the Main domain reset, i.e. deasserting later to show main domain reset complete?

[2] Separate Main Domain reset needed

In this case we use MCU_PORz for power on reset of both MCU domain and Main Domain.

We use MCU_RESETz as warm reset for both MCU domain

MCU_RESETSTAT shows the warm reset status of the MCU domain

We use MAIN_RESET_REQz for warm reset of Main domain

Questions

When the MCU_RESETz gets deasserted, but the MAIN_RESET_REQz is low, will now the Main domain still be held in reset, until the MAIN_RESET_REQz gets deasserted?

Will a MAIN_RESET_REQz assert followed by deassert cause only a Main Domain reset, and the MCU domain keeps running?

Over all question:

What reset is used when doing a Linux "reboot"?

Thanks!

--Gunter

  • 0
    TI__Guru* 80020 points

    Gunter,

    1) MAIN_RESET_REQz signal does need to be taken care of at the board level.  It is a reset request to the MAIN domain.  The signal triggers interrupts to the other processors on the device to start their reset isolation sequences (if applicable) before the main domain is reset.  Thus, this needs to remain high if you are using one of the other resets.  The MCU_RESETSTATz is a status of the MCU domain reset, and RESETSTATz is a status of the MAIN domain reset.  You can see their relationship in figure 7.7 of the TRM in response to an MCU_RESETz assertion.

    2)  This is a strange scenario as the processor will typically begin to boot when MCU_RESETz is deasserted, but the MAIN domain is still held in reset.  But i think the operation will still be the same.  Once the MAIN_RESET_REQz gets deasserted, the other processors will enter their reset isolation sequences and then the MAIN domain will be reset.  At other times, the MAIN_RESET_REQz assert followed by deassert will only cause the Main Domain to be reset. 

    I will have to ask the software folks on the linux reboot, but I'm fairly certain it generates an MCU reset.

    Regards,

    James  

  • 0 in reply to JJD
    TI__Genius 14107 points

    James,

    thanks! I think I understand.

    "The MCU_RESETSTATz is a status of the MCU domain reset, and RESETSTATz is a status of the MAIN domain reset.  You can see their relationship in figure 7.7 of the TRM in response to an MCU_RESETz assertion"

    In the TRM, could you say again which Figure shows the behavior? Fig 7-7 is this below, but you may look at something else

    Figure 7-7. MAILBOX_FIFO_STATUS_y Register

    Thanks!

    --Gunter

  • 0 in reply to Gunter Schmer
    TI__Guru* 80020 points

    Sorry, i meant figure 7-7 in the datasheet

    REgards,

    James