Skip to main content
bee2
bee2
Associate III
March 21, 2013
Question

STM32F4 Discovery UART problem using Rn-41 Bluetooth module

  • March 21, 2013
  • 23 replies
  • 4169 views
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
This topic has been closed for replies.

23 replies

Show previous replies
Tesla DeLorean
Tesla DeLorean
Guru
March 29, 2013
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Tesla DeLorean
Guru
March 29, 2013
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
bee2
bee2Author
Associate III
March 29, 2013
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
bee2Author
Associate III
March 29, 2013
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?

Tesla DeLorean
Tesla DeLorean
Guru
March 29, 2013
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
bl_it
bl_it
Associate III
April 1, 2013
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......

Tesla DeLorean
Tesla DeLorean
Guru
April 1, 2013
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
bl_it
bl_it
Associate III
April 2, 2013
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
Tesla DeLorean
Tesla DeLorean
Guru
April 2, 2013
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
bl_it
bl_it
Associate III
April 2, 2013
Posted on April 02, 2013 at 16:18

Clive1

That's what I was missing!! I was focused on Chip level and not board level!! and yes I've moved to USART3 PD8 (TX) PD9 (RX) and that seems to work fine!!

CS

Show more replies
Terms & ConditionsAccessibility statement