How to make stm32f4 communicate with hyperterminal

[salahuddinash]

Posted on April 19, 2014 at 22:32The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on April 19, 2014 at 22:40

What USB-to-Serial module are you using?

It really isn't that complicated to wire up. The USART6 TX pin of the STM32 would likely connect with the CMOS Serial RX pin of the module, the reverse for the RX-to-TX, and a ground. The PC would recognize your USB-to-Serial dongle, give it a COM#, and you'd open that in HyperTerminal at the Baud/Bit/Parity setting you picked. I'd recommend something better than HyperTerminal, look at Real Term or Clear Term Having a scope to look at the signals may help if you have the clocks/baud rate wrong. Send actual characters, sending 0 thru 31 as binary gets you control characters (refer to an ASCII chart)

[salahuddinash]

Posted on April 20, 2014 at 00:47

What USB-to-Serial module are you using?

its name is CP2102, its picture is included in the attachments. It really isn't that complicated to wire up. Really? I hope so but I find it so complicated The USART6 TX pin of the STM32 would likely connect with the CMOS Serial RX pin of the module, the reverse for the RX-to-TX, and a ground. I did exactly so The PC would recognize your USB-to-Serial dongle, give it a COM#, and you'd open that in HyperTerminal at the Baud/Bit/Parity setting you picked. How could I know if the PC recoginzed the USB-to_Serial dongle ? What do you mean with ''give it a COM#''? I'd recommend something better than HyperTerminal, look at Real Term or Clear Term Actually I first tried RealTerm and it looks more easy that HyperTerminal but it didn't work too .. and I gave it the sameBaud/Bit/Parity setting in the kit.. Having a scope to look at the signals may help if you have the clocks/baud rate wrong.What do you mean? How can I have a scope to look at the signals? Send actual characters, sending 0 thru 31 as binary gets you control characters (refer to an ASCII chart) does it make a difference if I sent different number every time, like in the code above? ________________ Attachments : USB-to-TTL_module.JPG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I19B&d=%2Fa%2F0X0000000bj1%2FzPh9gXaMRcsrQmGieTHV4b9h12AVRYnch159dH4Aj4Y&asPdf=false

[Tesla DeLorean]

Posted on April 20, 2014 at 02:44

You should be able to see the port in Device Manage, it should be assigned a COM#, like COM23 or COM34. You should confirm windows recognizes the attachment of the adapter, and that it has loaded appropriate drivers.

If you send a 'U' character repeatedly, you can measure the bit timing with an oscilloscope, and could verify that the baud rate is correct, and that the port is transmitting properly. You are not sending a ''number'' as much as a character, you'd be better served sending A-Z characters or 0-9 digits (ie '0', '1' .. '9'), sending characters below 32 will just result in the terminal doing weird things, or printing odd characters.

[salahuddinash]

Posted on April 20, 2014 at 15:05 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=0680X000006I6eb&d=%2Fa%2F0X0000000bsX%2F1lj7Z0LOOTzZnbzmb4AyMGjMVpVXEnQXDxTQirHnrGA&asPdf=false

[Tesla DeLorean]

Posted on April 20, 2014 at 18:57

Now where is the problem?

You confuse Transmit and Receive, you have to handle both, separately. Don't be using delays in the interrupt routine, they will result in data loss. Use TXE and RXNE interrupts.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4%20USART%20receive%20problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1964

[salahuddinash]

Posted on April 21, 2014 at 13:49

You confuse Transmit and Receive, you have to handle both, separately.

I don't understand what do you mean ?? In the Interrupt handler above it just had to do something if the TC flag is set .. Don't be using delays in the interrupt routine, they will result in data loss.Use TXE and RXNE interrupts.Ok, here's my modified ISR without any delays and it uses your template with TXE and RXNE interrupts and it's supposed to blink the LEDs if data is sent or received but that doesn't happen, although the RealTerm is receiving data from the KITand when using debugger, it didn't even entered the ISR<b>

//My ISR 

