cancel
Showing results for 
Search instead for 
Did you mean: 

Error Transmitting data via UART when using ADC & DMA (works separately)

ponuliukas
Associate II

Hi All,

I have been a little confused about my code and would appreciate some help greatly...

I have a basic program where I would like to read the ADC values from a sensor, and transmit them via UART for later signal processing and whatnot.

The structure is simple, and when I tested out reading the values from the ADC, as well as sending strings via UART - they both work perfectly fine. But now when I merge the two, the UART does not work anymore... I do not see anything in my serial monitor (Putty)

I feel like I am missing something big, but cannot find it. I would appreciate it if someone pointed me in the right direction :)

in my main, I have: 

 

 

uint32_t value[2]; // start adc in DMA mode
int isSent = 1;
uint8_t tx_buffer[] = "Welcome to BinaryUpdates!\n\r"; 

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  MX_TIM3_Init();
  MX_TIM4_Init();
  MX_TIM2_Init();
  MX_USART6_UART_Init();

  HAL_ADC_Start_DMA(&hadc1, value, 2);

  while (1)
  {
	  if (isSent == 1)
	      {
	  	  HAL_UART_Transmit_DMA(&huart6, tx_buffer, 27);
//       HAL_UART_Transmit_DMA(&huart6, value[0], sizeof(value[0]));
	  	  isSent = 0;
	      }
	      HAL_Delay(1000);
  }
}
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
	isSent = 1;
}

 

 

16 REPLIES 16
Andrew Neil
Evangelist III

@ponuliukas wrote:

the UART does not work anymore... 


What do you mean by that?

  • It transmits nothing at all ?
  • It transmits something, but not what you wanted ?
  • other ?

 

EDIT:

You haven't shown your definition of isSent, but it should be 'volatile'

Do you have any conflicts between ADC and UART pins?

raptorhal2
Lead

Edit: Cancel - I misunderstood. How do you get "value" into tx_buffer ?

Andrew Neil
Evangelist III

@ponuliukas wrote:

 

 

uint8_t tx_buffer[27] = "Welcome to BinaryUpdates!\n\r"; 

 

 


Although it doesn't matter in the code you've shown so far, note that this does not leave space for a terminating NUL - so that won't be a proper C string.

To have a proper C string:

 

uint8_t tx_buffer[] = "Welcome to BinaryUpdates!\n\r"; 

 

Thank you for the reply @Andrew Neil and @raptorhal2 , and apologies for not being perfectly clear. I edited the question :) 

It's confusing to edit the question after people have already commented on the question in its original form!

It's better to post an update as a reply.

Again,  isSent should be 'volatile'

 


@ponuliukas wrote:

the UART does not work anymore... I do not see anything in my serial monitor (Putty) 


That could be because your UART is sending something that's not visible to PuTTY ?

Have you check on the wires with a logic analyser or oscilloscope?

You're ignoring the return value from HAL_UART_Transmit_DMA - it might be telling you something ...

https://community.st.com/t5/stm32-mcus-boards-and-hardware/hal-rcc-oscconfig/m-p/674455/highlight/true#M19028 

What happens if you do away with the DMA, and just use a plain blocking send?

"value" is in binary, you will have to covert it to ASCII characters to be displayed by Putty. Think printf, or make your own conversion.

Good to know, will do that from now on :) 

 

When I just use UART I see the text "Welcome to Binaryupdates". It is only when I uncomment:

HAL_ADC_Start_DMA(&hadc1, value, 2);

do I stop seeing anything in my serial monitor.

I have not checked with a logic analyzer nor an oscilloscope :(  I Do not have an access to one unfortunately... 

 

Same thing happens if I just use "HAL_UART_Transmit" - It works alone, but If I start the ADC DMA, it doesn't work...

@raptorhal2 at this point, I would like to start by just sending the 27 characters (Welcome to BinaryUpdates!) to confirm that I can send data via uart and read the sensor values at the same time. 

Check for any conflicts between ADC and UART pins?

Doesn't look like there could be any conflict. I will scrutinize the PCB itself more

ponuliukas_0-1715784396465.png