RVI TMS570 target platform

Hello Edna,

We are reviewing this and will get back to you.

Regards,

Diwakar

Hello,

Can you please clarify which device part number and which version of the ARM debug tools are in use?  I have not used the ARM debug tools in several years but hope I can still be of some assistance.

I suspect what is happening is that the ARM tool has not set up the ICEPICK or AJSM modules to configure access to the Coresight debug domain scan chain.  The ARM tools have historically had issues in managing this interface.  This could be exacerbated due to use of the TMS570PSF762 configuration - this product is an older multi-core design with a Cortex R4 and a Cortex M3.  The '762 has a slightly different debug configuration as necessary to support both CPUs (multiple CoreSight domains, one for R4 and one for M3 as ARM did not make M3 fully CoreSight compliant).  Note that '762 has ICEPICK but not AJSM.

The error message of failing to write at 0x0 is to be expected unless you define this memory range as non-volatile in the debugger.  Most debuggers expect all memory to be volatile, read/write capable, but these products map flash at 0x0 which is read only.

Best Regards,

Karl

Thanks you for the reply , I'm working whit ARM develelopment Studio DS-5 (5.9 ) which contains RVI software , then I am using Real View Ice , this is an old version whose frimware was updated by  RVI update (current version 4.3).

First, I will contacte ARM support about ICEPICK / AJSM modules and RVI Ice compatibility

Second, according to memory range used by the debugger on TMS570LS20216 The Core Sigth is acceded throught  APB bus (Peripherals)  For this reason I changed the default configuration :

Basse addresse (cortex R4 core)= FFA01000

So, I agree with you about  non-volatile memory definition however I dont  think that the memory which will be accedded is the same data  memory defined in  0x08000..addresse

Hi Edna,

It may have caused a problem when you remapped the address of the CoreSight debug peripheral frame.  The debug tools typically access this frame via the APB-AP interface in the DAP module.  The APB-AP does not have the same memory mapping as the CPU.  The APB-AP sees the debug peripheral frame starting with a base address of 0x0000_0000.  Because bit #31 is used to indicate APB-AP bus master access, this might also be represented in the ARM tool as 0x8000_0000.  I apologize that I am not familiar enough with ARM's current tool offerings to be of more assistance here.

The debugger will typically be accessing the coresight peripherals via this path:  JTAG --> ICEPICK --> DAP JTAG-AP --> DAP APB-AP --> APB MUX --> CoreSight Frame.

The CPU can only access the coresight peripherals via this path:  CPU --> PCR --> APB MUX --> CoreSight Frame.  The PCR will strip the upper address bits off the transaction when passing it to the APB MUX such that the addressing is consistent for the CoreSight frame.

Once the base address of the frame is established, the CoreSight compliant debug modules should be accessible every 4kB.

Best Regards,

Karl