cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 Discovery UART problem using Rn-41 Bluetooth module

bee2
Associate II
Posted on March 21, 2013 at 08:24

I have the STM32F4 communicating with hyperterminal on windows 7 using a serial cable. My discovery board is plugged into an Embest expansion board which breaks out to an RS232 serial port and at the PC end I have a usb to serial converter as I have no serial port. I have gone back to the UART example Embest provide in their examples folder for the expansion board. All works fine hyperterminal receives the printf data.

I want to replace the serial cable with a Roving networks Rn-41-ms bluetooth device. I have fitted the Rn-41 to my board with a 3V supply and ground and I can talk to it via hyperterminal fine i.e can use get/set comands to confirm change settings on the device. I am using a bluetooth dongle at PC end.

My problem comes when trying to transmit from my program via the bluetooth device to hyperterminal. In the UART example COM1 is used for UART6 which is the serial port on the expansion board, so I have selected COM3 for UART1 which is shown STM32F4_discovery.h file. The way I have changed to COM3 is by basically changing all the COM1's in the main.c to COM3 but I've also enabled hardware flow control as this is required for the RN-41 device. The program compiles and downloads fine but no data is recieved by hyperterminal when run on the ST board?

I have set board rate, parity, stop bits etc the same on ST program, Rn-41 bluetooth device, PC bluetooth dongle and hyperterminal.

Any ideas or advice on other settings I should consider when changing com ports or debugging methods for UART appreciated, I don't have use of an oscilloscope until monday.

Expansion board

http://www.embest-tech.com/shop/product/dm-stf4bb-base-board.html

Bluetooth module

http://uk.farnell.com/jsp/displayProduct.jsp?sku=2144010&CMP=e-2072-00001000&gross_price=true&mckv=YKMwxwd8|pcrid|14164337469|plid|{placement}

#stm32f4 #rn-41 #bluetooth
23 REPLIES 23
bee2
Associate II
Posted on March 29, 2013 at 12:18

I am now communicating with the bluetooth module and I'm able to send data to hyperterminal fine but having problems receiving data from hyperterminal. I have gone back to the example UART code (as posted above). I'd just like to confirm my understanding of the while loop below (extracted from above code).  Sorry if my question is a bit basic.

The program waits at the internal while condition until data is received at  COM1 which enables  USART_FLAG_RXNE the program then comes out of the while condition as it is no longer == RESET.

The received data is saved as 'ch' and then sent sent back out to COM1 with the printf function, so I should see it in hyperterminal?

With the variable 'ch' not being an array does ch change for every bite read?

I've tried to monitor 'ch' in debug mode but I'm unable to see a value which is making me think I am miss understanding something?

 while (1)

  {

    int ch;

    while (USART_GetFlagStatus(EVAL_COM1, USART_FLAG_RXNE) == RESET);

 

   ch = USART_ReceiveData(EVAL_COM1);

 

   printf(''%c'', ch&0xff);    

  }

}

Sorry again if question is a bit basic I've really spent some time trying to sort this before posting. 

Posted on March 29, 2013 at 13:39

The program waits at the internal while condition until data is received at  COM1 which enables  USART_FLAG_RXNE the program then comes out of the while condition as it is no longer == RESET

Yes. But what code do you have supporting putchar/printf? Where does that go?
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on March 29, 2013 at 13:44

while(1)
{
int ch;
while(USART_GetFlagStatus(EVAL_COM1, USART_FLAG_RXNE) == RESET); // Wait on Received Character
ch = USART_ReceiveData(EVAL_COM1);
while(USART_GetFlagStatus(EVAL_COM1, USART_FLAG_TXE) == RESET); // Wait on Transmitter Empty
USART_SendData(EVAL_COM1, ch);
}

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
bee2
Associate II
Posted on March 29, 2013 at 19:32

Hi Clive, thanks again for reply, you seem to be the most helpful person on the internet.

The only code I have supporting putchar/printf is as above in the main.c file I posted.

First is before main :

#ifdef __GNUC__

  /* With GCC/RAISONANCE, small printf (option LD Linker->Libraries->Small printf

     set to 'Yes') calls __io_putchar() */

  #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)

#else

  #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)

#endif /* __GNUC__ */

Second is after main:

PUTCHAR_PROTOTYPE

{

  /* Place your implementation of fputc here */

  /* e.g. write a character to the USART */

  USART_SendData(EVAL_COM3, (uint8_t) ch);

  /* Loop until the end of transmission */

  while (USART_GetFlagStatus(EVAL_COM3, USART_FLAG_TC) == RESET);

  return ch;

} My understanding is the first section setups the printf function and the second is what enables the data to be sent to the serial port with the printf, am I about right?  I'm just trying to work out if I should be reading from the serial port with the standard example, I'm thinking so.

I'll try the bit of code you posted when I get home, cheers.

bee2
Associate II
Posted on March 29, 2013 at 19:39

I'm actually unsure why the variable 'ch' is used for both senddata and receivedata, why isnt a seperate variable used for send and receive functions, is this because you would only ever be sending or recieving at any one time?

Posted on March 29, 2013 at 20:11

I used ch as a holding variable here as I'm simply echoing a value back, so I'm not sure were else I would put it, or what difference that would make.

In a more practical application I would be using a couple of ring/fifo buffers.

The putchar/printf stuff might work with GNU/GCC, my practical experience with Keil suggests I need to do it somewhat differently.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
bl
Associate II
Posted on April 01, 2013 at 17:16

Folks 

Here is the interrupt code that works for me:-

extern ''C'' void USART1_IRQHandler(void)

    {

    // check if the USART1 receive interrupt flag was set

    if (USART_GetITStatus(USART1, USART_IT_RXNE ))

{

static uint8_t cnt = 0; // this counter is used to determine the string length

char t = USART1 ->DR; // the character from the USART1 data register is saved in t

/* check if the received character is not the LF character (used to determine end of string)

* or the if the maximum string length has been been reached

*/

if ((t != '\n') && (cnt < MAX_STRLEN))

   {

   received_string[cnt] = t;

   cnt++;

   }

else

   { // otherwise reset the character counter and print the received string

   cnt = 0;

   USART_puts(USART1, received_string);

   }

}

    }

and also I've changed the USART_puts function to:-

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

    {

    while ((*s) && (*s != '\n') && (*s != '\r')) // loop until you get to the end of the string

{

// wait until data register is empty

while (!(USARTx->SR & 0x00000040)) ; // no body to this while just waiting for the buffer to be free

USART_SendData(USARTx, *s);

s++;

}

    while (!(USARTx->SR & 0x00000040))

; // waiting for the buffer to be free

    USART_SendData(USARTx, '\r');

    while (!(USARTx->SR & 0x00000040))

; // waiting for the buffer to be free

    USART_SendData(USARTx, '\n');

    // void USART_SendData(USART_TypeDef* USARTx, uint16_t Data);

    }

Now on to getting USART2 working......

Posted on April 01, 2013 at 18:46

That would tend to dwell in the ISR for an awful long time, and you'd want to address the NUL termination properly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
bl
Associate II
Posted on April 02, 2013 at 08:46

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6mf&d=%2Fa%2F0X0000000bvO%2FnAqHZT37kjDWc1w549hZxnXBxTanoMw.4daIDwDxzVU&asPdf=false
Posted on April 02, 2013 at 15:34

Isn't there a potential conflict with PD5, RED LED, USB OverCurrent on the STM32F4-Discovery board?

Suggest you use USART3 PD8 (TX) PD9 (RX)
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..