I'm reading through the CC111x datasheet's "Debug Interface" section and wonder of how to read memory and/or registers. Are there debug commands missing in table 45 or am I missing something?
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.
Via the commands in Table 45 you can execute nearly any of the assembly instructions from Table 37 making it possible to access all of the registers. Out of academic curiosity I've done this but it has been a while. The IAR IDE gives you access to all of the registers, memory types, and SFRs with a couple of clicks.
Hi, I assume that you are referring to DEBUG_INSTR and/or STEP_REPLACE commands. Both commands return the status byte, but I can't see what I can do to get an actual register value out of the debug interface with these commands. How did you do that?
The device is put into debug mode with 2 transitions high of the debug clock while dropping and holding reset low and then returning /reset high (If you hold it low too long you will get a reset.)
The host outputs 1 to 4 bytes of instruction depending on the command sent and can get back 1 byte of data. If you send the unique command for status that is what will be returned.
You can see the DD and DC lines on the device pin out, the trick to implement IEEE 1149.1 JTAG with only 2 wires ( really 3) is /RESET becomes the direction pin. Low to write to the device and high for it to clock data out. (If you hold it low too long you will get a reset.)
Clock in 0x34 on the DD using DC for the clock with /reset low, set /reset high, initiate the clock, and the status code is returned on DD.
Now if you :
clock in 0x56, 0x90, address1, address2 you have set the data pointer to address high, address low and then clocked out garbage (MOV DPTR, 2 byte address),
clock in 0x56, 0xE0, and then clocked out garbage Move external RAM (XRAM) (16-bit address from previous step) to A (MOVX A,@DPTR; (your_data = A)
assert direction bit and clock out your_data
I used a SiLabs C8051F320 eval board using the GPIO P0_0 for DC and GPIO P0_1 for DD and a GPIO P0_2 to drive /RESET on a CC1110 and basically bit banged the CC1110 with the various debug and assembly codes. If you look at the schematic for the SmartRF04 you will see Ti does the same thing. They use different ports, but they do use the F320 and a GPIOto drive /Reset on the SOC.
To enter the debug mode I dropped P0_2, toggled P0_0 twice, and raised P0_2
To write the 8 bit data from an array preconfigured with the byte sequence for various commands I had a “for loop” for 8 loops and toggled P0_0 each loop, used a AND with 0x01 on each loop and then shifted the data 1 bit for the next loop (data << 1) for the 0 / 1 decision. The whole thing was less than a dozen lines of c code.
Crude, but I wanted to see it on the logic analyzer for myself as I was writing HDL code for a FPGA and needed to understand it on a step by step basis.
If I understand you correctly, I can read A after issuing a command and asserting reset_n. I'll give it a try this weekend, thank you very much.
BTW: Where do you know all that? Is this documented somewhere or did you monitor the three communication lines? I re-read the datasheet's debug interface section once again and can't find a single note mentioning reset_n being the direction bit...
It took some searching through old notes but I found a reference to a 2006 app note I must have used. It is SWRA124 and is titled
CC1110/ CC2430/ CC2510
Debug and Programming Interface
Specification
Rev. 1.2
Even in the AN the use of the /RESET for direction is not defined. In the timing diagrams they show the "direction bit" but never define it. This I got from the general 8051 standard we received with the purchase of a 8051 soft core and through testing on a CC1110 and watching the logic pattern from a Smart RF04 board.
-H