• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 952 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.

TDA4AL-Q1: can't use trace32 to flash and debug TDA4AL board

li liu
Intellectual 530 points
Part Number: TDA4AL-Q1
Other Parts Discussed in Thread: TDA4VL, TDA4VM

We plan to use trace32 to flash and debug our TDA4AL board, but currently we have encountered some issues:

1.The trace32 we are currently using is an ARM-26->TI-16 Pin connector, and our TDA4AL board has reserved a 10Pin interface. Our wiring diagram has been uploaded to the attachment (TI-16_TDA4AL-10 Pin_connect), and we need help to confirm if it is correct.

2. Currently, when we use TRACE32 software to debug the TDA4 board, there will be a debug port failed error, and then click CPU ->System Settings ->DETECT to run. However, once executed the file _J721S2_allcoretypes_connect.cmm will report error "debug port failed", Could you please confirm if this issue is related to the license or other issues? Please refer to the attached issue_video.mp4.

  • 0
    TI__Mastermind 23715 points

    Hello,

    Thanks for the video, it is very helpful in understanding the details.  It looks like the adaptor references you are using are based on a tricore jtag stack up and not the arm stackup.   A typical connection I see is from the TRACE32 ARM defined ARM-20 debug cable to a TI (cTI20 or TI14) or a MIPI (10/20/34/60) adaptor then to the SOC.  I would suspect these would prove to be the most robust and performant connection.  That said, I have just used patch wire for quick tests the to go from the TRACE32 debug cable to SOC headers and can work at lower speeds.

    Here is the appropriate reference point for ARM cables and adaptors:  https://www2.lauterbach.com/pdf/app_arm_jtag.pdf 

    It looks like you might be using tricore's auto-26 and a tricore16: https://www2.lauterbach.com/pdf/app_tricore_ocds.pdf 

    Do you have a TRACE32 ARM debug cable you can use?  Since your video shows ARM targets, and your system.detect shows an TDA4VL (0x0BB7502F) probably the basic connection is OK.  I scan ~56MHz with the same test with an ARM to TI cable stackup so your rate of ~8MHz implies a lot of bad noise.   I can see a case where you might daisy chain a few cpus on jtag and need a mixed arch+vendor cable, but having a dedicated header for each probably is better.
    The debug port fail could be due to the poor signaling, if so you could try and slow it down more and use CTCK (system.jtagclock CTCK 1MHz).  It also could be a result if you are using an HS device type along with trying to touch the Cortex-M core, access needs are different for these types.  BTW, in your video you tried to attach to a TDA4VM:J7ES-DMSC-M3 but they won't really work the same for a TDA4VL:J7AEP-TIFS-M4 setup.  You should use J721S2-CM4-0 first then if that does not work try J721S2-CR5-MCU.  The the R5 works but not the M4 you have an HS device.  You can use WIR as in scripts for board check out or just defer M4 connections until later after firmware is up.
    I will attach a current version of the scripts for TDAV4VL.  The archive has a password of TRACE32.  It will be better suited for the first phase bare metal board checkout across device types.   /cfs-file/__key/communityserver-discussions-components-files/791/4237.cmm_2D00_tda4v_5F00_j721s2.7z
    Regards,
    Richard W.