• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 605 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.

DRA829V: Hardware support to freeze the whole processor per Debugger

user6432699
Prodigy 80 points
Part Number: DRA829V
Other Parts Discussed in Thread: DRA829, TDA4VM,

Hello,

Is there a possibility to hold all the clocks of the DRA829 / TDA4VM together (synchronously) with a Lauterbach Trace32 Debugger? At least for the cores it will be useful.

I did not find this information in the TRM (spruil1b), the chapter On-Chip Debug is empty.

Thanks

Laurent

  • 0
    TI__Mastermind 24025 points

    Hello Laurent,

    Yes, it is possible to freeze a resource in conjunction with the halt of a core.  A register per freezable device exists which can link it to a core.  I provide some comments along with some example CMM scripts I use.

    Here is the note with an example you can use on DRA829V.

    Fullscreen suspend-mapping.txt Download 
    Peripherals can be frozen when a core is put into debug halt if a suspend signal is 
associated between a core and a peripheral.  This can be useful for debug of peripherals
which have running timers, watchdogs, or DMAs.

Suspend CPU mapping:
============================
Suspend Router: @APB:0x9D300000 | @AXI:0x4C:0x3D300000   

CPU Suspend Input mappings:
-----------------------------
0     => unused
1,2   => A72-0,A72-1
9     => C7x
17,18 => MCU-R50, MCU-R51
19,20 => MAIN0-R50, MAIN0-R51
21,22 => MAIN1-R50, MAIN1-R51
23/24 => C660, C661

Peripheral Outputs (0-127 slots):
----------------------------------
main timers main_0 to main_19 are mapped to slots 58 to 77 
mcu timers mcu_0 to mcu_9 are mapped to slots 89 through 98

MCU-TIMER0 is in slot 89  (89+1) x 4 = 360 = 0x168 
  @APB:0x9D300168         - debug address plane
  @AXI:0x4C:0x3D300168    - 64bit-system address

stop timer if "MCU-R50" is halted by writing:
  Data.Set EAPB:0x9D300168 %LE %Long (0x10000|17.)
  or Data.Set AXI:0x4C:0x3D300168 %LE %Long (0x10000|17.)

stop timer if "A72-0" is halted by writing:
  Data.Set EAPB:0x9D300168 %LE %Long (0x10000|1.)
  or Data.Set AXI:0x4C:0x3D300168 %LE %Long (0x10000|1.)

    I'll attach a current version of scripts which this is included with. 

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/8737.cmm_2D00_tda4_5F00_dra829.7z

    Regards,

    Richard W.

  • 0
    Prodigy 80 points

    Hello Richard,

    thank you very much for your answer and the detailed scripts.

    I look through many of the CMM files but could not find such kind of information:
    - Belong the cores also to "freezable devices" in this context?
    - In other words: is it possible to link cores with cores, in order to freeze all the cores simultaneously?

    Best regards
    Laurent

  • +1 in reply to user6432699
    TI__Mastermind 24025 points

    Hello Laurent,

    The suspend-mapping.txt file I highlighted links clock stop of a CPU to attached peripherals but not to other cores. With TRACE32 the stopping of other cores is also possible but the time to freeze is variable depending on event signaling method used. Through the use of the "synch" command set you can link cores to get synchronous operation (go/break/step).  You can explicitly link named cores or connect to all cores which have a controlling PowerView instance open.

    For example:

     IC ALL SYnch.CONNECT OTHERS
     IC ALL SYnch.MasterBreak ON
     IC ALL SYnch.MasterGo ON
     IC ALL SYnch.SlaveGo.on
     IC ALL SYnch.SlaveBreak.ON
     IC ALL SYnch.ON
     IC ALL SYnch.Xtrack others
     

    TRACE32 always supports software synchronized halts over channels where tool to tool messages are passed.  Also it supports hardware synchronization when available and configured. In DRA829V the cores events and actions are linked by coresight CTM/CTI networks at the CPU cluster and system level.  The debugger will have configured the SMP cluster's CTI/CTM settings to allow coupled operations. In these case the HW operation would happen before any possible SW operation.  Cross core halting will never be exactly synchronous (though single stepping should be possible) so there will always be some delay from event to halt action for cores.  In the case of SW perhaps its in low mS to high uS, in the case of HW it should be somewhere in the lower uS range.

    I would recommend setting up synch a synch group with all the cores you want to observe and see if the result solves the scenario you are looking to address. If you think faster event to action resolution is needed probably its best to take that up with Lauterbach support so they can help change path options.  If you manually program things you need to know how to coordinate with the debugger so it will not overwrite your settings.  It is possible to specify coresight components in the system to allow for this coordination. 

    Regards,

    Richard W.

  • 0 in reply to Richard Woodruff
    Prodigy 80 points

    Thanks a lot, Richard. It should be enough with the SYNCH method for our scenario. If we need faster reaction times or more specific features, we will contact Lauterbach.

    Best regards, Laurent