Nucleo STM32F334R8 DAC

[heap]

Posted on October 23, 2014 at 14:05

Hello community,

Actually I evaluating DAC on NucF334R8. 

DAC1

_

Channel1

 seems to work but I am not able getting 

DAC2

_

Cannel1

 (Pin 

PA6

) to work. I created the C Framework with STMCubeMX 4.4.0 - both channels with equal settings.[snip main.c]...  /* USER CODE BEGIN 2 */ HAL_TIM_Base_Start(&htim6);

HAL

_

DAC

_Start(&

hdac1

, DAC1_CHANNEL_1);

HAL

_TIM_Base_Start(&

htim7

);

HAL

_

DAC

_Start(&

hdac2

, 

DAC1

_CHANNEL_1); ..../* 

TIM6

 

init

 function */void 

MX

_

TIM6

_

Init

(void){  TIM_

MasterConfigTypeDef

 sMasterConfig;  htim6.Instance = 

TIM6

;  htim6.

Init

.

Prescaler

 = 0; htim6.

Init

.

ClockDivision

 = 0;  htim6.

Init

.

CounterMode

 = TIM_

COUNTERMODE

_UP;  htim6.

Init

.Period = 

0x1

;  

HAL

_TIM_Base_

Init

(&htim6);  sMasterConfig.

MasterOutputTrigger

 = TIM_

TRGO

_UPDATE;  sMasterConfig.

MasterSlaveMode

 = TIM_

MASTERSLAVEMODE

_DISABLE;  

HAL

_

TIMEx

_

MasterConfigSynchronization

(&htim6, &sMasterConfig);}/* 

TIM7

 

init

 function */void 

MX

_

TIM7

_

Init

(void){  TIM_

MasterConfigTypeDef

 sMasterConfig;  

htim7

.Instance = 

TIM7

;  

htim7

.

Init

.Prescore = 0;  

htim7

.

Init

.

CounterMode

 = TIM_

COUNTERMODE

_UP;

htim7

.

Init

.

ClockDivision

 = 0;  

htim7

.

Init

.Period = 

0x1

;  

HAL

_TIM_Base_

Init

(&

htim7

);  sMasterConfig.

MasterOutputTrigger

 = TIM_

TRGO

_UPDATE;  sMasterConfig.

MasterSlaveMode

 = TIM_

MASTERSLAVEMODE

_DISABLE;  

HAL

_

TIMEx

_MasterConfigSynchronization(&

htim7

, &sMasterConfig);} ... [snap]

DAC1

 - yellow; 

DAC2

 - blueNow I am using Keil Lite IDE but with mbed I got the same results....Does anybody have an idea what is wrong ?regards

[frankmeyer9]

Posted on October 24, 2014 at 11:04

Looking at the ref.manual and your code, there is another significant difference of the DAC peripheral, compared to other/older MCUs.

The DAC1 of the F334 has two channels, which could be operated independently or simultaneously. The DAC2 has only one channel, i.e. the old-fashioned ST DAC peripheral. For that reason, the peripheral registers are necessarily different. In your place, I would try to setup another project, utilizing ch1 and ch2 of DAC1, instead of DAC1 and DAC2. I still believe CubeMX might expose some bug here ...

[heap]

Posted on November 03, 2014 at 08:33

Hello,

I took a look in the source of HAL driver ''stm32f3xx_hal_dac.c'' On line 64 is written ''Wave generation is NOT available in DAC2.''But in ref.manual RM0364 it should be possible to use DAC2/Channel1 for generating triangle wave. I am confused. Is this a constraint of the HAL driver or of the STM32F334R8 ?regardsps. to use DAC1/Channel1 I have to rework the nucleo, cause LED1 share the same PIN.

[Amel NASRI]

Posted on November 20, 2014 at 15:17

Hi Faichtner.a,

Thanks for highlighting this issue. Please note that its root cause is a missed information in the reerence manual RM0364. In fact, only DAC1 offers the wave (Triangular or Noise) generation feature. This is not possible using DAC2.It will be fixed in next release of RM0364 & RM0316.CubeMX has to be updated accordingly.For ''fm'' who asked about the STM32F3 standard peripheral library supporting STM32F334, I say it is available in the web on

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF258144

 (version 1.1.0).Thanks for your contributions.-Mayla-

[frankmeyer9]

Posted on November 20, 2014 at 15:37

For ''fm'' who asked about the STM32F3 standard peripheral library supporting STM32F334, I say it is available in the web on

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF258144

 (version 1.1.0). Great to hear you do not abandon the standard peripheral libs. While I do not own a F334 board at the moment, I noticed the lib was missing. IMHO the SPL has much more appeal to commercial users, dealing in a very price-sensitive market. Apart from the immature state of the Cube software, it is dissed for fat code and undesired performance loss in unnecessary thick interrupt code HAL layers. Where a few cents count, PMs often tend to sacrifice development time for the next smaller Flash - as I experienced myself often enough ...