CTRLSTAT = 0xffffffff

Hi and welcome to the community.

Which tool are you using for reading the data ?

(Maybe OpenOCD - or your own ?)

-Can you provide some extra information about the microcontroller vendor and model number ?

(it might be helpful in finding out the cause and thus the solution).

Thank you for responding, and by the way i am using stm32f407vg as host and stm32f407vg as target .i am trying to implement debug functionality so that i could access/control target from host. i put a step forward with Mark's Space: Programming internal SRAM over SWD blog.

i am taken 2 gpio pins configuration as follow

/* preparing GPIO pin to SWDIO */

GPIO_PIN_DATA_t st_gSWDIOPin =

{

  GPIO_PORTE,

  PORT_PIN3,

  GPIO_MODE_OUT,

  GPIO_OTYPE_PP,

  GPIO_SPEED_50MHz,

  GPIO_PUPD_NOPULL

};

/* Preparing GPIO pin to clock  */

GPIO_PIN_DATA_t st_gSWDCLKPin =

{

  GPIO_PORTE,

  PORT_PIN2,

  GPIO_MODE_OUT,

  GPIO_OTYPE_PP,

  GPIO_SPEED_50MHz,

  GPIO_PUPD_NOPULL

};

as a first step i send signals from host to target and able to read IDCODE,and even i am able to write CTRLSTAT register with value 0x50000000 but when i am trying to read CTRLSTAT .I got ACK success but while i am reading i got 0xffffffff,

hoping thins information might helpful to you for my problem

Thanks & Regards.

For STMicroelectronics's own documentation on the subject, please see RM0090, section 38.3.1.

First of all, we'll need to make sure your connection is OK.

When I connect a JTAG-Lock-pick Tiny 2 to my targets, I use the standard JTAG pull-up and pull-down resistors:

• TCLK/SWDCLK: 10K pull-down
• TMS/SWDIO: 10K pull-up
• TDO/SWO: 10K pull-up

... Next, do you switch from output to input, when you're reading the CTRL/STAT register ?

... Also... The address; are you encoding it correctly, so (only) bits 3 and 4 in the first byte you send are modified ?

... If you have a logic-analyzer, it might be a good idea to connect it, in order to monitor the values sent and received on the pins.

... If you have a logic-analyzer, try monitoring the data that OpenOCD transfers to the target when it starts up, then compare to your own data.

I know this sounds ridiculous, but it is a very good idea to write some low-level debug code, which shows you exactly what is going on.

It will probably be a good idea to make a temporary modification to your transmit routine, the one routine, that sends a single bit:

It should output either a 0 or a 1, depending on the data it sends.

Then after each stream of bits, you send output a space.

Finally, at the end of each transfer, you output a newline character.

Transmit all the data from above to your debug-terminal via a UART interface, if you have a terminal connected to the board.

Example of making the code fast (do not use printf in your bit-transmitter code):

1: Create a static buffer and a static pointer variable outside your transmission function:

static char sDebugBuffer[128];

static char *pDebugBufffer = sDebugBuffer;

2: Before starting each transmission, do the following:

pDebugBuffer = sDebugBuffer;

3: Each time you transmit a bit, do the following:

*pDebugBuffer++ = '0' + bitValue;

4: Each time you're done transmitting a sequence of bits (for instance 8 bits for a byte, or 3 bits for the response code, or 33 bits for the WDATA, do the following:

*pDebugBuffer++ = 0x20;

5: Each time a transfer ends, do the following:

*pDebugBuffer++ = 0x0a;

*pDebugBuffer = 0x00;

pDebugBuffer = sDebugBuffer;

/* and write the contents of the debug-buffer to your UART; maybe you're using UART_send, maybe write, maybe printf, let's assume printf in this case: */

printf("%s", sDebugBuffer);

This enables you to verify that your transmission is correct length, and it will also enable you to see exactly what bit-values are sent, so you can verify they're what you expect them to be.

For the response, you can of course also implement a similar mechanism.

For STMicroelectronics's own documentation on the subject, please see RM0090, section 38.3.1.

First of all, we'll need to make sure your connection is OK.

When I connect a JTAG-Lock-pick Tiny 2 to my targets, I use the standard JTAG pull-up and pull-down resistors:

• TCLK/SWDCLK: 10K pull-down
• TMS/SWDIO: 10K pull-up
• TDO/SWO: 10K pull-up

... Next, do you switch from output to input, when you're reading the CTRL/STAT register ?

... Also... The address; are you encoding it correctly, so (only) bits 3 and 4 in the first byte you send are modified ?

... If you have a logic-analyzer, it might be a good idea to connect it, in order to monitor the values sent and received on the pins.

... If you have a logic-analyzer, try monitoring the data that OpenOCD transfers to the target when it starts up, then compare to your own data.

I know this sounds ridiculous, but it is a very good idea to write some low-level debug code, which shows you exactly what is going on.

It will probably be a good idea to make a temporary modification to your transmit routine, the one routine, that sends a single bit:

It should output either a 0 or a 1, depending on the data it sends.

Then after each stream of bits, you send output a space.

Finally, at the end of each transfer, you output a newline character.

Transmit all the data from above to your debug-terminal via a UART interface, if you have a terminal connected to the board.

Example of making the code fast (do not use printf in your bit-transmitter code):

1: Create a static buffer and a static pointer variable outside your transmission function:

static char sDebugBuffer[128];

static char *pDebugBufffer = sDebugBuffer;

2: Before starting each transmission, do the following:

pDebugBuffer = sDebugBuffer;

