Possible bug on kinetis driver fsl_dac_h/c SDK 2.7.0 ???

Showing results for 
Search instead for 
Did you mean: 

Possible bug on kinetis driver fsl_dac_h/c SDK 2.7.0 ???

Contributor I

In my app i use a driver set for MK66FN2M0xxx18 SDK Version 2.7.0, Manifest V. 3.6.0 on MCUXpresso IDE v11.1.1_3241.

Using the DAC peripheral configuration tool, if you enable buffer and you fill the firsts n-values, the tool initialize the element .upperLimit of dac_buffer_config_t descriptor, equal to NUMBER-OF-VALUES filled into dac-buffer and write this into DAC Control Register 2 (field DACBFUP) as the UpperLimit of read-pointer of buffer, but the true upperLimit is this number reduced by ONE!

May be?

If you fill all the 16-values in buffer (peripheral configuration tool) and you compile, the DAC outputting only the first value (0-index) because the DAC_SetBufferConfig(..) library-method, when set the true DACx_C2[DACBFUP], is write this field with 16U masked by 0x0F, rather 0x00(!), limiting possible out-values at the first (0-index) only.

If i fix DACx_c2[DACBFUP] post initialization, the DAC run properly… otherwise not.

Labels (1)
0 Kudos
1 Reply

NXP TechSupport
NXP TechSupport

Hi Antonio Del Magro 

  Thank you for your interest in the NXP kinetis product, I would like to provide service for you.

  Could you please also provide some screenshot about your test result? It will make the question more clear.

   Then I will help you to check more details about it.

    Do you test it based on the FRDM-K66 board? Do you check the SDK directly project, whether it will have issues or not? Eg SDK_2.7.0_FRDM-K66F\boards\frdmk66f\driver_examples\dac

    Please give me more information about it.

Best Regards,



- If this post answers your question, please click the "Mark Correct" button. Thank you!


- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

0 Kudos