UC3C2: DAC for internal routing to ADC does not exist. ??

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

i am implementing a hardware abstraction layer in C++ for the UC3C2256. I am about to write calibration routines for the DAC and stuff.
Here is my Problem:
The DAC-Output has internal connections to the ADC and analog comparator.

Its defined in the ADCIFA-Interface (Module Configurations) that for the internal routing of the positive ADC input to the internal DAC-Output, i have to select input #8. Quoting the Datasheet: "DAC0_int, Internal output of the DAC0". Fine.

Its also defined in the same section that the negative input selection i have to select "DAC1_int, Internal output of the DAC1"

 

Here it comes:

using AVR32_DACIFB0 is fine. But AVR32_DACIFB1 does not exist. 

 

So:

How am i suposed to connect the DAC1_int to the negative input of the ADC, if there is no DAC1 ???

 

a) is this messed up hardware? i simply cannot connect an internal input to the negative side of the ADC... (which would cripple my design completely, since i rely on this feature)
b) is this a messed up definition file and this DAC exists in hardware but the #defines arent there due to some mistake..

 

I would be glad if anyone can makes things clear on that.

Its just crazy...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you *have* to select the DAC1_int input if you use DAC0_int. ?
Why not select the ADCIFB INNx input to be GNDANA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its the basic operation: the maximum Ref-Voltage allowed is 3.5V at the ADC.

If you want to digitize 0V-5V at the ADC-Input you set one input to VCC/2 which was planned to be done by the internal DAC.
When using a 5V supply that would theoretical give you a conversion range between  2.5V-3.5V=-1V   to   2.5V+3.5V=6V. Which is of course clamped by the supply rails.
Never the less.. thats the only way to digitize 0V-5V with with maximum accuracy.  Everything else neglects the sign bit and only digitizes 0V to Vref, so not the full range.  One NEEDs to use the differential nature of the ADC.

If you use the positive input channels and the negativ you need to be able to set both other inputs to internal sources. The positive inputs can be conneced to DAC0_int while the negative Input can only be connected to DAC1_int.
 

Later on, the measured values will be used as comparator reference, which will also be generated by the DAC. Wohooo... heeeey and here we go again: the analog comparator is also connected to this mysterious DAC1 for the negative input which does or does not exist.  -_-'

 

This is clearly a lack of documentation or an incorrect Header-File. Its better the latter.

Last Edited: Wed. Oct 21, 2015 - 04:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So i looked further into this. I completed the self calibration for the DAC but i still have no luck with the internal signal DAC1_int.
The datasheet for the Uc3C2256 (table 2-1, Configuration Summary)says: 12-Bit DAC: 1, number of channels: 2.

While the bigger processors have also just one DAC, but 4 channels. Aha. So having just one DAC is enough to have the both internal Signals DAC0_int and DAC1_int. So either this table is wrong or.....
However bigger processors have 2 instances of the DAC, namely AVR32_DACIFB0 and AVR32_DACIFB1.  It simply does not fit together. 

How to get a clear statement on this from Atmel? Did they simply forget about the floating internal signals?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The smallest UC3C has only one DACIFB implemented while the medium and large ones has both. I'm not sure what you'd get if you tried to use the DAC1_int signal, but it's not coming from DACIFB1...

Each DACIFB has two Sample&hold output pins, but the internal signal comes directly from the DAC hardware output, ahead of the A/B splitter, so there'll be only one for each DACIFB.

 

If you have based your design around using the DAC1_int signal, I'm afraid you're out of luck.

It's a small comfort, I guess, but you are not the first one to be bitten by missing hardware in the smallest UC3C variants. I got burned by a missing TC1...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not that i made some progress, but i am still at the problem. I tried all inputs for the negative side of the ADC.  The UC3C2xxx has a smaller package and less pins and therefore less connected ADC-Input pins. I figured the smart move would have been to connect DAC0_int somewhere where an negative Input has become free.. but nope... really they are either grounded or just flapping around in the breeze.

 

Unless there is some undocumented control word to connect DAC1_int to DAC0_int the analog module on the UC3C2xxx is definitvely crippled and has unspecified behavior.

 

Damned. 400€ worth PCBs.. thanks a lot.  *tearing up*

 

Any help is still appreciated. Even if its confirmation that those analog peripherials are indeed neglected by Atmel.

The bad thing is that i really need those signals for the analog comparator. the 64-step divided VCC reference is not fine enough. Hardware patches are not possible due to extensive pin-usage.

 

Edit: DukerX wrote while i was updating. Thank you! That the Timers are missing is at least documented in the Datasheet! That there is a difference at the DACs is however NOT documented.
The number of DACs is officially the same in every UC3C.. just the number of Channels varies.  During the PCB design process i did not try to write code without hardware. The datasheet simply suggested that there is a smaller number of DAC-Channels. Since the Channels are made of Sample&Hold stages, i didnt care. This is just evil. There is not a single word about that problem. They should have at least connect the DAC0_int to the negative input somehow.  It would at least restore some functionality.  Its impossible to use the positive ADC input pins as single ended entities.

I bet the Atmel guys reading this while laughing at me and celebrating their evil fraud. Damned this costs real money -.-

Last Edited: Wed. Oct 21, 2015 - 04:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know what inputs your hardware is using, but can you put your measured voltage(s) on the INNx input(s), use DAC0_int on the INPx input(s) and then invert the results ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course the negative inputs work. It is also possible to connect at least one positive and negativ input to the (ground-referenced) Ref-Voltage-Pin. This hardware workaround enables singlended measurements for all inputs.  It requires a new PCB at the end. And it chews 3 pins of the 64-Pin package.  Well.....

