FT90x ADC & DAC section quite undocumented

[scoprioprise]

Hi Everyone,
I'm developing a custom board based upon FT902 rev B, I'm facing a little problem using ADC's.

In fact, there is little or none documentation on ADC module... but also DAC is missing some important informations

I have a BIG difference between measured (with a calibrated multimeter) and translated from MCU.
I'm using the adc_example3 from the toolchain 2.5.0 installer to get samples.

While 0 is 0 (as channels connected are almost grounded) For instance,measured 0,85V are translated into a 185/1024, which shall mean 0,59V...

In case of DAC , it has a immense delay from setting data to obtaining a real output.

Are there any specific application notes or specific infos?
Everiyhing I found is AN-324, pages 39-41 & BRT_AN_020 pages 42-45 + 223 -224, TN159 where some errata address use of buffer, but nothing else.

[BRT Community]

Hello,

Rev B has actually recently been replaced by Rev C:

PCN BRT 005
BRT AN 019 Migration Guide Moving from FT90x Revision B to FT90x Revision C

The ADC in FT90x Revision C is similar to the ADC in FT90x Revision B with some improvements as
stated below.
Change in FT90x Revision C:

• The FIFO Data Count issue, as stated in TN_159 FT90x Errata Technical Note, section 4.3,
  has been fixed. Counts of 0x7E and 0x7F now appear correctly, and 0xFF indicates the
  FIFO is empty.
• A bit has been added to select the size of the ADC samples: either 10 bits or 8 bits.
• A bit has been added to select the ADC clock speed: 12.5 MHz or 6.25 MHz.
• The internal Op-amp has been removed.

The mm900ev1b can be used to evaluate RevC silicon.

All available information on the ADC can be found at the product page:

https://brtchip.com/ft900/

If you have any other questions you can email our Tech Support at support.emea@brtchip.com.

Best Regards,
BRT Community

[scoprioprise]

Again, that's not enough. I have a reb B, so I will assume it has the problems with FIFO as you menitoned, ADC converter is fixed to 10bit samples, single speed.

So, let's deal with one problem a time:

DAC: single write mode does not write, it writes only after many times the loop has sent data to DAC.
Why? Seems it has to fill the FIFO buffer, but it is against what is said in datasheet (immediately written).  Maybe have I to force writes when starting to make it "responsive"? But how many writes?

ADC Op-amp? which op-amp? Ok, rev C has it removed. but in B what does it imply?

[BRT Community]

Hello,

OK, we have already engaged on email, so let's discuss further and post any resolution here later to help others in the community.

Best Regards,
BRT Community

[scoprioprise]

So, eventually we gained some light ! ADC is now a good boy that does its work!

There is a caveat that was not so easy to understand:

In the examples should be explicit this line of code:

Code Select Expand

ADCDAC->DAC_ADC_CONF |= MASK_DAC_ADC_CONF_ADC_EXT_VREF;
this enables the rail-to-rail reference.

If not enabled, you have a 0.33V -2.97 range which still corresponds to 0x000 - 0x3ff range ( 0d - 1024d ) and leads to a "bathtube" conversion: The center corresponds (1.65V set = 1.65 read), but has an error while going up and down.
Still, in rail-to-rail, you can see the very same phenomenon, but you can see it only near 0.1V or 3.2V, where the error is more explicit.

I STRONGLY suggest to make it explicit in datasheet.

Ok, so let's see the DAC....

[BRT Community]

Hello, great thanks for the feedback. I'll look into getting this added to the documentation.

As for the issue in DAC, I looked into this.

In single shot mode, single conversion works with the following excerpts from DAC Example 1

Code Select Expand

    /* Enable the DAC device... */
    sys_enable(sys_device_dac0);

    /* Make GPIO14 function as DAC0... */
    gpio_function(14, pad_dac0); /* DAC0 */

    /* Set the DAC to single shot mode */
    dac_mode(0, dac_mode_single);

    //dac_start(0);  ------->> this seems to have started the single data conversion

    dac_write(0, 1000);



dac_write() API writes data to the data register and performs start operation.
So a prior dac_start() is not needed.

Best Regards,
BRT Community

[scoprioprise]

You're right, that was the wrong line: commenting that line makes it work like a charm!
In fact, judging from this beaviour, dac_start implyes a continuous mode, thus fit needs filling the FIFO.
Say it's closed, but please make sure documentation will be expnded.
Thankyou so much!!!