void USART6_IRQHandler(void){ if (USART_GetITStatus(USART6, USART_IT_TXE) != RESET) // Transmit the string in a loop  {    //clear interrupt flag USART6->SR &= ~USART_FLAG_TXE; //blink LEDs to make sure if the program works properly  if(!(GPIOD->ODR & 0xF000)) { GPIOD->ODR |= 0xF000; } else { GPIOD->ODR &= ~0xF000; }  }   if (USART_GetITStatus(USART6, USART_IT_RXNE) != RESET) // Received characters modify string  {    //clear interrupt flag USART6->SR &= ~USART_FLAG_TXE; //blink LEDs to make sure if the program works properly  if(!(GPIOD->ODR & 0xF000)) { GPIOD->ODR |= 0xF000; } else { GPIOD->ODR &= ~0xF000; }  }}</b>why it doesn't work ?

[Tesla DeLorean]

Posted on April 21, 2014 at 15:46

Yeah, I don't think you're servicing the interrupts properly, and you're not configuring the NVIC either. Note example in my previous cite.

This should be a more effective IRQ demo for USART6

// STM32 USART IRQ TX/RX Loop (USART6 Tx PC.6, Rx PC.7) STM32F4 Discovery - sourcer32@gmail.com
#include ''stm32f4_discovery.h''
volatile char StringLoop[] = ''The quick brown fox jumps over the lazy dog

'';
/**************************************************************************************/
void RCC_Configuration(void)
{
/* --------------------------- System Clocks Configuration -----------------*/
/* USART6 clock enable */
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART6, ENABLE);
/* GPIOC & D clock enable */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC | RCC_AHB1Periph_GPIOD, ENABLE);
}
/**************************************************************************************/
void GPIO_Configuration(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
/*-------------------------- GPIO Configuration ----------------------------*/
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOC, &GPIO_InitStructure);
/* Connect USART pins to AF */
GPIO_PinAFConfig(GPIOC, GPIO_PinSource6, GPIO_AF_USART6);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource7, GPIO_AF_USART6);
/* Configure LED pins */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12 | GPIO_Pin_13 | GPIO_Pin_14 | GPIO_Pin_15;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOD, &GPIO_InitStructure);
}
/**************************************************************************************/
void USART6_Configuration(void)
{
USART_InitTypeDef USART_InitStructure;
/* USARTx configuration ------------------------------------------------------*/
/* USARTx configured as follow:
- BaudRate = 115200 baud
- Word Length = 8 Bits
- One Stop Bit
- No parity
- Hardware flow control disabled (RTS and CTS signals)
- Receive and transmit enabled
*/
USART_InitStructure.USART_BaudRate = 115200;
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_Init(USART6, &USART_InitStructure);
USART_Cmd(USART6, ENABLE);
USART_ITConfig(USART6, USART_IT_TXE, ENABLE);
USART_ITConfig(USART6, USART_IT_RXNE, ENABLE);
}
/**************************************************************************************/
void NVIC_Configuration(void)
{
NVIC_InitTypeDef NVIC_InitStructure;
/* Configure the NVIC Preemption Priority Bits */
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_0);
/* Enable the USART6 Interrupt */
NVIC_InitStructure.NVIC_IRQChannel = USART6_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
}
/**************************************************************************************/
void USART6_IRQHandler(void)
{
static int tx_index = 0;
static int rx_index = 0;
if (USART_GetITStatus(USART6, USART_IT_TXE) != RESET) // Transmit the string in a loop
{
USART_SendData(USART6, StringLoop[tx_index++]);
if (tx_index >= (sizeof(StringLoop) - 1))
tx_index = 0;
GPIOD->ODR ^= 0xA000;
}
if (USART_GetITStatus(USART6, USART_IT_RXNE) != RESET) // Received characters modify string
{
StringLoop[rx_index++] = USART_ReceiveData(USART6);
if (rx_index >= (sizeof(StringLoop) - 1))
rx_index = 0;
GPIOD->ODR ^= 0x5000;
}
}
/**************************************************************************************/
int main(void)
{
RCC_Configuration();
GPIO_Configuration();
NVIC_Configuration();
USART6_Configuration();
while(1); // Don't want to exit
}
/**************************************************************************************/

[salahuddinash]

Posted on April 21, 2014 at 22:20

Thanks very much sir, it works well now 

[pacman]

Posted on November 20, 2015 at 03:08

A few days ago, I started a new project on my STM32F4 Discovery board.

I wanted to use my CP2102 USB-to-U(S)ART device with the board and struggled a lot for 2-3 days. One of the reasons for my struggling was that HAL has been updated to v1.5.0 and the examples from the net just won't build anymore. I could get 2400 baud working fairly well. I was using USART1. I decided to make a STM32Cube 1.5.0 vairant of Clive's example, and I found out what my problem was. USART1 does not seem to work well with baud rates above 2 I knew I had the CP2102 working with another Cortex-M based microcontroller (of a different brand), so I wouldn't give up! Initially I would blame the board layout, but PC6 and PC7 are further away from the MCU than PA9 and PA10, so it must be something else. After 'modernizing' Clive's example, I discovered that if I set the baud rate to 4800 baud, it will work on USART6, but not on USART1. I've attached my code; I've made some efforts to make it compatible to a generic user's system (please forgive me if it causes problems). I'll try and visit this thread now and then, but I might not be online often, so have in mind it might take some time for me to see any replies; I'll watch the thread for a few days from the date of this post, though. -Thanks again to you Clive for the knowledge-database you've built. ;) ________________ Attachments : USARTx-HAL-test.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I191&d=%2Fa%2F0X0000000biz%2FkCMi.zPA4bDEhm7lTUhFTv9PeR8bGv3wDw1oveZjaGA&asPdf=false