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.

EMU0/1 Signal definitions

Other Parts Discussed in Thread: TPS65920, OMAP3530

Scanning through the OMAP3 documentation I can't find what the state definitions of the JTAG_EMU0 and JTAG_EMU1 pins mean.  I have compared the pins on the Mistral EVM and on the Beagleboard.  The Mistral EVM has a dip switch for both the EMU0 and EMU1 which allows the user to "enable the JTAG" when the EMU0 pin is pulled Low(switch on) and when the EMU0 pin is High(switch off) the "JTAG is disabled".  On the Beagleboard this pull down or jumper on the EMU0 pin has been removed but it claims you can still use the JTAG connector for debugging the OMAP3.  So I don't quite understand what happens when EMU0 is low or high? 

In our design I would like to use the JTAG interface for both OMAP3 debugging, just peeking and poking using the XDS510 emulator as I know it's not OS aware, and also use the JTAG interface for Boundary Scan on the OMAP3.  I would like to also have the TPS65920 on the JTAG chain.  Do you see any problems with the TPS65920 on the same JTAG chain as the OMAP3?

 

Thanks for your help,

Gary

  • Traditionally on C6x devices the EMU0 and EMU1 pins would be pulled high for normal operation for debugging, and would be pulled low for boundary scan mode, however for the OMAP3 it seems that one should have these pins pulled high at all times. My suspicion is that the dip switches on the mistral EVM are either a hang over from a prior design, or that there may be some internal test modes with EMU values of other than 1. A brief description of the EMU0 and EMU1 pins and the mention that they should always be high at power up is given in section 25.6.3 of the OMAP3 TRM. I have not done any boundary scan work on the OMAP3, but based on the wording in section 25.6.3 it would seem that your boundary scan tool would have to do any configuration at the initial TAP router level to configure the device for boundary scan.

    The TPS65920 seems to be a standard JTAG device, so as long as whatever debugging tool you are using allows you to put in a bypass for the device as needed I see no problem putting them together in the same chain. Note that the TWL4030 on the OMAP3 EVM also has a JTAG interface that is just left disconnected so it seems you may not need this debugging interface on the power management chip, though I suppose the boundary scan could be handy.

  • FWIW, EMU0=0 corresponds to a "wait in reset" state.  So rather than the ARM starting to execute from the boot ROM when reset is de-asserted it instead just sits there in reset.  I did some searching trying to find where that's located in the docs but couldn't find it.  I stumbled across that info at some point...

    Generally speaking I recommend just setting EMU0=EMU1=1.

    Brad

  • Maybe

    http://elinux.org/OMAP3530_ICEPICK

    can help a little, too. It mentions that "documentation for the control of EMU0/EMU1 is very misleading", though ;)

    I think above recommendation EMU0=EMU1=1 is the best (correct?) way to go, too.