2025-02-04 03:25 PM - last edited on 2025-02-04 10:47 PM by SofLit
Driving DAC1 channel 1 with
HAL_DAC_Start(&hdac1, DAC_CHANNEL_1);
...
while (1) {
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 4095UL);
HAL_Delay(100UL);
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 0UL);
HAL_Delay(100UL);
}
to generate 5 Hz, 50% duty cycle, 0 - 2.5v. Amplitude as expected but frequency varies from 1 - 4s and duty cycle varies from 20 - 80%: not expected. DAC1 configured like
DAC1 clocked at 65 MHz. When I step into HAL_DAC_SetValue() I see where the 0 - 4095 value is written to data register (12-bit, right-aligned). But sometimes after writing 4095 the output pin reads zero; and sometimes after writing zero the output pin reads 2.5v. I can't explain why this happens. DAC Instance following write looks like
I am the only writer on the data register.
Solved! Go to Solution.
2025-02-08 01:49 PM
This is a STM32CubeMX v6.13 issue: https://community.st.com/t5/stm32cubemx-mcus/stm32h563-dac1/td-p/770530
2025-02-06 09:52 AM - edited 2025-02-06 09:52 AM
Custom board. I lifted the op amp pin connected to PA4 (DAC1 channel 1). Same behavior. This isolates the problem to the MCU and DAC peripheral.
2025-02-06 10:06 AM - edited 2025-02-06 10:07 AM
Using same custom board, I ran an old project capable of generating the desired waveform. It works; desired waveform generated.
The new project (cannot generate desired waveform) used STM32CubeMX 6.13 and STM32Cube FW_H5 V1.4.0.
The old project (waveform good) used STM32CubeMX 6.12 and STM32Cube FW_H5 V1.3.0. I migrated the old project to STM32CubeMX 6.13 and STM32Cube FW_H5 V1.4.0. Now the old project which used to work -- fails. It manifests the same weird DAC behavior as the new project.
The code generated from the IOC file is identical. So the only difference is FW_H5 V1.4.0 vs FW_H5 V1.3.0.
How do I revert the project to STM32CubeMX 6.12 and FW_H5 V1.3.0?
2025-02-06 11:34 AM
What is the reference, VREF+?
JW
2025-02-06 11:35 AM
2.5v
2025-02-06 11:36 AM
Did you measure it?
JW
2025-02-06 11:58 AM
Yes. 2.57 to be exact. Stable.
2025-02-06 08:00 PM
I conclude: either the following code is wrong for running the DAC
HAL_DAC_Start(&hdac1, DAC_CHANNEL_1);
...
while (1) {
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 4095UL);
HAL_Delay(100UL);
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 0UL);
HAL_Delay(100UL);
}
or there's something wrong with migrating to STM32CubeMX 6.13 and STM32Cube FW_H5 V1.4.0 for H563.
If the migration is the problem, I need to revert a project from H5 V1.4.0 to V1.3.0. How to do that easily? Or do I remove H5 V1.4.0 from the repository and then re-create a project to grab the latest firmware version?
2025-02-07 09:26 AM
Comparing stm32h5xx_hal_msp.c from the "good" project and the "bad" project I see the "good" project has the following, which is absent from the "bad" project
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
if(hdac->Instance==DAC1)
{
/* USER CODE BEGIN DAC1_MspInit 0 */
/* USER CODE END DAC1_MspInit 0 */
/** Initializes the peripherals clock
*/
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_DAC;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
{
Error_Handler();
}
Adding the above code to the "bad" project's stm32h5xx_hal_msp.c fixes the problem.
What needs to change in the "bad" project's IOC file to add the above code to stm32h5xx_hal_msp.c? There is nothing obvious in the GUI representations of the IOC files to explain the difference.
I am attaching IOC files from "good" and "bad" projects. I don't see anything in a diff of the 2 files to explain the missing code.
The stm32h5xx_hal_msp.c for the "good" project was generated with STM32CubeMX v6.12.0. The stm32h5xx_hal_msp.c for the "bad" project was generated with STM32CubeMX v6.13.0. At this point I am suspicious of MX 6.13.0.
2025-02-08 01:49 PM
This is a STM32CubeMX v6.13 issue: https://community.st.com/t5/stm32cubemx-mcus/stm32h563-dac1/td-p/770530