3: Each time you transmit a bit, do the following:

*pDebugBuffer++ = '0' + bitValue;

4: Each time you're done transmitting a sequence of bits (for instance 8 bits for a byte, or 3 bits for the response code, or 33 bits for the WDATA, do the following:

*pDebugBuffer++ = 0x20;

5: Each time a transfer ends, do the following:

*pDebugBuffer++ = 0x0a;

*pDebugBuffer = 0x00;

pDebugBuffer = sDebugBuffer;

/* and write the contents of the debug-buffer to your UART; maybe you're using UART_send, maybe write, maybe printf, let's assume printf in this case: */

printf("%s", sDebugBuffer);

This enables you to verify that your transmission is correct length, and it will also enable you to see exactly what bit-values are sent, so you can verify they're what you expect them to be.

For the response, you can of course also implement a similar mechanism.

from Implementation of Serial Wire JTAG flash programming in ARM Cortex M3 Processors | Theesan's log  "Table 2.2.1 DP Register information" he given in 3:2 order i am taken in 2:3 order so

a[2:3] = 1 | 0

Parity = 1

Stop = 0

Perk = 1

in hex 0x95

To Read  CTRLSTAT 

startbit  = 1

APnDP = 0

R/W     = 1

from Implementation of Serial Wire JTAG flash programming in ARM Cortex M3 Processors | Theesan's log Table 2.2.1 DP Register information he given in 3:2 order i am taken in 2:3 order so

a[2:3] = 1 | 0

Parity = 0

Stop = 0

Perk = 1

in hex B1

HardwareDebugConnections - ** Code Red Support Site **

from the above url i connected host GPIO to SWCLK pin of target with 10k pull down, and host GPIO to SWDIO pin of target with 10K pullup. is there any wrong with hardware connection??

The timing information can be found on the ARM Information Center under SWD timing requirements.

Each edge should be between 10 ns and 500 us.

That means ... If you're running at 168MHz: at least 2 clock cycles (one for writing, one for delay), maximum 84000 clock cycles.

I think you can use something like this, in order to get the fastest possible transfer rate at 168MHz:

#define SW_NOP      __NOP()

#define SWDIO_HI    /* replace this comment with a way to set the SWDIO pin high */

#define SWDIO_LO    /* replace this comment with a way to set the SWDIO pin low */

#define SWDIO_IN    /* replace this comment with a way to read the SWDIO pin; the value should be either 1 or 0 */

#define SWDIO_(b)   if(b){ SWDIO_HI; } else { SWDIO_LO; }

#define WR(b)       SWDIO_(b) ; SWCLK_LO ; SW_NOP         ; SWCLK_HI

#define WR1         SWDIO_HI  ; SWCLK_LO ; SW_NOP         ; SWCLK_HI

#define WR0         SWDIO_LO  ; SWCLK_LO ; SW_NOP         ; SWCLK_HI

#define RD          SW_NOP    ; SWCLK_LO ; bit = SWDIO_IN ; SW_CLK_HI

#define CLK         SW_NOP    ; SWCLK_LO ; SW_NOP         ; SWCLK_HI

The CLK macro can be used to repeat a bit; eg. if you know you're outputting 8 zero bits, you can issue WR0; CLK; CLK; CLK; CLK; CLK; CLK; CLK.

Note: The order of reading and writing must match exactly, and the high and low states on the clock must also be exact.

(That does not mean that I've written the above code correctly, though).

The WR1 would take one clock cycle, if it's translated into a STR instruction without loading register values first.

The WR0 would also take one clock cycle (same case).

The RD might take two or three clock cycles, because it's often necessary to perform a bitwise AND operation before using a bitwise OR operation to insert the new bit into a register.

The assembly code would usually look like this:

                    ldr                 r2,[r3]             /* [2] read the pin state */

                    and                 r2,r1,r2,lsr#4      /* [1] move bit 4 to bit 0 and isolate it, so it's now either 0 or 1 /*

                    add                 r0,r2,r0,ror#1      /* [1] shift the result right by 1, then insert the new bit */

Using the above mehtod means that after receiving all the bits, you'd need to rotate the entire result left by the number of bits received -  1.

Note: on Cortex-M4, the BFX instruction can also be used for extracting the bit.

-But in some cases, you might be able to read from a port, where the bit value will always be 1 or 0.

-But also according to the documentation found here, there should be turnaround: http://www.arm.com/files/pdf/Low_Pin-Count_Debug_Interfaces_for_Multi-device_Systems.pdf

I get IDCODE 0x2BA01477 for both STM32F4 (which is a Cortex-M4 device) and LPC1751 (which is a Cortex-M3 device).

Here's a similar session with JTAG-lock-pick Tiny 2 and LPC1751:

11111111111111111111111111111111111111111111111111011110011110011111111111111111

11111111111111111111111111111111111100101001011001110111000101000000001011101010

00111000000110011011110000000000000000000000000000000000001011000110010000010000

00000000000000000111101110010101100110000010000000000000000000000000011011000110

00000001000000000000000000000000011110010101100110000000000000000000000000000101

In both cases, it seems there's no turnaround clock. So I believe that right after sending the last bit, before changing the SWCLK to LOW, you could try and change the SWDIO direction to input, then issue the SWCLK_LO and have 0 turn-around clock cycles.

According to all the documents I found, it seems that data are sampled on the rising edge of SWCLK, thus changing the direction should be done right after you've sampled the data.

So far, I have been unable to do a test with the JTAG-lock-pick Tiny 2 connected to the Discovery board, but if I get it set up, I'll post the output here as well.