sprintf not working when ADC started

[JS8]

I'm trying to send ADC results over to a receiver via UART, but somewhy the program freezes on sprintf() IF I have called HAL_ADC_Start_DMA() before. If I call sprintf() before HAL_ADC_Start_DMA() it works fine. However, I need to call it after starting the DMA. How can I fix this?

int main(void)
{
  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

/* Configure the peripherals common clocks */
  PeriphCommonClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_MEMORYMAP_Init();
  MX_ADC1_Init();
  MX_LPUART1_UART_Init();
  /* USER CODE BEGIN 2 */

  uint32_t values[4] = {0, 0, 0, 0};
  HAL_ADC_Start_DMA(&hadc1, values, 4);

  char str[100];
  sprintf(str, "TEMP_ADC: %d\n", values[1]);
  int size = (int)(ceil(log10(values[1]))+12)*sizeof(char);
  HAL_UART_Transmit(&hlpuart1, str, size, 100);

  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_8, SET);

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
	  HAL_Delay(1000);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

[Tesla DeLorean]

>>Do I also need to change the 'Number of Conversions' in the .ioc?

I don't know, I just code for myself.

Fix whatever you need to associate the size of the buffer, with the DMA, assuming the 4's here, but would assume the ADC is only 16-bit wide.

uint32_t values[4] = {0, 0, 0, 0};
  HAL_ADC_Start_DMA(&hadc1, values, 4);

One of the problems is that if sampling fast enough you'll end up with interrupts at 500 KHz to 1 MHz, which will be too hard for the processor do much else than enter/exit the interrupt handler. And none of your foreground code will have any time to execute.

You could try decimating the "sample rate" such that it might run at a few KHz