• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 2048 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.

Emulator reset and power consumption during RESET# assertion (AM5K2E02)

Nuri Eady
Prodigy 230 points
Other Parts Discussed in Thread: AM5K2E02
With the AM5K2E02 I have found that power consumption increases significantly when the RESET# input is pulled low while leaving the RESETFULL# input high. When RESETFULL# is pulled low power consumption drops. Is this the expected behavior? 
Also I am wondering which reset input is most appropriate to connect to the nReset# pin of the emulator? I would like to be able to initiate a reset of the processor from the emulator and halt the processor before it starts executing.
Thank You
  • 0
    TI__Guru* 81335 points

    Hi Nuri,

    I hope you are following the keystone design guide. If not, we recommend you to follow the guide from below link.

    Keystone Design Guide:

    Schematic Checklist:

    Thank you.

  • 0 in reply to Raja
    Prodigy 230 points

    Thank you for the feedback, I have used both documents you mentioned during the design and reviewed them briefly again but unless I'm missing something I didn't see anything that answers the two questions I posed.  Any input on these two questions is most appreciated.

    On a related note I would like to reset the processor and halt it before it starts executing any code. Is this possible with this processor? The problem I have is that code I have loaded in flash is causing a bus hang which then prevents the emulator from attaching. What I think needs to occur is that the emulator needs to attach and put the processor in debug mode (halted) prior to reset release. I realize I can change the boot mode to "No Boot" however this is not real convenient due to the way the circuit is designed and I'm hoping there is a way to take back control of the processor using the emulator so that new code can be loaded without changing the boot mode.

  • 0 in reply to Raja
    TI__Mastermind 46460 points

    Nuri,

    Please review the available descriptions for PORz, RESETFULLz and RESETz in the supplied documentation.  Each is uniquely different.  Here are a few high points:

    • PORz is most inclusive.  It resets everything and it tri-states almost all output buffers.  It should be driven by "power good" logic.
    • RESETFULLz is logically same as PORz.  It resets everything but does not tri-states all output buffers.  It is the hard reset that should be used to latch the BOOTMODE.
    • RESETz is programmable and can be blocked by register configuration.  It does not reset emulation logic and you can actually operate emulation through this reset if the chip is properly configured.

    The reset logic inside the chip is fully synchronous.  A clock is required to propagate it through the device.  This is true for all functional blocks including those that operate on a clock other than SYSCLK such as the DDR3 PHY and Controller.

    SRESET from the emulator may be connected to logic driving any of the resets listed above.  It depends on what you want to do.  It is intended to be a System Reset since you might need to be resetting other circuitry on the board at the same time.

    Tom

  • 0 in reply to Tom Johnson 16214
    Prodigy 230 points

    Thanks Tom,

    Is it possible for the emulator to attach while RESETz is asserted and halt the processor prior to code execution? This would allow me to take control of the processor before bad boot code causes an internal error which prevents the emulator from working anymore.

  • 0 in reply to Nuri Eady
    TI__Guru*** 125430 points

    Nuri Eady said:
    On a related note I would like to reset the processor and halt it before it starts executing any code. Is this possible with this processor?

    One method is to set a hardware breakpoint at the code entry point (i.e. the place where the boot ROM branches to).  It needs to be a hardware breakpoint, because otherwise the breakpoint opcode will be overwritten when the ROM loads the code.  You can then perform a chip reset through the JTAG, e.g. Run -> Resets -> System Reset, and you should halt at that breakpoint.

    Another method is to use the "wait in reset" mode.  I see this phrase mentioned in the data sheet and in the K2 Debug and Trace User Guide.  I don't see this described, but on other devices the wait in reset mode is accomplished by having EMU0=0 and EMU1=1 at the rising edge of reset.  You can then connect to the ARM, setup your hardware breakpoint (similar to first method), and then run to that breakpoint.

  • 0 in reply to Brad Griffis
    Prodigy 230 points

    Thanks Brad, this is very helpful.

    The first method I don't think will work for me since after the processor hangs due to bad code in the flash I can't attach using the emulator to set the breakpoint. The second method however worked and I can attach to the processor after reset while it is in the "wait-in-reset" mode.

    I understand that the RESET# input to the processor does not reset the JTAG module and it seems some communication can be performed if configured correctly. Do you know where I can find more information about what needs to be configured in order to attach when RESET# is asserted?

  • 0 in reply to Nuri Eady
    TI__Guru*** 125430 points

    Nuri Eady said:
    I understand that the RESET# input to the processor does not reset the JTAG module and it seems some communication can be performed if configured correctly. Do you know where I can find more information about what needs to be configured in order to attach when RESET# is asserted?

    Are you saying you've tried this and it doesn't work?

  • 0 in reply to Brad Griffis
    Prodigy 230 points

    Here is the error I get when I try to connect to the target when RESET# is asserted...

    I did find that when I run the "Test Connection" under the Target Configuration it passes and allows bits to circulate in the scan chain while RESET# is asserted.

  • 0 in reply to Nuri Eady
    TI__Mastermind 46460 points

    Nuri,

    Emulation trace through RESETz assertion requires certain configuration before RESETz is asserted.  If the device has never exited reset and been properly configured, emulation will not connect while RESETz is asserted.

    Tom

  • 0 in reply to Tom Johnson 16214
    Prodigy 230 points
    That makes sense. Where can I find info about how to configure the processor after exiting reset so that on subsequent RESETz assertions I should be able to attach?

    Thanks,
  • 0 in reply to Tom Johnson 16214
    TI__Guru*** 125430 points
    Nuri,

    Why aren't you using the wait-in reset method? It sounded like that worked as expected.

    The way RESET# was defined was to allow you to *survive* a reset, not so much to connect while the device is being held in reset. You certainly wouldn't be able to connect to any of the underlying cores while the device is held in reset. One potential option comes to mind... You *might* be able to connect to the ICEPICK while RESET# is asserted. While you're connected I think you should then be able to right-click on the A15 and enable "halt on reset" for that core.

    Brad
  • 0 in reply to Nuri Eady
    TI__Guru*** 125430 points

    Nuri Eady said:
    That makes sense. Where can I find info about how to configure the processor after exiting reset so that on subsequent RESETz assertions I should be able to attach?

    Thanks,

    I normally just right-click on the A15 up in the debug panel and enable the "halt on reset" option. 

  • 0 in reply to Nuri Eady
    Prodigy 230 points

    I am now able to attach to the processor in CCS, enable the "Halt-on-reset" function, perform a System Reset and then attach normally in a halted state before boot code has been run.

    Thanks, very much appreciate the help.

  • 0 in reply to Nuri Eady
    TI__Expert 3205 points
    The state of the device EMU1 and EMU0 pins are latched at power-on. A value of EMU1=1 and EMU0=0 will activate Wait-In-Reset (WIR) mode. WIR will extend reset to each of the CPUs until a debugger has an opportunity to attach and halt to them. EMU1 and EMU0 should be connected to the XDS debug header.

    From a snapshot earlier in this thread it seems that you are using an XDS200 class debug probe which is capable of driving these two pins. Here are the steps you should follow:

    1] In the advanced settings of your target configuration, you will see a property for "The JTAG nTRST Boot-Mode" and "The Power-On-Reset Boot-Mode". Configure both of these to "Enabled - EMU1 is high, EMU0 is low".

    2] Launch the updated configuration by opening the debug view (click on the bug icon).

    3] Now you can power-up your target, release resets like you normally would (they will be extended internally).

    4] Connect to the core(s) you wish to debug.