• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 631 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.

AM6548: AM6548 Warm reset on MAIN and MCU domains

Milan Oklobdzija32
Intellectual 350 points
Part Number: AM6548
Other Parts Discussed in Thread: TMDX654IDKEVM


Hello All,

I have a strange behavior of warm reset in MAIN and MCU domains on our custom board utilizing AM6548 SoC.
Maybe someone from TI can help me get a better insight into this.

My configuration is:

CCS ver 8.3.0
Windows version - Windows 10 Pro version 1803
PDK - pdk_am65xx_1_0_6
Custom board based on AM6548

Our custom board uses the same general schematic regarding Reset as AM65x (IDK) - TMDX654IDKEVM board.
RESETz (F17) is connected to the mechanical switch with debounce circuit with the Schmitt trigger on the output. This is the same configuration as on the IDK board except that signal is routed directly to RESETz pin after Schmitt trigger.
MCU_RESETz (W4) is left open with an option for 10k pull-up resistor.
PORz (E19) is implemented similar to the IDK implementation.

Configuration of input pins in Pinmux is like on the following images:

What happens is that board runs fine (connection via XDS200 emulator) up until Board_init() is called and actually Board_pinmuxConfig() is called.
We tracked the problem to the RESETz and MCU_RESETz signals. If we disable these in Pinmux board boots and works fine. I can run the test application use MAIN UART0 and test DDR memory and other peripherals.
However, if either MCU_RESETz or RESETz are enabled SoC goes into reset as soon as these pins are initialized in Pinmux in Board library.
PORz is enabled in Pinmux and it seems that it works as expected as we use it as JTAG reset also.

I have checked the following with RESETz (as per 5.3.1.2 Device Reset Pins Routing in AM6548 TRM):
- Signal to the RESETz (F17) is high and stays high (3.3V) while SoC goes into reset (checked with oscilloscope and detected no glitch).
- State of CTRLMMR_WKUP_MAIN_WARM_RST_CTRL register is 0x80010000 before Board_init() is called so I assume that reset is not forced in SW.

This directed me to check MCU_RESETz behavior as the only signal influencing RESETz is RESETz_MCU_FINAL.
I disabled RESETz in SYSTEM Pinmux and enabled only MCU_RESETz in WKUP_SYSTEM and rebuilt the board library.
Than I have checked the following for MCU_RESETz:
- Tried two configuration with 10k Pull-up resistor populated and removed as on the IDK. Signal on MCU_RESETz is high and stays high (3.3V) while SoC goes into reset.
- State of CTRLMMR_WKUP_MCU_WARM_RST_CTRL register is 0x80010000 before Board_init() is called so I assume that reset is not forced on MCU also.

That left me wondering about the state of PORz_WKUP_INT.

Did I overlooked something here or forgot to check something?

Best regards,
Milan

  • 0
    Intellectual 350 points

    I just tested warm reset function on RESETz  pin on our custom board with MCU_RESETz and RESETz disabled in Pinmux and it works fine as Reset is default function for RESETz (F17) pin. So it seems we can have warm reset function on our board.

    However, I still don't know why we have different behavior on our board compared to IDK when MCU_RESETz and RESETz are enabled in Pinmux.

  • 0
    TI__Mastermind 23125 points

    Hi Milan, 

    could you confirm if you ever tried the following experiment:

    1. disable MCU_RESETz from pinmux;

    2. after booted, verify if MCU_RESETz can cause chip warmreset.

    I am just checked  Board_pinmuxConfig() in the PDK, it is writing to the corresponding PADCONFIG register. The MCU_RESETz is dedicated pin with the pad control defaulted correctly. so not sure why we need to rewrite the MMR.  So the reason I am asking the above experiment is to verify the pin shall be skipped from pinmux setup, and still works as a full-chip WARMRESET pin. 

    I will also get in touch with our PDK team to understand the background on what are the rules to re-mux these system pins. 

    regards

    Jian

  • 0 in reply to jian35385
    Intellectual 350 points

    Hello Jian,

    Thank you on the reply and suggestion.
    I disabled both MCU_RESETz and RESETz. Line on RESETz was high and I pulled MCU_RESETz low. 

    Sitara was reset as expected so MCU_RESETz works also.

    Best regards,
    Milan

  • 0 in reply to Milan Oklobdzija32
    TI__Mastermind 23125 points

    Milan, 

    Glad to hear that the MCU_RESETz is functional despite that you disabled them in the pinmux tool. This means the default PADCONFIG register setting functions as expected and there is no need to re-initialized this MMR. 

    Could you further check the header file create by your pinmux configuration, for the CTRLMMR_WKUP_PADCONFIG62 register? I would check against default as shown in Table 5-319 in the TRM.

    I still own to check with the PDK team. 

    Jian

  • 0 in reply to jian35385
    TI__Mastermind 23125 points

    Milan, 

    Since we aligned that the pin functions normally without including it in the pinmux tool, you are not blocked. I will treat this as a collateral improvement for TI internal tracking. 

    let me know if you still want a follow-up once the collateral improvement is complete.

    Jian