DAC doesn't work on my Nucleo stm32f446RE

[HDKLog]

Hi,
I'm trying to make output on pin A4 with DAC driver and it doesn't work. My board is Nucleo 64 (STM32f446RE) and here is my code:

Code: Select all

int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  /*
   * Starting DAC1 driver, setting up the output pin as analog as suggested
   * by the Reference Manual.
   */
  static const DACConfig dac1cfg = {
        .init         = 4047U,
        .datamode     = DAC_DHRM_12BIT_RIGHT
      };

  palSetPadMode(GPIOA, 4, PAL_MODE_INPUT_ANALOG );
  dacStart(&DACD1, &dac1cfg);
  dacPutChannelX(&DACD1, 0, 4000);

  /*
   * Normal main() thread activity, if the button is pressed then the DAC
   * transfer is stopped.
   */
  while (true) {
    chThdSleepMilliseconds(500);
  }
  return 0;
}


what I'm doing wrong?

[tfAteba]

Hi HDKLog,

You probably modified the testhal DAC example for STM32F4xx to make your example.

Here is what I will look at first:

1) Are you sure that the channel "0" is connected to GPIOA Pin 4??

2) Did DAC channel 0 is enable in hal configuration?

Just a suggestion:

Did you first try to run the testhal example with small configurations for your board?

It will help you to understand how thing works and then make your own program after that!

[HDKLog]

Thanks for quick reply tfAteba

Here is my mcuconf.h DAC config:

Code: Select all

/*
 * DAC driver system settings.
 */
#define STM32_DAC_DUAL_MODE                 FALSE
#define STM32_DAC_USE_DAC1_CH1              TRUE
#define STM32_DAC_USE_DAC1_CH2              TRUE
#define STM32_DAC_DAC1_CH1_IRQ_PRIORITY     10
#define STM32_DAC_DAC1_CH2_IRQ_PRIORITY     10
#define STM32_DAC_DAC1_CH1_DMA_PRIORITY     2
#define STM32_DAC_DAC1_CH2_DMA_PRIORITY     2
#define STM32_DAC_DAC1_CH1_DMA_STREAM       STM32_DMA_STREAM_ID(1, 5)
#define STM32_DAC_DAC1_CH2_DMA_STREAM       STM32_DMA_STREAM_ID(1, 6)


and halconf.h

Code: Select all

/**
 * @brief   Enables the DAC subsystem.
 */
#if !defined(HAL_USE_DAC) || defined(__DOXYGEN__)
#define HAL_USE_DAC                 TRUE
#endif


I'm checking GPIOA Pin 4 and have attached LED to it and it doesn't light up when I'm setting 4000 to channel 0

[tfAteba]

Ok,

Your configuration is looked me correct. I'm going to make some test in my side and see if I find something that can help you to resolve you problem.

But I will make my test under Nucleo 401 re I don't have your board. But the principle is the same.

Look carefully if the GPIOA pin 4 can generate the DAC signal for channel 0. We have to be sure for that first.

[tfAteba]

sorry but my board don't have a DAC. I will try to find by another way, to understand what happen.

[tfAteba]

I knew it, I found a 429 board, finally I can make test and give feedback

[tfAteba]

Hi,

I used ChibiOS_16.1.5, and made a first test with the file testhal/STM32/STM32F4xx/DAC/

Here is what I change to make the demo works for STM32F429I_discovery:
- Makefile

1) The board name: include $(CHIBIOS)/os/hal/boards/ST_STM32F429I_DISCOVERY/board.mk
2) The linker script: LDSCRIPT= $(STARTUPLD)/STM32F429xI.ld

- main.c: I removed the following at line 74 because my board don't have an LED attached to this PIN.

Code: Select all

  if ((nz % 1000) == 0) {
    palTogglePad(GPIOD, GPIOD_LED3);
  }


I added a pin configuration for the LED on GPIOG Pin 13.

Code: Select all

palSetPadMode(GPIOG, 13, PAL_MODE_OUTPUT_PUSHPULL);


I also added in the while loop:

Code: Select all

palTogglePad(GPIOG, 13);


That it, and it works for the testhal application. I have attached a picture of the result.

I suggest you to start like this and if it work you can make you own application.

I'm now going to test your code to see if there is a mistake

[tfAteba]

Finally, I made a test with dacPutChannelX function, and for me it worked correctly.

I used a variable in the main function to see the value changed. dacPutChannelX(&DACD1, 0, i);

So you need to check carefully your code and configurations.

Also try to proceed like I told you:
- Configure the testhal/STM32/STM32F4xx/DAC for your board and make it work.
- Modify the testhal for your need.

I hope it will help you!

If you don't find the problem, send your project, I will look after to see if there is some thing wrong.

[HDKLog]

Thanks for your job tfAteba!
I finally found the problem source. In example testhal/STM32/STM32F4xx/DAC/ I find out that reading from Button pin gives you HIGH (1) instead of LOW (0), and "if" condition should be changed from

Code: Select all

if (palReadPad(GPIOC, GPIOC_BUTTON)) {

to

Code: Select all

if (!palReadPad(GPIOC, GPIOC_BUTTON)) {

Best regards, Harry!

[tfAteba]

Hi,
Ok, That[ (!palReadPad(GPIOC, GPIOC_BUTTON))]work for your board, it may be have another configuration.
For me the button is on GPIOA, and I don't have to invert the button state.
To get the button state I used: if (palReadPad(GPIOA, GPIOA_BUTTON))

Here is the code you told ma that it wasn't working properly:

Code: Select all

int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  /*
   * Starting DAC1 driver, setting up the output pin as analog as suggested
   * by the Reference Manual.
   */
  static const DACConfig dac1cfg = {
        .init         = 4047U,
        .datamode     = DAC_DHRM_12BIT_RIGHT
      };

  palSetPadMode(GPIOA, 4, PAL_MODE_INPUT_ANALOG );
  dacStart(&DACD1, &dac1cfg);
  dacPutChannelX(&DACD1, 0, 4000);

  /*
   * Normal main() thread activity, if the button is pressed then the DAC
   * transfer is stopped.
   */
  while (true) {
    chThdSleepMilliseconds(500);
  }
  return 0;
}


What about it? you did not have to use the button here so that was not your problem. Did you finally manage that too?

You are welcome!