How do I view the contents of the peripheral registers (EDMA.McASP,etc) of the TMS320DM814x using Code Composer?
I am using Code Composer version N201105110900 as a standalone debugger.
Is there a configuration file I need?
Hi,Sorry, unfortunately we don't have viewable peripheral registers for DM814x/DM816x/C6A816x/AM387x/AM389x families of devices. You would need to open a Memory browser and set its address to the register's address - these are listed in the device's Technical Reference Manual at: http://www.ti.com/litv/pdf/sprugz8aI apologize for the inconvenience,Rafael
Hi Graham,
Following your answer:I find this unacceptable, this was to be my reply: Except SPRUGZ8a doesn't give the registers address -- just the offset and description -- the addresses are listed in another document, the data sheet, SPRS614B. Having to use two different large documents to figure out register contents and register decoding not be supported by the debugger is just stupid. Analog Devices manage it fine. This is a very complicated device, it needs decent tools to effectively use it. Are there any plans to support register decoding in the debugger or even a single document describing the registers?
I understand your point as it is quite ineficient to have to open multiple documents just to find out the address and bit felds.
It seems that in some previous version of CCS you could customize the memory windows to displays different registers using XML. I am not sure if it is possible with the actual version of CCS for DM814x. May be Rafael will be able to confirm:http://processors.wiki.ti.com/index.php/Creating_Custom_Memory_Mapped_CCStudio_Register_Windowshttp://processors.wiki.ti.com/index.php/TargetDB_XML_Specificationhttp://processors.wiki.ti.com/index.php/Board_XML_files_-_Creation
Best regards,
Anthony
Anthony, Graham,
Yes it is possible to customize the Registers view to display the desired registers using XML files.
If you want to add this support yourself, I strongly suggest you take a look at the references sent by Anthony and use some of the existing multicore devices that already have support (like the OMAP3530, OMAP4430, etc.).
CCSv5.2 will have added support to the existing devices, but I haven't yet heard any plans for these specific device families. Sorry.
Regards,
Rafael
Yes I found those files from the information provided by Anthony. I am in the process of customising one file for my purposes.
I was given the impression that the family of devices were something TI were actively promoting.
So it is surprising that a released product doesn't have full support from the toolset. Especially as it doesn't look like that big a job fro someone familiar with the XML files.
I also find it surprising that I wasn't told about it earlier. I find this an issue with TI in that I have to make a fuss to actually get information that is readily available.
I do make an effort to solve issues myself but Code Composer and the device itself as well as all the associated s/w and documentation is complicated and extensive. So I have to make use of support services to help me find my way. When I contact the support services I do expect some effort to be made. Each time I contact TI support it seems I have to make a nuisance of myself to get results.
I have attempted to edit the standard ti816x.xml to insert some register definition taken form the OMAPL138 which has identical peripherals.
I have modified the CortexA8 cpu node like so
<instance XML_version="1.2" desc="CortexA8_0" href="cpus/cortex_a8.xml" id="CortexA8" xml="cortex_a8.xml" xmlpath="cpus" /> <cpu HW_revision="1.0" XML_version="1.2" desc="CortexA8" description="Cortex_A8 CPU" deviceSim="false" id="CortexA8" isa="Cortex_A8"> <property Type="numericfield" Value="0x80001000" id="Address" /> <property Type="filepathfield" Value="../../../emulation/boards/dm816x_evm/gel/evm816x_mem_map.gel" id="GEL File"/> <instance href="../Modules/OMAPL138_C6748/rCSL_mcasp_001.xml" id="McASP0ARM" xml="rCSL_mcasp_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP" requestor="CortexA8" baseaddr="0x48038000" endaddr="0x48038FFF" size="0x1000" accessnumbytes="4" permissions="p" /> <instance href="../Modules/OMAPL138_C6748/rCSL_afifo_001.xml" id="McASPFIFO0ARM" xml="rCSL_afifo_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP FIFO" requestor="CortexA8" baseaddr="0x48039000" endaddr="0x48039FFF" size="0x1000" accessnumbytes="4" permissions="p" /> <instance href="../Modules/OMAPL138_C6748/rCSL_mcasp_001.xml" id="McASP1ARM" xml="rCSL_mcasp_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP" requestor="CortexA8" baseaddr="0x4803C000" endaddr="0x4803CFFF" size="0x1000" accessnumbytes="4" permissions="p" /> <instance href="../Modules/OMAPL138_C6748/rCSL_afifo_001.xml" id="McASPFIFO1ARM" xml="rCSL_afifo_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP FIFO" requestor="CortexA8" baseaddr="0x4803D000" endaddr="0x4803DFFF" size="0x1000" accessnumbytes="4" permissions="p" /> <instance href="../Modules/OMAPL138_C6748/rCSL_mcasp_001.xml" id="McASP2ARM" xml="rCSL_mcasp_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP" requestor="CortexA8" baseaddr="0x48050000" endaddr="0x48050FFF" size="0x1000" accessnumbytes="4" permissions="p" /> <instance href="../Modules/OMAPL138_C6748/rCSL_afifo_001.xml" id="McASPFIFO2ARM" xml="rCSL_afifo_001.xml" xmlpath="../Modules/OMAPL138_C6748/" HW_version="Matrix" description="McASP FIFO" requestor="CortexA8" baseaddr="0x48051000" endaddr="0x48051FFF" size="0x1000" accessnumbytes="4" permissions="p" /> </cpu>
The registers appear in the register view but the register values are not displayed. The message "Error:Unable to read" is displayed in red. The memory is accessible in the memory viewer. I suspect that it is looking in CPU space rather than physical address space as when I click "View Memory at Address" it views it in CPU space.
I don't really understand what the requestor field should be set to. The documentation says this:
requestor: the target that the register group should be associated with
whilst failing to specify what target is.
What really really annoys me is that this should have been done by TI. I should be developing a new product for my company not messing about with inadequately documented esoteric XML code.
Graham,
The register view doesn't access physical memory to view peripheral registers. There's two bugs tracking this (as it requires changes to two separate modules to function) - SDSCM00044313 and SDSCM00041854.
In the mean time, you can work around this using a custom struct and the @phy attribute in the expression view. First, define a struct that looks like the registers at the peripheral you want to view (if you don't want to pollute your own application, put it in another project and just add the symbols after loading your regular application). Something like:
struct MyPeripheral { int firstRegister; int secondRegister; ...}Next, view this in the expressions view at the fixed physical address by specifying "@phy". Something like "(MyPeripheral*)(0x48000000@phy)". When you expand this in the expressions view, the underlying members will contain values read using a physical address, not a virtual address.
Darian
Thanks for the info at least I can progress now. It would have been more useful to have told me about the bugs when I first raised the issue back in May.
Anyway for other users here is the register structure for the McASP derived from the McASP serial driver. If using in code remember to map the physical memory!
/* McASP serial driver **************************************************************************************************************/#define pad( __n , __s , __e ) unsigned char pad_##__n[__e-__s-4];typedef struct { volatile unsigned long davinci_mcasp_pid_reg ; volatile unsigned long davinci_mcasp_pwridlesysconfig_reg ; pad( a , 0x4 , 0x10 ); volatile unsigned long davinci_mcasp_pfunc_reg ; volatile unsigned long davinci_mcasp_pdir_reg ; volatile unsigned long davinci_mcasp_pdout_reg ; union { volatile unsigned long in_reg ; volatile unsigned long set_reg ; } davinci_mcasp_pd ; volatile unsigned long davinci_mcasp_pdclr_reg ; pad( b , 0x20 , 0x44 );
volatile unsigned long davinci_mcasp_gblctl_reg ; volatile unsigned long davinci_mcasp_amute_reg ; volatile unsigned long davinci_mcasp_lbctl_reg ;
volatile unsigned long davinci_mcasp_txditctl_reg ; pad( c , 0x50 , 0x60 ); volatile unsigned long davinci_mcasp_gblctlr_reg ; volatile unsigned long davinci_mcasp_rxmask_reg ; volatile unsigned long davinci_mcasp_rxfmt_reg ; volatile unsigned long davinci_mcasp_rxfmctl_reg ;
volatile unsigned long davinci_mcasp_aclkrctl_reg ; volatile unsigned long davinci_mcasp_ahclkrctl_reg ; volatile unsigned long davinci_mcasp_rxtdm_reg ; volatile unsigned long davinci_mcasp_evtctlr_reg ;
volatile unsigned long davinci_mcasp_rxstat_reg ; volatile unsigned long davinci_mcasp_rxtdmslot_reg ; volatile unsigned long davinci_mcasp_rxclkchk_reg ; volatile unsigned long davinci_mcasp_revtctl_reg ; pad( d , 0x8C , 0xA0 );
volatile unsigned long davinci_mcasp_gblctlx_reg ; volatile unsigned long davinci_mcasp_txmask_reg ; volatile unsigned long davinci_mcasp_txfmt_reg ; volatile unsigned long davinci_mcasp_txfmctl_reg ;
volatile unsigned long davinci_mcasp_aclkxctl_reg ; volatile unsigned long davinci_mcasp_ahclkxctl_reg ; volatile unsigned long davinci_mcasp_txtdm_reg ; volatile unsigned long davinci_mcasp_evtctlx_reg ;
volatile unsigned long davinci_mcasp_txstat_reg ; volatile unsigned long davinci_mcasp_txtdmslot_reg ; volatile unsigned long davinci_mcasp_txclkchk_reg ; volatile unsigned long davinci_mcasp_xevtctl_reg ; volatile unsigned long davinci_mcasp_clkadjen_reg ; pad( e , 0xD0 , 0x100 );
/* Left(even TDM Slot) Channel Status Register File */ volatile unsigned long davinci_mcasp_ditcsra_reg[6]; /* Right(odd TDM slot) Channel Status Register File */ volatile unsigned long davinci_mcasp_ditcsrb_reg[6]; /* Left(even TDM slot) User Data Register File */ volatile unsigned long davinci_mcasp_ditudra_reg[6]; /* Right(odd TDM Slot) User Data Register File */ volatile unsigned long davinci_mcasp_ditudrb_reg[6]; pad( f , 0x15C , 0x180 ); /* Serializer n Control Register */ volatile unsigned long davinci_mcasp_xrsrctl_reg[16]; pad( g , 0x1BC , 0x200 ); /* Transmit Buffer for Serializer n */ volatile unsigned long davinci_mcasp_txbuf_reg[16]; pad( h , 0x23C , 0x280 ); /* Receive Buffer for Serializer n */ volatile unsigned long davinci_mcasp_rxbuf_reg[16]; pad( i , 0x2BC , 0x1000 ); /* McASP FIFO Registers */ volatile unsigned long davinci_mcasp_wfifoctl ; volatile unsigned long davinci_mcasp_wfifosts ; volatile unsigned long davinci_mcasp_rfifoctl ; volatile unsigned long davinci_mcasp_rfifosts ;} mcasp ;
#undef pad