You know what realy sucks about it: you cant connect any reference voltage internally to deduce your actual reference voltage. Thus you cant easily measure absolute voltages or go single-ended at full range.

 

What you now need to do is:
1) Set ADC and DAC to the same Ref-Voltage (the only way to do it is the external pin connected to the 3.3V regulator or whatever. Too bad its not possible to use the 0.6V*VDD sice its not connected to the DAC too. -.-' That would free one Pin again.. well at least it would remove the nessecity of that pin for that procedure.)

2) Calibate the DAC so its reasonable accurate. (That alone is a task that even Atmel avoided in the ASF. They just load random (likely 0xffff) values from the flash factory page for a peripherial which is not factory calibrated. Well tested guys! This procedure leaves the DAC more uncalibrated than the default value.)

3) Set the ADC to the 1V-Reference

4) Figure out what DAC-Value you need to saturate the ADC at 1V. (you loose precission here of factor Vref/1V + noise)

5) Calculate the RefVoltage from that (the 3.425V in my case).

 

 

It should look like is:

1) Enable the ADC with VRef=whatever evernal, or 0.6*VDD

2) Measure 1V Bandgap against GND-

3) Deduce the full voltage range. Thats it.

 

You can actually make meaningfull measurements then. If the 1V Reference is accurate at least. Who knows. Maybe the 1V-reference also removed from the chip without any notice and the internal connection is simply left floating. Those things happen, you know..

 

A full scale voltage measurement looks like this:
1) Enable ADC with a Ref-Voltage higher than VDD/2   (VDD*0.6 was actually well chosen! +1 points)

2) Measure the Input against (the known) Vref

3) Vin = Vref*[1.0 +/-  ADC/(1<<11)]. Done.

 

 

[Rant] I mean the whole path using the DAC and stuff introduces such useless error/noise and produces so much overhead.. it drives me crazy from an engineers point of view.. they have impemented two 16:1 analog Mux inside. Instead of using all inputs and providing valuable connections for flexibility (to both DACs, to all references, and not only to GND and some undocumented "TSense"), they virtually crippled the module and restrict it to the most basic functions.
I talked about that with a friend. He says, its basically my fault using the hardware to such extrend. I mean.. how is this even possible?? The Datasheet is from 2012 and absolutely no one until now has complained about UC3C2xxx wrong documentation so that Atmel gives a s..t? No one ever saw the the "Configuration Overview"-Table and was confused by the number of DACs?  I am a AVR-freak, i guess. I mean a real one. Are UC3C only good for Eval-Boards with users who cant even get a UART up and running?

Awwww i am pissed. Its like loosing a girlfriend. First you think to find the perfect match.. and then the little details start to accumulate until some overflow happens and all its left is pure negativity..

Last Edited: Wed. Oct 21, 2015 - 10:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I implemented the above Sequence to measure the internal References and Voltages. Its strage.

In Detail:

1) Set the DAC Reference to VDD
2) Output somewhat around 0.2V

3) Set the ADC Reference to the internal 1V.

4) Measure the DACs 0.25V.

5) Output somewhat around 0.8V

6) Measure the DACs output.

7) Calculate a linear equation to estimate which DAC value will result in 0.98V (close to adc saturation)

7.1) Extrapolate what voltage would the DAC generate if its set to the maximum value -> Thats the DAC Ref-Voltage

8) Output that value via the DAC and confirm that it is indeed 98% of the full adc range. (Yes it is +/- some LSB)

9) change the ADCs reference voltage to the actual reference that shall be measured.

10) Convert the before confirmed 0.98V again and extrapolate what voltage is the maximum voltage. That is then the Reference voltage.

 

The 1V internal Reference is measured to be 1.001V.  Thats basically Noise during step 8.

The VDD is measured to be 5.05V while it is 5.07V. Fine  (Step 7.1).
The 0.6*VDD id measured to be 3.08V while it should be 3.042V. (Step 10) Well ok.

So far, so good. (i mean that, its reasonable accurate, considering that stupid workaround with the DAC)

 

Now: Measure the external Reference pin (PA16, the ground referencd ADCREF0-Pin). Here it displays 3.7V while only 3.42V is actually applied.

Interesting: If i choose the ADCRF0-Pin as reference and convert an ADC-Input the 3.7V would be wrong. Only when using 3.42V within the calculation i can restore the actual applied Input-Voltage. So the measurement is wrong and the 3.42Volts are unchanged internally present as reference.
How can the same code work so nice, but fails with the external reference :-/  There is only one execution path during the measurement. No "If", no Loops.
I am pretty sure, this is caused by some non-linearity in either the ADC or DAC.
Because: the whole Measurement also works when the Ref-Voltage of the DAC is not VDD, but also PA16 (ADCREF0/DACREF). Step 7.1 puts out 3.51V in that case while the whole agorithm gives 3.7V back. Thats weird: if everything would be linear this would only differ by some LSBs...

 

What is obviously strange is that i cant really decide if i should use Pin-function 'C' (DACREF) or 'A' (ADCREF0) while both Peripherials are fed by PA16. But thats what the datasheet says about the calibration procedure of the DAC. Of course i followed those instructions. I would like to know how Atmel solves the problem. (Besides loading 0xffff from the Factory Page..)

Last Edited: Thu. Oct 22, 2015 - 03:30 AM