Hi again
This time the test subject is an ARM1176JZF-S, namely Samsung S5P6443. What is particular about this MCU is that it has two daisy-chained devices: an ARM ETB(I suppose it is ARM7 based) and the ARM1176JZF-S core.
In all available documents is stated that the combined "intelligence" (probe firmware+dll) can handle ARM11 cores. This is just partly true and no refference was ever made about what was NOT implemented for ARM11 cores. Let me start with things that are working:
* halt struggles a litthe bit but finally it works after nResetting the device, see this log fragment
T0FE0 002:347.709 JLINK_Connect()
T0FE0 002:357.844 TotalIRLen = 10, IRPrint = 0x0021
T0FE0 002:358.920 At least one of the connected devices is not JTAG compliant (IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)
T0FE0 002:360.576 JTAG chain detection found 3 devices:
T0FE0 002:360.606 #0 Id: 0x2B900F0F, IRLen: 04, ARM ETB
T0FE0 002:360.633 #1 Id: 0x0F6EDE1F, IRLen: ?, Unknown device
T0FE0 002:360.659 #2 Id: 0x00000001, IRLen: ?, Unknown device
T0FE0 002:360.686
***** Error:
T0FE0 002:360.706 CPU-TAP not found in JTAG chain
T0FE0 002:432.857 TotalIRLen = 9, IRPrint = 0x0011
T0FE0 002:435.803 JTAG chain detection found 2 devices:
T0FE0 002:435.896 #0 Id: 0x2B900F0F, IRLen: 04, ARM ETB
T0FE0 002:435.925 #1 Id: 0x07B76F0F, IRLen: 05, ARM1176 Core
T0FE0 002:437.185 -- Max. mem block: 0x00010FA8
*RAM reads/writes and cp15 handling works well
*Can't say anything about breackpoints and watchpoints because I did not test them
*ICE reg operations are specific to ARM7/ARM9 and, as expected, are not working
Now let's talk about one thing which is not working but one would expect to do so: DCC
It is clear that DCC in ARM11 works sohehow different as in ARM7/ARM9 but ARM11 has in fact DCC. Unfortunately none of the DCC functions are working on ARM11. Ok, maybe ARM11 was not interesting compared to Cortex family but at least warn the customers that DCC is not implemented (yet) for ARM11 cores. Due to the fact that I needed this functionality, I implemented it in three different ways to test performance. I will give hints about all three because in the third I found an issue redarging dll/probe firmware combination.
The first and slowest was to select scan chain 5 and put into a loop JLINKARM_JTAG_StoreGetData() until "Valid/nRetry" flag (DTR[33]) is either set or clear, depending on the direction: reads or writes. Due to the huge USB trafic, the transfer rate was 6,76 kB/sec. The seccond method was a little bit faster: the ram code fils an internal buffer with the required data, sends a synk word through DCC and at host side a full storedata followed by getdata without checking flags. Transfer rate increased to about 55 kB/sec, data perfectly valid. The third method: ram code sends through DCC only one sync word that ram buffer is full/processed, host halts the core, reads/writes ram buffer then restarts the ram code. Transfer rate around 154 kB/sec.
In order to read/write ram, most certainly the probe's software sets bit[13] of DSCR, pushes LDC/STC instructions into the pipeline via scan chain 4 than reads/writes data from/to DTR... So yes, in certain conditions it uses the 34 bit long scan chain 5, from here it would be just a small step to implement full DCC.
And now comes the flow I was talking about. My ram code at entry explicitely clears DSCR[13]
MRC p14, 0, r0, c0, c1, 0
ORR r0, r0, #BIT11
BIC r0, r0, #BIT12
BIC r0, r0, #BIT13
BIC r0, r0, #BIT14
BIC r0, r0, #BIT15
MCR p14, 0, r0, c0, c1, 0
for a good reason: with this bit clear, DCC handshaking at host side is done through Valid/nRetry flag, DTR[33]. When DSCR[13] is set, handshaking at host side should be done through Ready flag DTR[32]; in this situation DTR[33] will have an unpredictable state. One would expect that after setting DSCR[13]and executing instructions in scan chain 4, DSCR will be restored to it's previous value, which is not happening. The firmware "forgets" to restore DSCR after it finishes the ram reads/writes and DSCR[13] remains set! A good programming practice is that if some registers are changed for a reason, they should be restored to their previous values, exactly as the entry in a function: registers used in the function are pushed on the stack and poped before return. It is not a huge issue, ram code can easily fix it but is good for you to know about this.
This time the test subject is an ARM1176JZF-S, namely Samsung S5P6443. What is particular about this MCU is that it has two daisy-chained devices: an ARM ETB(I suppose it is ARM7 based) and the ARM1176JZF-S core.
In all available documents is stated that the combined "intelligence" (probe firmware+dll) can handle ARM11 cores. This is just partly true and no refference was ever made about what was NOT implemented for ARM11 cores. Let me start with things that are working:
* halt struggles a litthe bit but finally it works after nResetting the device, see this log fragment
T0FE0 002:347.709 JLINK_Connect()
T0FE0 002:357.844 TotalIRLen = 10, IRPrint = 0x0021
T0FE0 002:358.920 At least one of the connected devices is not JTAG compliant (IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)
T0FE0 002:360.576 JTAG chain detection found 3 devices:
T0FE0 002:360.606 #0 Id: 0x2B900F0F, IRLen: 04, ARM ETB
T0FE0 002:360.633 #1 Id: 0x0F6EDE1F, IRLen: ?, Unknown device
T0FE0 002:360.659 #2 Id: 0x00000001, IRLen: ?, Unknown device
T0FE0 002:360.686
***** Error:
T0FE0 002:360.706 CPU-TAP not found in JTAG chain
T0FE0 002:432.857 TotalIRLen = 9, IRPrint = 0x0011
T0FE0 002:435.803 JTAG chain detection found 2 devices:
T0FE0 002:435.896 #0 Id: 0x2B900F0F, IRLen: 04, ARM ETB
T0FE0 002:435.925 #1 Id: 0x07B76F0F, IRLen: 05, ARM1176 Core
T0FE0 002:437.185 -- Max. mem block: 0x00010FA8
*RAM reads/writes and cp15 handling works well
*Can't say anything about breackpoints and watchpoints because I did not test them
*ICE reg operations are specific to ARM7/ARM9 and, as expected, are not working
Now let's talk about one thing which is not working but one would expect to do so: DCC
It is clear that DCC in ARM11 works sohehow different as in ARM7/ARM9 but ARM11 has in fact DCC. Unfortunately none of the DCC functions are working on ARM11. Ok, maybe ARM11 was not interesting compared to Cortex family but at least warn the customers that DCC is not implemented (yet) for ARM11 cores. Due to the fact that I needed this functionality, I implemented it in three different ways to test performance. I will give hints about all three because in the third I found an issue redarging dll/probe firmware combination.
The first and slowest was to select scan chain 5 and put into a loop JLINKARM_JTAG_StoreGetData() until "Valid/nRetry" flag (DTR[33]) is either set or clear, depending on the direction: reads or writes. Due to the huge USB trafic, the transfer rate was 6,76 kB/sec. The seccond method was a little bit faster: the ram code fils an internal buffer with the required data, sends a synk word through DCC and at host side a full storedata followed by getdata without checking flags. Transfer rate increased to about 55 kB/sec, data perfectly valid. The third method: ram code sends through DCC only one sync word that ram buffer is full/processed, host halts the core, reads/writes ram buffer then restarts the ram code. Transfer rate around 154 kB/sec.
In order to read/write ram, most certainly the probe's software sets bit[13] of DSCR, pushes LDC/STC instructions into the pipeline via scan chain 4 than reads/writes data from/to DTR... So yes, in certain conditions it uses the 34 bit long scan chain 5, from here it would be just a small step to implement full DCC.
And now comes the flow I was talking about. My ram code at entry explicitely clears DSCR[13]
MRC p14, 0, r0, c0, c1, 0
ORR r0, r0, #BIT11
BIC r0, r0, #BIT12
BIC r0, r0, #BIT13
BIC r0, r0, #BIT14
BIC r0, r0, #BIT15
MCR p14, 0, r0, c0, c1, 0
for a good reason: with this bit clear, DCC handshaking at host side is done through Valid/nRetry flag, DTR[33]. When DSCR[13] is set, handshaking at host side should be done through Ready flag DTR[32]; in this situation DTR[33] will have an unpredictable state. One would expect that after setting DSCR[13]and executing instructions in scan chain 4, DSCR will be restored to it's previous value, which is not happening. The firmware "forgets" to restore DSCR after it finishes the ram reads/writes and DSCR[13] remains set! A good programming practice is that if some registers are changed for a reason, they should be restored to their previous values, exactly as the entry in a function: registers used in the function are pushed on the stack and poped before return. It is not a huge issue, ram code can easily fix it but is good for you to know about this.