• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 790 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Boot WDT Warm Reset Override?

Robert Servilio
Prodigy 110 points
Other Parts Discussed in Thread: AM3703

I have a custom board with 2 AM3703 processors.  We have an external reset that is buffered with an open collector device and the same reset net goes to both processors' SYS_nRESWARM I/O pins.

What we didn't realize when designing this was that with both processors powered up with blank NANDs, both processors issue warm resets after timing out  (i.e., in a dead loop) when they can't find a valid boot source.  These warm resets occur continuously, approx. every 9 mS (SYS_BOOT is set to look at NAND first, then UART3).

Here's the problem.  If I try to boot one of the processors either through JTAG or UART3, that processor can get clobbered by the other processor's warm reset.

Is there a way to configure the processor being booted to ignore it's own warm reset input?  Perhaps a JTAG command that blocks external resets, at least until something valid is loaded?  Or through UART3 via the Flash tool?

The proper fix to this would be to have used 2 open collector buffers and isolate the 2 warm resets.  However, our TI apps person approved our configuration as a proper way to go.  Unfortunately, it's impossible to break the net and get at the 2 processor reset inputs due to the board routing.

Any thoughts would be appreciated.  We have tried powering down one of the processors, but the pad diode at the reset I/O of the powered-down processor is pulling the reset line permanently to .45V -- so the live processor is always reset.

Thanks in advance for any suggestions.

  • 0
    TI__Guru* 86550 points

    Robert, you should be able to disable the warm reset function on one of the processors by changing its pinmux for that I/O.  The warm reset pin is also muxed with GPIO_30, so if you JTAG into one of the processors, you can manually change that pin to GPIO, and then it won't issue warm resets (and it won't react to any warm resets).  Then you should be able to boot the other one with UART and/or NAND. 

    REgards,

    James

  • 0 in reply to JJD
    Prodigy 110 points

    James,

    Thank you for the quick response.  I will do as you suggest.  I assume in order to implement what you recommend, that I should use a GEL script wiith the pinmux settings.  Is there any critical timing here to be concerned about?  In other words, will the reset from the other processor interfere with the JTAG writes that configure the pinmux?

    Kind regards,

    Bob

  • 0 in reply to Robert Servilio
    TI__Guru* 86550 points

    I don't think a GEL script is necessary.  You should be able to simply connect thru JTAG, open up a memory window at the appropriate pinmux register (CONTROL_PADCONF_SYS_NRESWARM is at 0x48002A08) and set is to 0x4 (mux mode for the GPIO). 

    You are correct that you might have trouble keeping the JTAG connected while the processor is going thru a bunch of resets.  One idea is to setup a GEL file using the OnTargetConnect() function, and put the write to the pinmux register in there.  This will execute as soon as JTAG connects.

    Another idea would be to setup 2 JTAGs for each processor, and try to connect each.  When you connect, it should stop the resets since the code is halted. 

    One more (i'm thinking these up as i type), choose a different boot mode for one of the processors.  USB boot should have a multi-second timeout, which will give you time to connect to JTAG with the other one.  Or, a lot of times XIP boot will not fall into a deadloop because the check for a valid image is weak.  Try booting one of the processors with XIP first to see if that eliminates the warm resets from that device.

    regards,

    James

  • 0 in reply to JJD
    Prodigy 110 points

    Hello, James.

    These are all good options.  I especially like the XIP boot mode idea, since it would allow me to boot the processors without 2 JTAGs connected (or moving one between the 2).

    BTW, I tried setting the PADCONF on our Mistral EVM and it worked.  Basically, we set the register and then I manually pressed the warm reset pushbutton, which as expected, was ignored by the processor.

    I have a manufacturing defect with the board I was debugging, so I'll need to bring up another board before I try your ideas out.  I'll let you know how things work out.  Thanks again.

    Bob

  • 0 in reply to Robert Servilio
    Prodigy 110 points

    Hello James,

    I wanted to give you an update.  We could not update the PADCONF for the SYS_nRESWARM signal fast enough via JTAG before the warm reset from the other processor clobbered it.

    What we ended up doing was pulling the JTAG EMU0 from the offending processor low, then powering up.  This puts that processor in its Wait in Reset state.  In this state, it still issues a warm reset, but only once every 10-12 seconds!  This allows us to fairly reliably initialize the other processor and set its PADCONF to ignore the warm resets.

    Thanks for all your insightful help.

    Bob