• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1342 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.

OMAP3530: Using Eclipse XML register descriptions for OMAP3xxx to create register dumping utility...

tshelbur
Intellectual 1310 points
Other Parts Discussed in Thread: OMAP3530

I have created a tool for other ARM9 devices that dump all system registers for a device before. I have done this using brute force register descriptions and hard coded programs to dump register sets to s serial console.

I am looking for a way to automate the generation of an application that can dump registers for new devices by using the XML descriptions of the device it self (in this case OMAP3530) to generate include files that I can build a generic application against to dump device registers to avoid all of the custom work involved with creating such an application.

Is it possible to use CGXML or some other tool chain to walk through these device specific XML files (i.e. ..\ccsv4\common\targetdb\Devices\OMAP3530.XML and other referenced XML files for specific peripheral instances) and generate "C" formatted tables of data that could be used to drive creating a register dumping application that does not require as much custom coding?

Here is an example of the output that my DRA446 register dumping tool produces (brute force code does this); this lists virtual and physical address used running under QNX in this case along with register value and register name (matching documentation names. This has proven to be invaluable because we can actually dump register settings from two different boards and diff the results to find differences in settings. This has allowed us to find customer problems/bugs very quickly in the past...

Jacinto (TMS320DRA446) Register Dumper Version 1.1
-v1
-a

Dumping PLL0 Control Registers
VA: 0x01800C00, PA: 0x01CA1C00
Adr: 0x01CA1C00, Val: 0x0001080D, Reg: PID
Adr: 0x01CA1CE4, Val: 0x00000001, Reg: RSTYPE
Adr: 0x01CA1D00, Val: 0x00000049, Reg: PLLCTL
Adr: 0x01CA1D08, Val: 0x00800000, Reg: SECCTL
Adr: 0x01CA1D10, Val: 0x00000015, Reg: PLLM
Adr: 0x01CA1D18, Val: 0x00008000, Reg: PLLDIV1
Adr: 0x01CA1D1C, Val: 0x00008002, Reg: PLLDIV2
Adr: 0x01CA1D20, Val: 0x00008003, Reg: PLLDIV3
Adr: 0x01CA1D28, Val: 0x00008000, Reg: POSTDIV
Adr: 0x01CA1D38, Val: 0x00000001, Reg: PLLCMD
Adr: 0x01CA1D3C, Val: 0x00000006, Reg: PLLSTAT
Adr: 0x01CA1D40, Val: 0x000001FF, Reg: ALNCTL
Adr: 0x01CA1D44, Val: 0x00000000, Reg: DCHANGE
Adr: 0x01CA1D48, Val: 0x00000003, Reg: CKEN
Adr: 0x01CA1D4C, Val: 0x0000000B, Reg: CKSTAT
Adr: 0x01CA1D50, Val: 0x000001FF, Reg: SYSSTAT
Adr: 0x01CA1D60, Val: 0x00008003, Reg: PLLDIV4
Adr: 0x01CA1D64, Val: 0x00008005, Reg: PLLDIV5
Adr: 0x01CA1D68, Val: 0x00008003, Reg: PLLDIV6
Adr: 0x01CA1D6C, Val: 0x00008005, Reg: PLLDIV7
Adr: 0x01CA1D70, Val: 0x00008016, Reg: PLLDIV8
Adr: 0x01CA1D74, Val: 0x00008000, Reg: PLLDIV9

Dumping PLL1 Control Registers
VA: 0x01800000, PA: 0x01CA2000
Adr: 0x01CA2000, Val: 0x0001080D, Reg: PID
Adr: 0x01CA20E4, Val: 0x00000000, Reg: RSTYPE
Adr: 0x01CA2100, Val: 0x00000049, Reg: PLLCTL
Adr: 0x01CA2108, Val: 0x00800000, Reg: SECCTL
Adr: 0x01CA2110, Val: 0x0000001A, Reg: PLLM
Adr: 0x01CA2118, Val: 0x00008000, Reg: PLLDIV1
Adr: 0x01CA211C, Val: 0x00008001, Reg: PLLDIV2
Adr: 0x01CA2120, Val: 0x00008002, Reg: PLLDIV3
Adr: 0x01CA2128, Val: 0x00008000, Reg: POSTDIV
Adr: 0x01CA2138, Val: 0x00000001, Reg: PLLCMD
Adr: 0x01CA213C, Val: 0x00000006, Reg: PLLSTAT
Adr: 0x01CA2140, Val: 0x000000FF, Reg: ALNCTL
Adr: 0x01CA2144, Val: 0x00000000, Reg: DCHANGE
Adr: 0x01CA2148, Val: 0x00000003, Reg: CKEN
Adr: 0x01CA214C, Val: 0x0000000B, Reg: CKSTAT
Adr: 0x01CA2150, Val: 0x000000FF, Reg: SYSSTAT
Adr: 0x01CA2160, Val: 0x00008002, Reg: PLLDIV4
Adr: 0x01CA2164, Val: 0x0000800B, Reg: PLLDIV5
Adr: 0x01CA2168, Val: 0x00008001, Reg: PLLDIV6
Adr: 0x01CA216C, Val: 0x0000800B, Reg: PLLDIV7
Adr: 0x01CA2170, Val: 0x0000800B, Reg: PLLDIV8

.

.

.

  • 0
    TI__Guru**** 162305 points

    Tom,

    Parsing the device xml files would be a big job.  There is a way to dump the registers to file.  It doesn't give you the values but you could use it to get all the names.  You need to use DSS to do it.  Personally I would probably write the DSS script in Perl as you will need to do some parsing of the output.

    You could write a script that:

    -launches a debug session or connects to an already existing one

    -dumps the register list

    -loops through the list extracting the name from the text file, calling an API to get the address and calling an API to get the value and outputting all 3

    The API to call after the openSession in your DSS script is listed below.  Each line in the file will have the connection name, cpu name, register group and register name...  Note that this is not an API that we publish in the standard docs (typically just used internally for testing.

    debugServer.listRegisters("c:/registers.txt")

     

     

  • 0 in reply to JohnS
    TI__Intellectual 1310 points

    Are these scripts supported in both CCS 3.3 and in the new eclipse based CCS v4.x? Are these debug scripts going to be available for years if I take the time to write a script that uses these API's?

  • 0 in reply to tshelbur
    TI__Guru**** 162305 points

    Thomas,

    DSS is only available in CCSv4 and later.  DSS scripts will be supported for many years, much of our test infrastructure is dependent on them.

    Regards,

    John