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.

F28069 Piccolo DAC comparator glitching

Other Parts Discussed in Thread: CONTROLSUITE, TMS320F28062

I am having trouble with gliching on the comparator and DAC. I am trying to generate a ramp for use in a peak mode current controller.

I am using a F28069 Control card in an experimenters kit.

I started with the 'TripComp' sample software from the 28069 Control stick examples.

I am comparing an analog input on A2 with the internal DAC. My analog input is created by using a potentiometer supplied by the experimenter kit 3V3 and GND.

I have added a ramp generator to the DAC configuration, and tweaked the event/TZ logic to turn EPWM1A off when the ramp cross the input ADC value.

I start the ramp with :-

Comp1Regs.RAMPDECVAL_SHDW = 64;

Comp1Regs.RAMPMAXREF_SHDW = 44800

And vary the potentiometer.

It works, but when it hits a glitch, the glitches are large - upto 40% DC @ 800KHz.

Has anybody else had trouble with this chip or other Piccolo chips ?

Any ideas on what to try ?

PS The problem also appears when using the CLA to update the DAC - so not a ramp generator problem, I think.

PPS Although there is nothing in the errata about this problem, the control card has a TMX chip on it.

  • Hi Gil,

    Has anybody else had trouble with this chip or other Piccolo chips ?

    NO, I used the same sample code 6months back, the DAC was fully functional with no such glitches.

    Any ideas on what to try ?

    I hope you've the latest controlSuite.

    Although there is nothing in the errata about this problem, the control card has a TMX chip on it.

    TMX is nothing but a development part number and is no different (might slightly vary) than TMS.

    Regards,

    Gautam

  • Yes, I have the latest version of ControlSuite.

    I have reproduced the problem on 2 different F28069 cards and 1 F28035 cards. So I do not think the problem is specific to one card.

    The problem maybe related to updating the DAC quickly - either a large step, producing some overshoot, or a lot of quick steps (a ramp - either internal, or CPU/CLA generated).

    Thanks.

  • Hi Gil,

    I'm sure you might've have already referred this doc:

    ftp://ftp.ti.com/pub/dml/DMLrequest/Christy_FTP-10-30-12/controlSUITE/development_kits/F28069%20controlSTICK/Comparator%20-%20TripComp/~Docs/TripComp.pdf

    There isn't much in the doc, but what you can do is refer the technical reference manual for F28069 and try tweaking the code.

    Regards,

    Gautam

  • Yes, I installed the latest version of the ControlSuite.

    Yes, I read the technical reference manual.

    I was hoping TI might make a comment!

  • Some further info:

    Using F28035 control card in the experimenters kit, again with a potentiometer as the comparator2 input (ADC A4), I have reproduced the problem with the Biricha code sample (sprabe7).

    The problem appears to be worse around the mid-point of the ADC range (e.g. 1.6V). It also seems to start with a short glitch (similar to the 3 TBCLK glitch which is documented). As the input voltage deceases slightly, the duty cycle gets longer, and the 3 TBLCK glitch turns into a 20 TBCLK glitch.

    My test results appear consistent across several chips and different test setups (including an operating converter).

    Is this TI's expected performance ?

  • Gil,

    Can you try to drive in a buffered signal rather than using a potentiometer?  The hysteresis feedback of the comparator looks like a 100kOhm series load to the input so you may end up with a varying voltage divider at the input depending on the potentiometer sizing.

    Are you able to scope the inputs to see if there's any noise on the input pin that correlates with the output glitches?

    -Tommy

  • Hi Tommy

    Thanks for your input.

    The potentiometer we were using was 1K - at about its mid point. So quite low.

    I also tried turning off the hysteresis (AdcRegs.COMPHYSTCTL.bit.COMP1_HYST_DISABLE = 1;). But this made no difference (the voltage at which the glitch happens moves slightly - so had to trim pot).

    We don't have any suitable buffers in stock - but I used our real converter which has an op amp driving the ADC input via a 33R - same problem. Equally, I used a signal generator, with 50R impedance, to drive my experimenters kit. All showed glitching.

    No evidence of noise on the input. Possibly some noise on ADC supply when the PWM o/p switches. Maybe the '3TBCLK' glitch, causes supply noise/instability. Control card supply issue??

    Unfortunately I have run out of time to investigate further. Maybe in the New Year.

    Gil

  • I wonder if there has been any more discussion on this apparent ADC problem. I have what may be a similar scenario:

     

    I'm using a TMS320F28062, sampling ADCINB6 continuously with minimum sample window. I have what I believe to be a clean voltage ramp into the ADC pin. When I plot consecutive ADC samples, I can see the ramp. But it seems that all ADC samples that should have been in the (decimal) range of 3008 to 3019 result in a converted value of 3019.

    My first thought was that somehow comparator hystersis was influencing this ADC input. But the comparator clocks are disabled, the hysteresis is disabled, etc. (all done based on things I've read in this forum.). None of this seems to have helped the apparent deadzone of ADC samples.

    I've attached a JPG snapshot of a time-series plot of the samples. While I cannot fully rule out PCB influence, the lack of noise in the "stuck" region reeks of a digital (i.e. internal) issue. Wonder if anyone has seen similar issues in their applications...

     

  • Hi Robert,

      Are you still having troubles or did you solve your issue?  Have you tried switching to an ADC channel that does not have COMP or AIO functionality to narrow down the cause?  Incidentally are you using TI or custom hardware?

    Regards,

    Joe

  • Hi Joe,

    I apologize to you and any who may have had any interest in the problem I had encountered. I found my issue and neglected to share it in a timely manner on this forum.

    As it turns out, my issue was a fairly simple one (almost all are simple once you know how to fix them!). In this case, I was clocking the ADC above its specified 45MHz maximum. The CPU was being clocked at 80MHz (in spec), but the ADC pre-scalar was erroneously set to divide by 1 instead of 2, yielding an 80MHz ADC clock (NOT in spec).

    Sadly, I classify this as a typo, having always intended to divide by 2.

    Thanks for your follow up question. And sorry again for not replying sooner.

     

  • Robert,

      No worries, I'm just glad you got it working!  Also thanks for sharing your experience, I'm sure many others will benefit from your debug.

    Regards,

    Joe