Why USART stops with ADC? STM32F103C8

[Jesus Villanueva]

Posted on October 08, 2017 at 23:50

Hi to everybody!! I have a problem with an STM32F103C8 board 'Blue Pill'. I have configured the two ADC converters to make measurements, I also have configured the USART1 to send and receive information from and to the computer. (I can turn on a LED and I can see a printf from the MCU) Each one works good, but when I add the both functions to the int main(), the USART stops to work, while the ADC keeps working good. I know that the ADC keeps working because I can see the data in the debug tool. To send and receive serial information I use a software named DOCKLIGHT. 

I hope someone would help me to know if I have to configure something in the KEIL uVision 5 to program this board. Thank you very much

[T J]

Posted on October 09, 2017 at 00:12

Printf is a bit dodgy, it may be your problem.

I think with Keil, it is definitely a printf issue.

The issue is that the printf is trying to use the same USB link that the debugger is using.

I had to move to a different serial port with pins, to make it all work.

[Jesus Villanueva]

Posted on October 09, 2017 at 00:30

I use a serial to USB converter to  make the serial communication. I've worked in this way before and everything was good, even with the STLink connected. But now that I create a new project, this happens. I'll disconnect the STLink before to start the serial connection.I'll share with you what did happened.

[Jesus Villanueva]

Posted on October 16, 2017 at 04:21

HI guys!! I'm really sorry for the late answer but here I have something that is very interesting

When I use the two ADC available on chip, the USART stops. But if I configure the ADC1 for work with two channels, the USART works good even if I have the ST-Link and my serial to usb converter connected at the same time.

I'm such as a new on this micro, so I've been practicing with the other peripherals and also, when I use the SPI alone (with the examples provided by the web site) this works good, but if I add the USART, The SPI also stops to work!!

So, do you think that it is a problem in the software configuration?? Thank you to everybody

[AvaTar]

Posted on October 16, 2017 at 08:20

Without some more details of your code it is difficult so see.

But I suspect a problem with interrupt runtimes.

Assuming your peripherals (ADC, UART, SPI) working on interrupts, you probably use the default priorities, i.e. all the same.

But once you miss a received character (UART) because excessive runtime of another interrupt, you get an OV error that stops the UART until you explicitly clear it.

Which, I guess, you don't yet.

And the same goes probably for SPI.

[Jesus Villanueva]

Posted on October 19, 2017 at 19:56

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=0680X000006I6tc&d=%2Fa%2F0X0000000bxZ%2Ftv_Zg_kEkFB_Ir.pwvbc8y7x9_MkTtdgxQ6coRXGmX8&asPdf=false

[Tesla DeLorean]

Posted on October 19, 2017 at 21:38

You should always front wait for TXE on USART_SendData() with

while (!(USART1->SR & USART_FLAG_TXE)); 

You are checking if the register is empty and ready to take data, don't bother back waiting on TC

You are passing an ADDRESS, use the Ampersand

DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)&ADC1ConvertedValue; 

[Jesus Villanueva]

Posted on October 23, 2017 at 23:50

Well, I have some images to share, I hope they be useful to know more about this issue.

In the first image I use the debug session to know the status of the USART1, as you can see in the DR register there's a 0.

The second image show's how after we send a data trough the serial port, the DR register changes and the ''char'' variable ''b'' changes from 0 to ''0x40 '@'. In this case the led connected to the board turns on and returns a message of ''Prendido'' (Turn On). At this point everything's all right.

The third image shows how I add the function adc_configuracion, to start the two ADC converters and as I say, the char variable ''b'' is used to receive the data from the serial port. I used the instruction that

Turvey.Clive.002

‌ recommended to know if the USART->DR is in conditions of receive or send data.(also y fixed the &error in the adc configuraton, thank you!!)

In the last image I show how the DR register receives the data (0x40) but the variable ''b'' doesn't changes the status and the led doesn't turn on, the word ''Prendido'' do not appear in the screen as well.

Is in this moment when the ''interrupt runtimes'' (that

meyer.frank

‌ has commented to verify), are in conflict?? Because it seems that after to receive the data in the register, this information doesn't arives to the USART bus, or why this would occur: The variable ''b'' do not receive the information from the USART.

Thank you very much!!

[AvaTar]

Posted on October 24, 2017 at 10:25

I don't see any UART receive code, and and no interrupt handler.

Perhaps you are polling UART1->RX, and don't use interrupts ?

With busy-looping while UART transmissions (like this):

for ( ; *s; s++)

{

     USART_SendData(USARTx,*s);

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

}

you will surely have trouble to fetch received chars in time.

One missed char sets the OV flag, and stops reception until you explicitly reset the flag.