• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 440 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.

AM6548: APB-AP Memory Map for on-board debugging

Will Hwang
Intellectual 280 points

Part Number: AM6548

Hello,

Could you please provide the APB-AP Memory Map for on-board debugging?

I am currently trying to get the JTAG debugging working with the TI adapter on AM6548 board.

Chapter 13.6 in TRM (spruid7e.pdf) is named "Debug Memory Map", and is where I would expect to find the APB-AP memory map, but instead it includes a block diagram and points the reader to "the Memory Map chapter", which seems to be Chapter 2.

However, I find it extremely difficult to connect the Chapter 2's memory map to the block diagram in Chapter 13.6.

Thanks,

Will

  • 0 in reply to Will Hwang
    Intellectual 280 points

    Ping. again.

    Is it possible to get some kind of reply to this?

    We have a customer that is interested in having this board ready by sometime next month.

  • +1 in reply to Will Hwang
    TI__Mastermind 25605 points

    Hello Will,

    Based on the message I am guessing you are looking to add support for GHS for one of the AM65xx SOCs. There are several ways to get at the base addresses for the debug components. The default way is to follow the ARM standard which defines how tools should interrogates the ROM table at the base of the APB (on APSEL 1). If you use your debuggers scan feature or directly dump the table you will be able to find the standard coresight component addresses directly on the target.  If its easiest to do this after the TI firmware has run, as it would have started the necessary power and clocking resources for possibly dependent domains.  For example the A53 cluster if off at reset but the firmware will power it on as part of the boot flow.  The debug components which you are need to get at are accessible in both the APB address space and the system address space as described in chapter 2 of the TRM.  The memory spaces lower addresses overlay on each other so that you can use the addresses found in the memory map chapter for the APB after truncating and adjusting the upper nibbles. You can identify the debug resources as they have the string DEBUGSS in them. The debug space on ABP (APSEL 1) uses a 32 bit address where the AXI-AP (APSEL 2) can use the TRM address directly.

    To speed up the process or discover the addresses statically you can also look directly at public examples in other tools.  TI's CCS exposes the address in its xml in the "common/targetdb/devices/<soc>.xml, e.g. DRA80xM.xml is an AM65xx SOC.  Also, the open tool OpenOCD enumerates them in its public repos, see commit http://openocd.zylin.com/5952, the core base address aspect are here http://openocd.zylin.com/#/c/5182/3/tcl/target/ti-k3.cfg.   I do believe the GHS tool has basic support for the TDA4 SOC which shares the same base debug architecture.  It will be possible to leverage that for enablement also, though some of the addresses will be different.

    Regards,

    Richard W.