This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC53202: issue in updated fix voltage on DAC using hex values.

Part Number: DAC53202
Other Parts Discussed in Thread: DAC63204

sorry it took some time to jump back onto DAC project again. as mentioned earlier I'm using below code. but it seems that DAC value is not updated.

I'm hex values to update DAC voltage. eg. ( 0x708 for 7.44v, 0x604 for 8.3v etc)

here is my code ;;;;;;;

// Function to configure OUT0 on DAC53202RTER
void configure_out0(void) {
ret_code_t err_code;

// Configure DAC53202RTER for OUT0
uint8_t common_config_data[2] = {0x1F, 0x03FF}; // Set OUT0 in voltage output mode
uint8_t gain_config_data[2] = {0x15, 0x0400}; // Set gain for OUT0 (use VDD as the reference)

// Send I2C start condition and write COMMON-CONFIG register data
err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, common_config_data, sizeof(common_config_data), false);
if (err_code != NRF_SUCCESS)
{
NRF_LOG_ERROR("I2C transaction failed with error code: %d", err_code)
NRF_LOG_FLUSH();
}

// Send I2C start condition and write DAC-0-VOUT-CMP-CONFIG register data
err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, gain_config_data, sizeof(gain_config_data), false);
if (err_code != NRF_SUCCESS)
{
NRF_LOG_ERROR("I2C transaction failed with error code: %d", err_code)
NRF_LOG_FLUSH();
}
// Optionally, add a delay to allow the DAC to settle
nrf_delay_ms(10);
}

// Function to update the OUT0 output value
void update_out0(uint16_t output_value) //output_value are hex codes (ex. 0x708 for 7.44v & 0x00 for 16v)

