STM32F103C8TC6 USART Help.

[diyaudio]

Hi Guys

I'm at a point of confusion, vie set-up my STM32F103C8TC6 for USART communication im stuck with the following problem.

When I send a string of characters none of the character seem to appear at the terminal window, I can verify communication on the USART2 TX bus, the scope shows data however, the decoded ASCII OR HEX data isn't correct at all I'm totally lost.     

Code: [Select]

int main(void)
{

   setup_init();     

    uint8_t data[] = {0x55, 0x01, 0x02, 0x03, 0x04,  0x00};
       
       
       
    while(1)
    {

       send_string(data);
       delay();

    }
}


void setup_init()
{
 

  // Setup system clocks.
  rcc_config();
 
  // Setup GPIO
  gpio_config();
   
 
  usart1_config();
 
  // Setup Printf USART2
  usart2_config();
}


void rcc_config(void)
{

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA , ENABLE);
 
  /* USART-1 clock enable */
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
 
  /* USART-2 clock enable */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
}


void gpio_config()
{

  /* Configure USART1_TX  as alternate function push-pull */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10;  // PA.10 USART1.TX
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
  GPIO_Init(GPIOA, &GPIO_InitStructure);
 
  /* Configure USART1_RX as input floating */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11;  // PA.11 USART1.RX
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
  GPIO_Init(GPIOA, &GPIO_InitStructure);
 

  /* Configure USART2 Tx as alternate function push-pull */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;  // PA.2 USART2.TX
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
  GPIO_Init(GPIOA, &GPIO_InitStructure);
 
  /* Configure USART2 Rx as input floating */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;  // PA.3 USART2.RX
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
 
  GPIO_Init(GPIOA, &GPIO_InitStructure);

}


void send_string(const char *str)
{
    while (*str)
    {
        while(USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);
        USART_SendData(USART2, ((uint16_t)str++) );
    }
}

void usart2_config(void)
{
  USART_InitTypeDef USART_InitStructure;
 
  /* USARTx configuration ------------------------------------------------------*/
  /* USARTx configured as follow:
        - BaudRate = 9600 baud
        - Word Length = 8 Bits
        - Two Stop Bit
        - Odd parity
        - Hardware flow control disabled (RTS and CTS signals)
        - Receive and transmit enabled
  */
  USART_InitStructure.USART_BaudRate = 9600;
  USART_InitStructure.USART_WordLength = USART_WordLength_8b;
  USART_InitStructure.USART_StopBits = USART_StopBits_1;
  USART_InitStructure.USART_Parity = USART_Parity_No;
  USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
 
  USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
 
  /* USART configuration */
  USART_Init(USART2, &USART_InitStructure);
 
  /* Enable the USART2 */
  USART_Cmd(USART2, ENABLE);
}





See attachment I was expecting the data order 0x55, 0x01, 0x02, 0x03, 0x04 and 0x00 null character. However I got crap, the clock is set at 72MHZ.

I've looked at the datasheet and looked at the demo sample code and on-line resources, either im suffering from tunnel vision or something else is wrong.

[dannyf]

I posted an interrupt driven uart routine that can be easily adapted to your application in the ghetto thread.

sounds like you have to get the transmission right first and then worry about the receiving end.

[diyaudio]

I posted an interrupt driven uart routine that can be easily adapted to your application in the ghetto thread.

sounds like you have to get the transmission right first and then worry about the receiving end.

Okay I will check it out, still I need to understand if transmission is incorrect, is it on my side or the standard peripheral usart implementation side. 

[cv007]

probably start here-

USART_SendData(USART2, ((uint16_t)str++) );

str is a pointer address
you want *str++

[diyaudio]

probably start here-

USART_SendData(USART2, ((uint16_t)str++) );

str is a pointer address
you want *str++

I tried this still no luck.

Code: [Select]

void USART_puts(USART_TypeDef* USARTx, volatile char *s){

while(*s){
// wait until data register is empty
while( !(USARTx->SR & 0x00000040) );
USART_SendData(USARTx, *s);
*s++;
}
}


[dannyf]

I think it's more productive to assume that the errors are in your code, unless you can prove other.

[mikerj]

How are you connecting the STM32 UART to your PC, via a MAX232 and proper serial port, or some TTL/USB USART bridge?

[diyaudio]

How are you connecting the STM32 UART to your PC, via a MAX232 and proper serial port, or some TTL/USB USART bridge?

ftdi chip and tera terminal. (bogus data)
scope rigol ds2072a RS232 decoder. (bogus data)

both test fixtures fail.

[dannyf]

Take a working piece of code (lots of examples, from the library or the ghetto thread), get it to work on your set-up and then tailor to your application (on usart2 for example).

On first glace, you didn't activate the alternate function - again, compare your code with something that's known to work.

[diyaudio]

Take a working piece of code (lots of examples, from the library or the ghetto thread), get it to work on your set-up and then tailor to your application (on usart2 for example).

On first glace, you didn't activate the alternate function - again, compare your code with something that's known to work.

I think, I will take a break after I've taken your advice, its been a long HOT unproductive day.

[dannyf]

Here is your code modified (bugs fixed and added flipping of PA4 in the main loop).

Hopefully it helps convince you that the issue is with your code, not the standard library.

The flipping of PA4 is to show you why on a fast mcu like this, not using the interrupt is so costly.

[westfw]

Code: [Select]

void rcc_config(void)
{

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA , ENABLE);
 
  /* USART-1 clock enable */
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
 
  /* USART-2 clock enable */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
}

Turn on RCC_APB2Periph_AFIO (and I guess RCC_APB1Periph_AFIO) as well.  I don't THINK that any of the other functions enabled it...

[dannyf]

In case you really want to see your string on the TX line, here it is.

In this case, the transmission is done via the isr. Because of that, the mcu is freed up, as demonstrated the high rate at which PA4 is flipped.

[andyturk]

[...] the transmission is done via the isr. Because of that, the mcu is freed up [...]

You mean DMA?

[diyaudio]

Right. vie solved all the issues.

1) First the easy one decoding wasn't triggering correctly, was a mistake on my side.
2) I studied the STM32F103XX clock tree and discovered the "copy and pasted" clock template I was using used a 25Mhz crystal, so the HSE setup was totally wrong which in turn calculated "incorrect baud", this was fixed and I immediately got the decoded packets! great success.
3) Saved the best for last, these shit ebay ftdi boards never worked (all three of them), I re-tested using a working ftdi cable and the results was obvious, the ebay ftdi board I used never worked! not just one but all three of them, they all send bogus data!

I was really happy to see the STM32F103C8TC6 board I got off ebay working after all this trouble.

@danny
Now that Im on path, I will consider your findings that you posted using an ISR approach. Thanks for that tip.






   

[dannyf]

clock tree

I provided a set of routines in the ghetto thread that can be used to set clock sources and frequencies easily. It was written for STM32F030 but can be easily ported to STM32F103 or any other STM32 chips.

The uart modules on those chips are fairly simple to operate. The initial difficulties are, as usually, with the set-up, both software and hardware.