How to program Cortex-R4 Debug Unit within TMS570 device?

Hi Pashan,

You have two options to consider - programming via coprocessor register instructions or via sending memory mapped debug requests to the CoreSight register interface of the CPU.  The CoreSight registers for the CPU are mapped to 0xFFA0_1000 to 0xFFA0_1FFF as noted in the TRM.

ARM does not publicly disclose the debug programming model of the CPU.  However, I believe if you sign an NDA or click-wrap license on their silver.arm.com site you may be able to download the information.  I believe the critical document is the ARM Debug Interface v5 Architecture Specification.  The debug programming model is the same for the Cortex A and Cortex R CPUs.

Good luck,

Karl

Hello Karl,

Are these only registes available within the range 0xFFA0_1000 -- 0xFFA0_1FFF as shown below? or, Is there a complete list of Registers mapped at that address range?

Thank you
Regards
Pashan

Hi Pashan,

TI gives the ARM logic a 4kB chip select as required by the CoreSight programmer's model.   CoreSight defines a number of identification registers in the last region of the 4kB chip select, but beyond that the contents are up to the designer of the IP.  In this case ARM controls the data, not TI.

Please note that the CPU does not conform to the MEM-AP model you are showing in your screenshot.  An example of a MEM-AP would be the AHB-AP debug bus master logic.  Note that the MEM-AP is not programmable via CPU software, but only via a physical debug interface and Coresight DP in present ARM architecture.

If you are not finding the details of the CPU debug programmer's model in the v5 document, suggest you try the debug architecture section of  the ARM Cortex A/R Architecture Reference Manual in combination with the R4 TRM. Sorry if we don't have an immediate clear answer - this is an area where ARM's documentation could be improved.

Regards,

Karl

Hello Karl,

Things are looking better. In the Architecture Reference Manual, there is a mention of v7 and v7.1 Debug Interface Registers as shown below.
Can you please tell me which version is implemented for the TMS570LS0432 device?

Thank you.
Regards
Pashan

Hi Pashan,

Version of debug architecture is an ARM attribute - TI has no control over this point.  To my knowledge, all Cortex R4/R5 CPUs implement the v7 architecture.  I believe v7.1 is only relevant to Cortex A15 and A7, but I am not sure on this point.

Regards,

Karl

Hello Karl,

In the Architecture TRM, there are many mention of IMPLEMENTATION DEFINED. I am assuming TI documented those IMPLEMENTATION DEFINED items. In the ARM Support Mail List, they are telling that I should contact TI for these items.
Can you please tell me how to find all these IMPLEMENTAION DEFINED items as implemented within TMS570LSxx devices?

Thank you
Regards
Pashan

Dear Karl,

I'm working on In-System Application solutions for TMS570 family. I'm developing a programmer which interact to the target via JTAG debug port to download a small flashing firmware in RAM. I already support several TMS570 family devices but seems that TMS570LS0432 has a different architecture and I can't access memory map via  MEM-AP. 
I did some tests on the device in object and this is what i discovered:

* IcePick peripheral is working properly (as I read the IDCODE correctly)
* Debug Port is working properly (as I read the "Debug Control Status" correctly)
* MEM Access Port is connected properly to the Debug port (as I read the Identification Register properly). As the Identification Register is not accessing the memory I expected it would work.

My driver now is using BD0 Banked Data to access "Debug register interface" and actually Halt the core. This interface is actually memory mapped, and actually any access to this register is failing. You suggested to use coprocessor register instructions but how can I accomplish this task? Can I still use Debug Port? Is there any documentation I could read?

Thank you very much,
Samuele 

Hello Samuele,

The TMS570LSxxx products have a DAP implemented with a JTAG-DP, APB-AP, and APB-MUX logic.  All of the products excluding the TMS570LS04x/03x also include an AHB-AP in the DAP, which allows the debugger to access device memory without forcing a CPU access.

For the TMS570LS04x/03x, there is no AHB-AP interface shown in the datasheet (SPNS186).  Based on your feedback, it sounds like the designers elected to keep at least some of the logic in place but to avoid hooking it up as a bus master to the device's main SCR.

