cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F0 connected with Hc 06, do not recive the data

MMaj.1
Associate II

I've been trying to make connection with STM32F0 Discovery and hc-06 bluetooth module via USART2. I've configured Discovery as shown on figure below. Additionally there is an nvic interruption. Hc-06 is configured the same way as Discovery.

uint8_t bluetooth_recive = 1;
HAL_UART_Receive_IT(&huart2, &bluetooth_recive, 1);

I've checked hc-06 if it's passing values sended form app on smartphone. App I was using was Bluetooth terminal HC-05. I was sending ASCII code. Connected hc-06 via usb_uart converter

was passing values to computer's application Realterm.

So my question is if there is a configuration problem or something else..

0690X00000BvdZXQAZ.jpg

4 REPLIES 4

>>So my question is if there is a configuration problem or something else..

Hard to say, try sending data, and checking with a scope. Check other board rates, or getting the module in to AT command mode.

Make sure the TX/RX sense of the pins is wired correctly. That the output on the HC06 goes to the input on the STM32

Check functionality of the HC06 using a USB-to-CMOS Serial converter, and interact on a PC

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
S.Ma
Principal

No pb with HC-06 on STM32L4R5 on my side.

You can route the HC-06 on your power up and disabled STM32 board to the STLink VCP RX/TX and use Teraterm on your PC to send/receive AT commands.

Then you can activate the STM32 UART and see if you can talk to HC-06. There is no SmartIO on STM32 so you need to develop UART (from STLink) to UART (to HC06) bridge for live debug from the PC.

AT+BAUD8 to update the HC-06 to 115200bps.

MMaj.1
Associate II

There is no communication problem with HC-06 via AT commands. Pins are double checked. I will try now communicate with borad/pc with different configurations.

MMaj.1
Associate II

Okay, I changed interruption type. Now I am using DMA, which unexpectedly works...

Now, can someone tell me why I am not stoping my ADC with UART DMA? Code below.

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart2) {
	if(bluetooth_recive == 0)
	{
		HAL_ADC_Stop_DMA(&hadc);
	}
	else
	{
		HAL_ADC_Start_DMA(&hadc, (uint32_t*)adc_buf, ADC_BUF_LEN);
	}
}

Code logicly seems fine.

I am using STM studio to check memory. I see that my bluetooth_recive change, but my buffer memory don't stop changing despite of UART DMA. I am sending 0 and 1 via bluetooth.