{
ret_code_t err_code;

// Update the OUT0 output using the DAC-0-DATA register
uint8_t data_register_data[3] = {0x1C, (output_value >> 8) & 0xFF, output_value & 0xFF};

// Send I2C start condition and write DAC-0-DATA register data
err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, data_register_data, sizeof(data_register_data), false);
if (err_code != NRF_SUCCESS)
{
NRF_LOG_ERROR("I2C transaction failed with error code: %d", err_code)
NRF_LOG_FLUSH();
}
// Optionally, add a delay to allow the DAC to settle
nrf_delay_ms(10);
}

  • Hi Vishal, 

    The max supply for this device is 5.5V. Are you supplying more to that to the VDD or VREF pin? You cannot get 7.44V or 8.3V with this device. 

    Best,

    Katlynne Jones

  • Hi Jones,

    I'm so sorry to confuse you.

    yes, I'm operating DAC on normal voltage 3.3v from MCU.

    I'm expecting the voltage on the BOOST controller not on DAC, sorry for that.

    I checked the dac with SMARTGUI software, for corresponding hex it is giving output properly. eg. for hex 0x708 the output is 2.138v.

    The only question is was my piece of software is correct, I'm missing anything to enable..?

    Thanks,

    vishal

  • Hi Vishal, 

    Got it, thanks for clarifying. 

    When you write to register 0x1C, the data should be left shifted to 16-bits first. I assume 0x708 is just the 10-bit data, so you would need to shift the data left by 6 to 0xB100. The 10-bit DAC53202 will accept the most significant 10-bits of data in the register (bits 15:6)

    Can you try this? 

    Best,

    Katlynne

  • sure..! I will update you once tested.

  • Hi,

    I tried making the changes it did not work. seems to be DAC-OUT0 is not in output mode. 

    I2C communication was fare enough. it's working fine. 

    pls check this lines :

    uint8_t common_config_data[2] = {0x1F, 0x03FF}; // Set OUT0 in voltage output mode
    uint8_t gain_config_data[2] = {0x15, 0x0000}; // Set gain for OUT0

    // Send I2C start condition and write COMMON-CONFIG register data
    err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, common_config_data, sizeof(common_config_data), false);

    // Send I2C start condition and write DAC-0-VOUT-CMP-CONFIG register data
    err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, gain_config_data, sizeof(gain_config_data), false);

    void update_out0(uint16_t output_value)     //output_value are hex codes

    {
    ret_code_t err_code;

    // Left-shift the 10-bit data by 6 bits
    uint16_t shifted_data = output_value << 6;

    // Prepare data array for the DAC-0-DATA register
    uint8_t data_register_data[3] = {0x1C, (shifted_data >> 8) & 0xFF, shifted_data & 0xFF};

    // Send I2C start condition and write DAC-0-DATA register data
    err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, data_register_data, sizeof(data_register_data), false);

  • Hi Vishal, 

    Can you share a oscilloscope screenshot of one of the I2C writes so I can check? 

    I notice here you have the gain config register set to 0 now. This will select the external reference as the reference. Do you have anything connected to the VREF pin? 

    uint8_t gain_config_data[2] = {0x15, 0x0000}; // Set gain for OUT0

    Best,

    Katlynne Jones

  • Hi Jones, 

    I have misinterpreted few things, now I found couple of issues and rectified them. 

    the changes are as following: 

    I'm using DAC53202RTER  not DAC63204.

    My I2C communication address is 0x48 (GND)

    The addresses and values which I Traced using SMART-DAC-GUI

    1. common config ---> addr 0x1F,   data 0x0FF9

    2. DAC0-Vout-cmp-config ----> addr 0x03,  data 0x0400  (VDD as ref)  also this did not play any role in GUI, pls let me know I should be using this in my software.

    3. DAC0-DATA ---->  addr  0x19,  data 0x7080  (any hex values)

    Thankyou for your inputs through out the process, these are my final findings. So, pls guide me on this. These are the values traced on SMART-GUI with DAC63204.

    But on actual formfactor board it's DAC53202RTER. 

    Thanks,

    vishal.

  • Hi Vishal, 

    The external reference pin is pulled up to VDD on the EVM, so if you left  DAC0-Vout-cmp-config as 0x0000 then the device would be using the external reference connected to VDD. Do you have the external reference connected to anything on your board? If not, you should set  DAC0-Vout-cmp-config to 0x0400 to select VDD as the reference. 

    Channel 0 on the DAC53202 has different register locations than channel 0 on the DAC63204, so make sure you are using the correct addresses/data: 

    1. common config ---> addr 0x1F,   data 0x03FF

    2. DAC0-Vout-cmp-config ----> addr 0x15,  data 0x0400  (VDD as ref)  also this did not play any role in GUI, pls let me know I should be using this in my software.

    3. DAC0-DATA ---->  addr  0x1C,  data 0x7080  (any hex values)

    Also make sure you are measuring the correct pin on the DAC53202. Channel 0 are on pins 1,2. OUT0 and FB0 should be shorted together. 

    Best,

    Katlynne Jones

  • Hi Jones,

    Thankyou for the reply, yes I have shorted OUT0 & FB0...!

    so for DAC63204 are my addresses correct..?  (0x1F, 0x0FF9) (0x03, 0x0400) & (0x19, hex values) 

    and DAC53202 the addresses what you mentioned. 

    I'm so confused because I have tried all the combinations. now I'm trying to trace my data by PICO.

    pls, provide little clarification for Both DAC63204 & DAC53202 with addresses and values

    Thanks,

    vishal 

  • Hi Vishal, 

    Please share a schematic of your setup and a oscilloscope screenshot of one of your writes to the DAC so I can double check. 

    DAC63204: (0x1F, 0x0FF9) (0x03, 0x0400) & (0x19, hex values)

    Output pins 11, 12:

    You can also wire up your controller to the DAC63204 EVM and try writing the above values to check if you can get an output. This could help isolate if the issue is with your code or the DAC53202 board you are using.  

     

    DAC53202:  (0x1F, 0x03FF) (0x15, 0x0400) & (0x1C, hex values)

    Output pins 1, 2:

    Best,

    Katlynne Jones 

  • Hi Jones,

    Thankyou for your inputs, 

    I was able to configure_out0 and update values. 

    on DAC53202RTER  i have tested with "(0x1F, 0x03FF) (0x15, 0x0400) & (0x1C, hex values)" which didn't work. 

    But for both  DAC63204 & DAC53202RTER   "(0x1F, 0x0FF9) (0x03, 0x0400) & (0x19, hex values)"  worked perfectly.

    Still there was little issue where I'm trying to update the value (0x19, 0x708 (hex-codes)) 

    any specific format to be followed to update hex values on 0x19 (out0 pin)...???

    I'm using the following :

    void update_out0(uint16_t output_value) //output_value are hex codes

    {

    // Extract the 12 least significant bits of the 16-bit value
    uint16_t data_value = output_value & 0x0FFF;

    // Prepare data array for the DAC-0-DATA register
    uint8_t data_register_data[3] = {0x19,  (data_value >> 8), (data_value & 0xFF)};

    Thanks,

    vishal.

  • Hi Vishal, 

    If the below is correct then you are looking at the wrong output pins and are actually looking and channel 1 on the DAC53202. That is fine for now as you are just trying to get the part up and running, but can you please share your schematic so I can verify?

    But for both  DAC63204 & DAC53202RTER   "(0x1F, 0x0FF9) (0x03, 0x0400) & (0x19, hex values)"  worked perfectly.

    Can you elaborate what issue you are seeing with updating the output values in register 0x19? You should be extracting the most 12 significant bits of the 16-bit value, not the least significant 16-bits. For example 16-bit 0x8000 is equivalent to 12-bit 0x800. If you are taking the 12 LSBs, then you are left with data 0x000 which give you 0V output. I'm guessing that is your issue. If not, please elaborate on the behavior you are seeing. 

    Best,

    Katlynne Jones

  • Hi Jones,

    Yes I should re-verify that part. But for now both the EVM's are up and running.

    "You should be extracting the most 12 significant bits of the 16-bit value, not the least significant 16-bits. For example 16-bit 0x8000 is equivalent to 12-bit 0x800. If you are taking the 12 LSBs, then you are left with data 0x000 which give you 0V output. I'm guessing that is your issue. If not, please elaborate on the behavior you are seeing"

    This lines will solve most of the issue, It's a small calibration issues. I can re-check the logic considering above guidelines.

    Thanks,

    vishal.

  • Hi Vishal, 

    Yes, please recheck and let me know if you face more issues. 

    Best,

    Katlynne Jones

  • Hi Jones,

    I think 2byte is not transmitting properly, I tried to debug/read the updated values but able to read only 1st byte. Can you trace any issue in following logic.

    "

    void update_out0(uint16_t output_value) //output_value are hex codes

    {
    ret_code_t err_code;
    uint8_t reg_address = 0x19;

    // Extract the most significant 12 bits of the 16-bit value
    uint16_t data_value = (output_value >> 4) & 0x0FFF;
    NRF_LOG_INFO("DATA: %x", data_value)
    NRF_LOG_FLUSH();

    // Prepare data array for the DAC-0-DATA register (big-endian format)
    uint8_t data_register_data[3] = {
    0x19, // DAC-0-DATA register address
    (data_value >> 8) // MSB
    (data_value & 0xFF) // LSB

    };

    // Send I2C start condition and write DAC-0-DATA register data
    err_code = nrf_drv_twi_tx(&m_twi, DAC53202RTER_I2C_ADDRESS, data_register_data, sizeof(data_register_data), false);
    if (err_code != NRF_SUCCESS)
    {
    NRF_LOG_ERROR("I2C transaction failed with error code: %d", err_code);
    NRF_LOG_FLUSH();
    }
    while (m_xfer_done == false);
    nrf_delay_ms(10);   "

    Thanks,

    vishal.

  • Hi Vishal, 

    The data should be 16-bit aligned in the register. 

    When you write to register 0x1C, the data should be left shifted to 16-bits first. I assume 0x708 is just the 10-bit data, so you would need to shift the data left by 6 to 0xB100. The 10-bit DAC53202 will accept the most significant 10-bits of data in the register (bits 15:6)

    Here, you are shifting it to 12-bits. 

    uint16_t data_value = (output_value >> 4) & 0x0FFF;

    So your voltage output is likely divided by 16. You can just leave the data in 16-biit format. The DAC63204 will ignore the 4 LSBs, the DAC53202 will ignore the 6 LSBs automatically. We do this to make it simple to write to all resolution variants of these devices with out having to re-manipulated the data. 

    I would just delete this line of code completely and leave the data as 16-bit. 

    uint16_t data_value = (output_value >> 4) & 0x0FFF;

    Best,

    Katlynne Jones