• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 4 answers
  • Subscribers 104 subscribers
  • Views 789 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.

TDA4VM: Which Debug signals are required in mass production?

Hui-Liu
Expert 1420 points
Part Number: TDA4VM
Other Parts Discussed in Thread: SYSBIOS

Which Debug signals are required in mass production?

For example,

There are so many TRC_DATAx in the JTAG MIPI60 CONNECTOR of TDA4 CPB(Common Processor Board), are they necessary? 

There is also a XDS110 debugger on the CPB, which can be deleted, right?

  • 0
    TI__Mastermind 46440 points

    The XDS110 is a emulator/debugger - and would not be needed in a production environment.  Regarding how much access to Debug/TRC_DATA signals you need in a production environment - you should not be doing much debug in a production environment.  I would say access to test points for JTAG signals should be sufficient.  The TRC_DATA can operate in different widths - only affects interfaces bandwidth.  Can be configured as low a single bit - or as large as 24bit.

  • 0 in reply to Robert Eschler
    TI__Mastermind 20555 points

    A couple of additional comments:

    I agree that making test points for the JTAG signals is needed.  In addition to those making sure EMU0/EMU1 available is good practice. These 2 pins are sampled at boot and can determine the debug mode (functional, BSDL, wait-in-reset) and at runtime, they have some linkage to the triggers which exist in the C6x DSP.  If your board shop uses BSDL for checkouts then they will need to be able to drive the state of these signals.

    As far as TRACE signals go.  It depends on how SW wants to leverage external trace.  If they don't need this, but you have space, I'd suggest providing what you can.  Minimally the TRC_CLK and a TRC_DATA0.  It only makes sense for TDA4 to export them sequentially.  A DATA0 and DATA1 would make sense but a DATA0 and DATA2 would not.  Exposed DATAx trace pins provide a way to hook up a receiver which can do long run non-intrusive logging. The higher the rate of the trace source the more pins which would be needed. You will find some tool vendors provide safety certification packages that leverage trace so there can be concrete needs depending on the SW. Most users would likely offer full debug on prototype boards then optimize it away for production.

  • 0 in reply to Robert Eschler
    Expert 1420 points

    Thanks a lot.

  • 0 in reply to Richard Woodruff
    Expert 1420 points

    Do I need to keep MCU GB ETHERNET part for debug? As shown in the figure below.

  • 0 in reply to Hui-Liu
    TI__Mastermind 20555 points

    What other ports you may need for field debug will depend on your application.  For your development board, you will want UART ports exposed and ethernet can be very useful.  Most of the example TI firmware and software will emit messages to domain-specific UARTs. For full debug of all domains concurrently this can mean multiple UARTs.  The software can be changed to just use one, but if 3 master systems (A7x-application, DSP-RTOS, MCU-safety) all are writing to the same single UART the outputs sometimes can be intermixed causing usability issues.

    A typical flow might be to prototype on EVM (all debug available), then move to an application-specific development board that provisioned for application-specific debug, then finally go to a production board.  In final the production board, leaving at least a path for JTAG and a UART should be the minimum. You might choose to not populate the headers but it should be possible to somehow add at least wires. The need for additional interfaces will depend on your application SW's needs and physical end unit constraints.

    It is a good idea to consult with your systems and software teams to understand their usage.  If an in-field system doesn't come up for some reason what methods will be there to debug it...   Some customers include some simple flash parts which can capture trouble codes of some sort.  They then ensure the results can be uploaded from the target through some means.

  • 0 in reply to Richard Woodruff
    Expert 1420 points

    Thanks for your reply.

    Now Our Software Team need a RJ45 for debug, so we have questions below:

    1, Which RGMII is better for debug? 

    2, the difference between MCU RGMII and PRG0 RGMII or RGMII, which is better for debug? I find the TDA4 CPB(EVM) use MCU RG ETH at first.

  • 0 in reply to Hui-Liu
    TI__Mastermind 20555 points

    Hello,

    I got the following recommendation from another Engineer working in this area:

    The general recommendation is to use MCU RGMII which is connected to CPSW_2G. CPSW_2G has a single MAC port, hence it’s seen as a MAC interface.

    The other RGMII instances are connected to CPSW_9G (or CPSW_5G). CPSW_9G is an Ethernet switch peripheral, hence it’s not best suited for debugging tasks.

    The other paths could be made to work but would require more custom effort which is not in line with our normal usage.

  • 0 in reply to Richard Woodruff
    Expert 1420 points

    Thanks a lot.

    Can you tell me the relationship between MCU domain and Main domain? And how Linux use them?

    For example, Our Software Engineer told me that Linux can use MCU RGMII.

    Can Linux use other parts of the MCU, such as MCU MCAN, MCU TIMER IO and MCU WAKEUP IO?

    If so, why are they called the MCU Domain? what is so special about the MCU Domain?

  • 0 in reply to Hui-Liu
    TI__Guru 51042 points

    Hui, Can you start a new thread w/ your additional questions?  This will help to get the right person assigned.

    Thanks,

    Kyle

  • 0 in reply to kcastille
    TI__Mastermind 20555 points

    Hui,

    Yes, I agree with Kyle, that the questions are not moving into other domains.  Keeping the threads focused helps get the best answers. Please create new threads.

    A high-level response to what you asked is like this... the SOC's hardware is partitioned such that it supports many different usage models. In some complex models you might have 3 different independent but often cooperating software entities running.  For example, Linux running a user interface using the display controller DSS & graphics GPU (from the Cortex-A72), an embedded RTOS like TI/SYSBIOS running an automotive ethernet stack from a Cortex-R5-main,  and some safety monitor running on the Cortex-R5-MCU.  In that use model its easier to implement and debug if each software group uses private peripherals.  Sharing is possible by adding code abstractions or using hardware virtualization IPs but that more complex. In the end, your software team needs to relay how they plan to use the hardware and this can help you figure out what interfaces 'must' be there and which ones you 'might' need to 'provision' for to support future use cases.

    Regards,

    Richard W.