AM4372: Debug AM4372 from XDS110 on board of siplelink MCU launchpad

There are two components to your question, one is related to hardware functions of AM437x and the other is software expectations of Code Composer Studio (CCS).

I can only address questions related to hardware functions of AM4372.

I can see where the CC1352 launchpad provides connections to the basic JTAG signals via level-shifters. The AM4372 IOs are not fail-safe, so the IOs of attached devices need to be powered from the same IO power source as any attached device. Therefore, you would need to configure the CC1352 launchpad to power the AM4372 side of the level-shifters with the same IO supply that is used to power the respective AM4372 JTAG IOs. 

The level-shifters implemented on the CC1352 launchpad will introduce delay in the signal path, which may significantly reduce the maximum operating frequency of the JTAG interface. The JTAG interface was designed to launch signals on one edge of clock and latch signals on the other edge of clock, which allows setup and hold time requirements to be met by simply reducing the JTAG clock frequency as necessary to provide adequate timing margin for the interface. If you have specific bandwidth requirements, you may need to perform a timing analysis of the interface using setup/hold requirements and switching characteristics of the CC1352 launchpad, setup/hold requirements and switching characteristics of AM4372, along with delays introduced by PCB signal traces and cables. The setup/hold requirements and switching characteristics of AM4372 can be found in the AM437x datasheet.  I do not know where to find this information for the CC1352 launchpad. The other option would be to connect AM4372 JTAG signals to the CC1352 launchpad and adjust JTAG clock frequency until the interface works.

I also noticed the CC1352 launchpad does not provide any EMU signals. I'm not sure what debug functions can be implemented by CCS without these signals. This topic ventures into CCS software expectations, which I can not address. There may be a dedicated forum for CCS questions, but I'm not sure. If so, you should ask a similar question on that forum to get feedback on using XDS110 integrated on the CC1352 launchpad from the CCS team.

Regards,
Paul

This is a little out of my area of expertise but the document here shows what CCS uses the EMU pins for.

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds_target_connection_guide.html#emu

Bootmodes

Cross triggers

HS-RTDX

Trace

Cross-triggers are used when you have multiple devices on the same scan chain which I don't believe is applicable here.  HS-RTDX is obsolete so that is not a concern.  Trace to pins requires the use of a trace receiver like an XDS PROTRACE so that is not applicable when using an XDS110.

Regards,

John

Only EMU0 and EMU1 are used for boot modes. These pins are latched on the rising edge of reset. The state of these inputs should be defined by external pull resistors. Typically both pins are pulled high for normally operation. However, the device can be place in wait-in-reset mode when EMU0 is pulled low, EMU1 is pulled high, and these logic states are latched on the rising edge of reset. The wait-in-reset mode is mostly used when trying to resolve issues with one of the ROM boot functions.

Based on John's feedback, it sounds like you should be able to use the XDS110 integrated on the CC1352 launchpad if you make the appropriate power and signal connections. However, frequency of operation my be limited due to delays introduced by the level-shifters.

Regards,
Paul