I am a bit confused by your use case - if I understand correctly, you are writing JTAG-DP --> AHB-AP --> APB-MUX --> Cortex R4 CoreSight registers.  This is an un-necessarily complex route.  The expected usage from standard ARM perspective would be JTAG-DP --> APB-AP --> Cortex R4 CoreSight registers.  Please give this a try, as it should work across all of the TMS570LSxxx products and it should also improve the performance by removing a number of un-needed clock cycles from the datapath.

Regards,

Karl

One more note - regarding the performance, my statement stands with respect to access time for managing CPU debug features.  However, if you are only performing memory operations, then the AHB-AP route will generally provide greater bandwidth.  Optimal performance solution will depend on your pattern of usage.

Regards,

Karl

Hi Karl,

thank you very much. Now I got how to modify my path toward APB bus. But I need a little help from you on how to get to the core once I've control of APB access port. On chapter 4.20.2 of device datasheet (SPNS186) there's a table which maps debug components, probably this is what I need but I'm still a bit confused.
I suppose I also need to know which bank the core registers are mapped and a register table which describes which registers are available.
Thank you very much, 

Hello Samuele,

Use the addresses in the debug rom, as per the CoreSight standard.  Each CoreSight peripheral has a 4kB memory chip select and the base address of each implemented CoreSight IP is noted in the debug ROM.  The debug ROM is always at address 0x0 on the debug bus (APB-AP).  The debug ROM shows the Cortex R4 CPU at address 0x1000 on the debug bus (APB-AP).  Note that the debug bus address of a Coresight peripheral is the same as CPU memory map address with the upper half-word removed --> i.e. 0xFFA0_0000 from a CPU access will generate an access to 0x0000_0000 on the debug bus, 0xFFA0_1000 will generate 0x0000_1000, etc.

If you don't have a copy of the CoreSight standard, you can download it from http://infocenter.arm.com.  

For details on the registers inside each CoreSight IP, you need to reference the IP specification.  For the R4 CPU, this is found in the R4 TRM.  The debug resources can be accessed by CPU software as coprocessor registers or on the debug bus (APB) via the JTAG-DP.  In the R4 TRM DDI0363E, the register mapping is noted in section 11.3.4.

Regards,

Karl

Dear Karl,

thank you, with your suggestion I've been able to access the APB-AP. The proof is that I've been able to read and write DBGDSCR register succesfully both using 0xFFA01088 and 0x1088 address.

Now I'm going to download my flashing firmware on RAM, I already noticed some differences between APB and AHB access port but my doubt is if RAM start address 0x8000000 is still addressable as it as in your last post seems that the memory map is varied (or bus width is lowered down to 16 bit).
How can I access RAM locations through ABP bus?

Sorry for my newbie question, I hope in your kindness for another clarification.
Regards, 

Hi Samuele,

Unfortunately programming the CPU's debug unit is a bit more complex than programming the AHB-AP.  The R4F TRM, ARM DDI 0363E, contains instructions of how to program the CPU's debug unit to perform basic tasks in section 11.11.  In particular, please refer to section 11.11.6, "Accessing registers and memory in debug state."   Effectively what must be done is to load a sequence of ARM instructions to the CPU by using the ITR registers in order to force the CPU to make the memory access for you.

Best Regards,

Karl

Dear Karl,

I've been able to complete the layer above and now I can write and read on RAM with success (and, of course, I can control processor registers). After writing my flashing firmware on RAM I've to setup stack register and PC register and put the core in running mode. Here' there are the following issues:

* Reading the PC before writing it returns 0xC (Prefetch Abort). How could it be possible?
* I force PC writing the entry point address of my flashing firmware (0x8000000) and reading back immediately (i mean, I don't release the core): I read 0x8000008. If i then release the core I read back again 0xC
* I write a different register (R13) with 0x8000000 and I read back correctly 0x8000000.

Have you got any idea on what is happening to my core?
Thanks for your great help, 

In addiction, DSCR register, both before and after writing PC is 0x3086803, which should be quite normal.

Hello Samuele,

I fear we may be getting outside of an area where we can provide significant help. It may be necessary that you contact ARM support.

About a decade ago I wrote my own scanloader for an ARM 966 and the issues you are seeing sound familiar.  I suspect what is happening is that you are inadvertently introducing a bad instruction to the CPU via the debug comms channel, which is causing the prefetch abort.  

I am not so worried by the PC reflecting desired PC + 0x8.  The core fetches in 64b chunks and this is simply indicating that the PC has incremented to the next address.  I suspect this means that the CPU has launched the fetch request at your desired PC and has automatically incremented after the fetch was issued.

Hopefully this stirs some ideas from your side.

Best Regards,

Karl

Hi Karl,

thank you for your suggestion. I tested with another device (correctly supported) and I replicated the PC+0x8 behaviour, confirming your opinion (although it still seems strange to me as the core is actually halted and should not execute instructions).

Anyway this second board doesn't power up with Prefetch Abort, unlike my actual issue. Could it be a problem? I double checked to have a blank flash memory (and ECC too), to avoid that a firmware in flash could mess up the processor registers before I start working with.

Regards

Hello Samuele,

In this case, it may be better to operate from a programmed device with known good code.

If the device is erased, the prefetch abort may be due to the CPU trying to execute the "0xFFFFFFFF" instruction before you take control with the debugger.  It is probably necessary for you to use the debugger to check for and clear any aborts which are present at the time you take over via debug.  In addition, you may need to flush the pipeline to ensure that additional bad instructions are not already fetched to the prefetch buffer and waiting to be executed.  This may be the cause of your problem - even though you have set the next PC, you still have bad fetches waiting to be processed in the pipeline before you can fetch the new code.

Regards,

Karl

Hello Support.

I have similar issue with the CPU debug unit.

Here is what I need to accomplish: in runtime (without JTAG debugger or any external debugger) I need to intercept function call and execute code before the function is executed. I would like to do this using breakpoint.

From what I've learned, this should be possible using the debug unit in monitor mode. I suppose I need to enter monitor mode before doing anything else. But when I'm trying to write anything to DBGDSCR (also unmodified value of DBGDSCR), I'm getting invalid instruction exception (when writing it using CP14) or nothing happens and the register is not changed when trying to access it through the memory mapped registers.

I can read debug registers and their contents seems right (both when accessing through CP14 as well as in memory mapped area).

Please at least confirm that it is possible to set breakpoint from the code itself (without external debugger).

Any other hints will be appreciated.

My development platform is Hercules HDK for TMS570.

Regards,
Lukasz

Hello Lukasz,

Sorry if we can't get too precise here, the ARM documentation on this logic is not always so clear.

If you have not used it already, I would recommend that you reference ARM DDI0406B, "ARM Architecture Reference Manual - ARM v7-A and ARMv7-R edition".  Part C of the document includes the definition of the debug architecture used on the Cortex R4/R4F.  In particular, section C3.2.1 walks through breakpoint debug events initiated by software.

Regarding the point you are seeing on the DSCR register, I recommend that you perform the action via coprocessor instruction from the CPU rather than memory mapped access via CoreSight.  The CoreSight bus can differentiate by hardware a transaction coming from the debugger vs. the on-chip logic and in some cases may handle the two differently, as described in the architecture manual.

With respect to the invalid instruction exception, are you sure you are properly writing the coprocessor instruction?  Another possibility might be that you need to be in a privileged mode to write to the register.

Best Regards,

Karl

Hello Karl,

Thank you for your response.

I think you may be right about the privileged mode, I will go in this direction. I'm pretty sure the instruction used is correct.

I will get back to you with my results.

Kind regards,

Lukasz

Dear Karl,

I finally solved all this issues, rebuilding initializations with last HalCoGen version and setting correctly both stack size and stack address.

However I noticed a little instability in my code execution, getting random errors on flashing api functions. My implementation initially followed the same logic as all other TMS570 developed: I have two data buffer, while one buffer is being flashed by the core, my programmer download data on the second buffer, so to parallelize this operations. 

Being this device without direct access to RAM I thought this optimization unuseful, as the processor has to be halted during data download process. Moving from two buffers to one seems solve the instability problems.

My question is: does halting the core for writing/reading operations compromize the flashing process? I use polling methods to understand from programmer side if the flashing operations are completed or not.
Thank you, best regards 

Hello Samuele,

I'll ask one of my colleagues more familiar with the flash programming sequences to comment on this point.

Best Regards,

Karl

Hello Samuele,

As the Flash State Machine (FSM) is independent of the core, I would not expect halting the core to compromise the flashing process.  The behavior I have seen when stepping through my test code that the core halts do not affect the FSM, but I will check with other colleagues to verify my observations.

Hello Samuele,

My colleagues have confirmed that halting the CPU will not affect FSM operations on the Flash memory.

Hello,

For the same reasons as Pashan I would like to access an TMS570LS3137-ZWT. But I already stuck at the Access Port of the Cortex-R4, rather I cannot read any ID from the IDR of Bank 0xF of the device. I noticed that the CxxxPWRUPACK-Bits/Signals in the CTRL/STAT Register are HIGH even at the Start-up of the CPU. I already got around the ICEPick, so I don't know what I have to do to get access to the Cortex-R4 APB-AP.

Thanks in advance,

Peter

Hello Peter,

The DAP implementation including connection to Cortex R4 is done to ARM standard.  Have you referenced the ARM Debug Interface (ADI) v5 and the debug architecture in the ARM Architecture Reference Manual?

In general, once ICEPICK has engaged the proper path, you must program the JTAG-DP inside DAP to select one of the AP targets.  To access the CPU, select the APB-AP.  The CPU is at the 2nd 4kB chip select, with the debug ROM at 0x0 as per ARM standard.  Note that unlike a Cortex M, the CPU does not have a dedicated AP.

With respect to the PWRUPACK bits in the JTAG-DP, the device does not support power aware debug so these signals should be static during operation.  Power aware debug is an optional feature in the ARM debug architecture.  The presence or lack of this feature should not impact any ability to communicate with the CPU.  However, it is a good practice to always command the power domains "on" in case you need to migrate the code to a product with power-aware debug.

I am a bit confused by your statement on the AP.  If you program the APSEL to 0x0, I believe it should be selecting the APB-AP.  To my knowledge, the APB-AP IDR register is found at 0xFC.  If you program the JTAG-DP with 0xF for the bank, I believe you will be seeing the BD0, BD1, BD2, and BD3 registers, but it has been a long time since I have worked with the devices at this level.

Regards,
Karl 

Hello Karl,

Following your suggestion I've checked if I can write DBGDSCR in privilidged mode (using SVC) but no luck, I'm still getting Undefined exception (0x4); I'm using the following code to handle the SVC call (which I call using asm("SVC #6"):

_svc:

    stmfd  sp!,  {r0-r12,lr}
	ldr r0,[r14,#-4]		; Get SWI Instruction
	and r0, r0, #0xff		; Look at lower 8 bits of SWI Number Only
	cmp r0, #HIGHEST_SWI		; Check for SWI out of Range
	bhi _swi_exit			; Exit Immediately if SWI out of Range
	mrs r1, spsr			; Get SPSR for SWI's that change PSR

	ldr pc,[pc,r0,lsl#2]		; Dispatch Instruction
	mov r0,r0			; Exactly 1 Word Between Disp. Instr and Table
	.word	_swi_enable_fiq		; SWI 0x00 - Dispatch Table Begins Here  
	.word _swi_disable_fiq	   ; SWI 0x01
	.word _swi_enable_irq		; SWI 0x02
	.word	_swi_disable_irq	   ; SWI 0x03
	.word _swi_enable_fiq_irq	; SWI 0x04
	.word	_swi_disable_fiq_irq	; SWI 0x05
	.word _swi_enable_monitor  ; SWI 0x06
	
_swi_disable_fiq
	orr r1, r1, #FIQMASK
	msr spsr_cxsf, r1
	b   _swi_exit
		
_swi_enable_fiq
	bic r1, r1, #FIQMASK
	msr spsr_cxsf, r1
	b   _swi_exit

_swi_disable_irq
	orr r1, r1, #IRQMASK
	msr spsr_cxsf, r1
	b   _swi_exit

_swi_enable_irq
	bic r1, r1, #IRQMASK
	msr spsr_cxsf, r1
	b   _swi_exit

_swi_disable_fiq_irq
	orr r1, r1, #(FIQMASK|IRQMASK)
	msr spsr_cxsf, r1
	b   _swi_exit

_swi_enable_fiq_irq
	bic r1, r1, #(FIQMASK|IRQMASK)        ;I and F bit be cleared
	msr spsr_cxsf, r1
	b   _swi_exit

_swi_enable_monitor
   MRC p14, #0, r1, c0, c1, #0
   MCR p14, #0, r1, c0, c1, #0
   MOVS pc, r14

_swi_exit:
        ldmfd  sp!,  {r0-r12,pc}^

Everything works as expected and I'm getting value of 0x02004806 when reading DBGDSCR, but when I'm trying to write the same value back I get Undefined exception. Same for writing value of 0. I've tried this using external debugger in single stepping and also when running withouth debugger (I can see the results on HDK's LEDs).

I've found a Linux project that does exactly the same (writes DBGDSCR) and the philosophy is very similar, unfortunatelly it is not for ARMv7 debug (it expects b0011 in DBGDIDR for the debug architecture version) so I cannot check their code.

Any thoughts ?

Regards.

"Note that unlike a Cortex M, the CPU does not have a dedicated AP."

What do you mean by that ?

"I am a bit confused by your statement on the AP.  If you program the APSEL to 0x0, I believe it should be selecting the APB-AP.  To my knowledge, the APB-AP IDR register is found at 0xFC.  If you program the JTAG-DP with 0xF for the bank, I believe you will be seeing the BD0, BD1, BD2, and BD3 registers, but it has been a long time since I have worked with the devices at this level."

I've tested all APs from 0 to 2 (AHB-AP, APB-AP and JTAG-AP) but I get no plausible ID at Bank 0xF. BD0 to BD3 are at Bank 0x1.

Do you have any suggestions what to do (what register to read) to ensure that I have a correct communication / access to the processor.  

Hi Lukasz,

I'm afraid this is going a bit beyond my expertise.  I'll try to contact some of the support folks at ARM to see if they can provide an example.

Thanks and Regards,

Karl

Hi Peter,

On the Cortex M devices, each CPU includes an AP element in the integration layer.  On Cortex R and Cortex A products, the AP is included in the DAP and a single DAP can support multiple processors.  As a result, if you were coming from a Cortex M background you may find A/R to have a few differences.

I expect the only valid JTAG-DP decodes to be:

AHB-AP --> 0x0

APB-AP --> 0x1 (not 0x0 as earlier stated)

On this device, I expect the ID registers to show:

AHB AP ID:  0x14770001

APB AP ID:  0x04770002

What IDs are you reading?

Note that all of the data should be managed as little endian on the debug subsystem programming, even if you are using a word invariant big endian (BE-32) device.

Regards,

Karl

"On the Cortex M devices, each CPU includes an AP element in the integration layer.  On Cortex R and Cortex A products, the AP is included in the DAP and a single DAP can support multiple processors.  As a result, if you were coming from a Cortex M background you may find A/R to have a few differences."

Ok, but that's not relevant for me because the access to the DAP (I mean Debug Port and Access Port) is the same.

"What IDs are you reading?"

Nothing plausible -> 0x000000F0. I can only assume that the device is faulty ? Or what pins (the JTAG pins excluded) do I have to observe / consider when I want to access the debug unit. Are there even any more than the standard JTAG pins?

Hi Peter,

It is possible you have a bad device, but improbable.

Only standard JTAG pins are needed to access debug functionality.

Can you confirm debug access with a debugger which is known to work with the product, such as TI CCS, ARM RVDS, or similar to check your concern of a potentially faulty device?

If you try to read other locations by changing bank address, do you see expected values for any of the APB-AP registers?

Regards,
Karl 

Hi Lukasz,

ARM support believes that what you are seeing is most likely an access permission problem.  

If programming via the CP14 coprocessor, please confirm you are in a privileged mode.  If programming via the memory mapped registers, please confirm you have unlocked the CoreSight lock registers (DBGLAR) by writing the key "0xC5ACCE5".

These steps need to be done before writing the monitor mode debug enable bit in the DBGDSCR.

Regards,

Karl

Hi Lukasz,

Passing along one additional note from ARM support - you will need to perform the programming via the memory mapped interface, not the coprocessor interface.  The monitor mode debug enable control is RO via CP14, but RW via memory mapped interface.

Regads,
Karl 

Thank you Karl, I will try that and let you know the results.

Regards,

Lukasz.