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.

TMS320F28376D: offset on Comparators DAC issue

Part Number: TMS320F28376D
Other Parts Discussed in Thread: C2000WARE

Hello everybody , 

please I m using a TMS device   TMS320F28376DPTPT   .  

I m using  all onboard comparators  and only on some of them ( different comparator  number on a different chip ) , I see a issue on DAC : there is  about 300mV offset   . So if I set  DAC ref to zero , comparator will not change state unless I m over 300mV in  input  , and offset is there on all the input range ( so  a 1V threshold for the comparators , I need an input of 1.3V ) .

in attach the connection scheme I use .

I clear  registrer DACHVALs  , CPRIPH stays high  ( comparator low  ) till input  of CMPINxP  reaches 300mV .   I checked  same input voltage with internal ADC  and I can see correctly the 300mV input  so no issue in the board .

as said issue is there on different comparators ( some are working as I am expecting  )  on different devices .

please where am I wrong ?

thank you 

regards

Calro

  • Hi Carlo,

    That is interesting. The CMPSS offset is much less than 300mV. In order to get a better idea of what is going on, i need some details and specifics.

    1. Is this a custom board?

    2. What is the reference option for COMPDAC, VDDA or VDAC? What is the voltage?

    3. Which CMPSS work and which don't?

    4. Do you see the same issue on both high and low comparators?

    5. Is hysteresis enabled or disabled?

    6. What is driving the non-inverting comparator input?

  • Carlo,

    Are you observing the comparator state from the COMPSTS register or through an X-BAR?  If it's X-BAR, make sure that the Mux selection is not an OR'd signal between both comparators (MUXn.1 is OR'd).

    -Tommy

  • Hi Tommy ,

    thank you ,let me double check and I ll be back

    regards

    Carlo

  • Hi everybody,

    Carlo was asking for me.

    Thanks in advance for your help. I Always solved when somebody answer on this forum, so I really appreciate your help.

    Attached there is a readMe file where I try to explain what I was doing and how I configured the analog comparator. I hope to have been clear.

    I could attach the project, but I have to ask permission by my boss, so until monday I can not.

    Thank you again for your help,

    Regards,

    Andrea Marcianesi

    ReadMe.docx

  • Hi Andrea,

    Thanks for providing the extra details. Providing the project is not necessary as the cmpss configuration code should be enough. Looking through your configuration code, a few questions come to mind.

    1. You have the async path enabled to the xbar but you are also configuring the filter. So which path are you using to check the trip, compsts register or gpio?

    2. Do you have a delay in your code after you call "CMPSS_Init2"? The comparators have a power-up time and this requirement needs to be satisfied for proper operation.

    3. Do you see the same issue if you switch to using the COMPL?

    Also, it is usually a good idea to max out the other compdac in a CMPSS if you are not using it. In your case, you aren't using COMPL so you should write 0xFFF to DACLVALS so you don't get any disturbance trips because the non-inverting input goes to both comparators.

  • Hi Frank,
    in the following there are my answer and questions.

    1) You have the async path enabled to the xbar but you are also configuring the filter. So which path are you using to check the trip, compsts register or gpio?
    I’m Using the GPIO: using these setting
    gpst_CmpssRegs[e_ECmpss]->COMPCTL.bit.CTRIPHSEL = 0
    gpst_CmpssRegs[e_ECmpss]->COMPCTL.bit.CTRIPOUTHSEL = 0

    no matter if the filter is configured or not, I select the Async Output of the comparator.

    Then with these settings I output the Comparator to the GPIO

    OutputXbarRegs.OUTPUT1MUX0TO15CFG.bit.MUX0 = 0; OutputXbarRegs.OUTPUT1MUXENABLE.bit.MUX0 = 1;
    OutputXbarRegs.OUTPUT1MUX0TO15CFG.bit.MUX1 = 0;

    Clearly for Cmpss1 submodule. Am I wrong?
    2) Do you have a delay in your code after you call "CMPSS_Init2"? The comparators have a power-up time and this requirement needs to be satisfied for proper operation.
    I configured 6 cmpss, using the following 6 functions.
    CMPSS_Init2 (e_CMPSS_1, 0.0, 0.0, e_CMP_PWM_1_SYNC);
    CMPSS_Init2 (e_CMPSS_2, 0.0, 0.0, e_CMP_PWM_2_SYNC);
    CMPSS_Init2 (e_CMPSS_3, 0.0, 0.0, e_CMP_PWM_3_SYNC);
    CMPSS_Init2 (e_CMPSS_4, 0.0, 0.0, e_CMP_PWM_4_SYNC);
    CMPSS_Init2 (e_CMPSS_5, 0.0, 0.0, e_CMP_PWM_5_SYNC);
    CMPSS_Init2 (e_CMPSS_6, 0.0, 0.0, e_CMP_PWM_6_SYNC);

    Inside each of them there is at the end the enable of the comparator gpst_CmpssRegs[e_ECmpss]->COMPCTL.bit.COMPDACE= 1

    After these functions I configured the epwms and other stuffs, but, as the analog comparator is already enable, is already working. So what delay I should insert and where ? I should put some NOP istructions between the configuration and the gpst_CmpssRegs[e_ECmpss]->COMPCTL.bit.COMPDACE= 1 instruction?


    3) Do you see the same issue if you switch to using the COMPL?
    Yes, I configure the COMPL to output using the following instructions,

    OutputXbarRegs.OUTPUT1MUX0TO15CFG.bit.MUX1= 0;
    OutputXbarRegs.OUTPUT1MUXENABLE.bit.MUX1= 1;

    Instead of
    OutputXbarRegs.OUTPUT1MUX0TO15CFG.bit.MUX0= 0;
    OutputXbarRegs.OUTPUT1MUXENABLE.bit.MUX0= 1;

    And the behavior is exactly the same: the gpio58 goes high when the analog input voltage goes below 330mv, when the Cmpss1Regs.DACLVALS.bit.DACVAL=0. There are 2 different DACs for COMPL and COMPH?

    4) Also, it is usually a good idea to max out the other compdac in a CMPSS if you are not using it. In your case, you aren't using COMPL so you should write 0xFFF to DACLVALS so you don't get any disturbance trips because the non-inverting input goes to both comparators.

    I tried to follow your advice, writing 0xFFF to DACLVALS, but nothing change.
    In Figure 12-1. CMPSS Module Block Diagram of the manual, there is no way for the COMPH to influence the COMPL output and vice versa. Am I wrong? How could be possible that a disturbance in the non-inverting input could influence the output of the COMPH?

    I also send the project to Carlo, is such a way to be sure to not have any wrong configuration which clearly I don't see. If you could look also to that project (is quite short) it would be of great help.

    Thankyou very much,
    Andrea Marcianesi.
  • Andrea,

    1. Ok. Just wanted to make sure the async path was your intended output path and not the filter. The output xbar settings for your configuration is fine.

    2. When the comparator is enabled with "COMPDACE=1", the bandgap and comparator circuitry needs some time to fully power on. This is specified in the data manual as the comparator power up time, 10us. In practice, the comparator powers on much quickly than that but since what you are seeing is unexpected behavior, we need to cover all unlikely avenues. You can use the "DELAY_US" function. You don't need to place it after each function call to "CMPSS_Init2", you can call it once after the last comparator is configured.

    3. Yes, there are 2 different COMPDACs per CMPSS module but they share some components.

    4. Ok. In general, you still have to follow that advice even after your issue is resolved because as i mentioned in the previous point, the COMPDACs share some components so a trip on COMPH or COMPL temporarily disturbs the other. This is specified in the data manual as "CMPSS DAC output disturbance/disturbance time".

    Right now, I'm leaning towards a bad part but i think that is a bit premature at this point so we need to rule out everything else. I need your clarification on a few questions.

    5. Is this a custom board?

    6. How are you supplying the non-inverting input to the 6 CMPSS? Is this one voltage source going to all 6 or does each CMPSS have it's own?

    7. The comparator is a very sensitive device so finding the trip point when the 2 inputs are very close together is not a reliable test. Can you try using the filter path instead and also for sanity checking, you can look at the COMPSTS register to make sure it gets set when the GPIO trips?

  • 1. OK
    2. I added the Delay_us(10) istruction, but nothing change.
    3.ok
    4.Yes now I found it. I didn't understand wasfor cross comparator disturbance, any way 100LSB are +-80mv, not 300mv. Anyway, your advice is good, I will follow from now on.

    I would like to remember to you that I face the same problem with an other Board, which has a different DSP. In that case cmpss1 and 3 were affected with different macrooffset.

    5. Yes
    6. each CMPSS has it's own. All configured with similar, but separated hardware filter (RC).
    7. checking the COMPSTS register is quite difficult, as I set the DAC value in the epwm1 Interrupt service routine, but, the epwm1 output is configured to have a maximum duty which can be shortened by the comparator trip coming in the pwm trough a DC event 2. When I put the dac value to 0, I saw the maximum pwm frequency in the output, if the analog non inverting input is lower than 300mv, meaning that the pwm is never shortned by the comp. Over 300mv, the pwm is 0, meaning that as soon as the dacval is updated by pwm1, the comp trip and cut off the pwm. This is an other proof that the dac of the comparator seems to have a dc offset of 300mv.

    I really hope that you could take a look to my code that Carlo should give you.

    Regards,
    Andrea Marcianesi.
  • Andrea,

    I received the project from Carlo. From a quick glance, nothing is really standing out as the issue. At this point, it is not clear if the problem is software or hardware. To help rule out a software or hardware problem, i have attached a code i want you to run. It's a sort of inside-out of what you are doing but it's equivalent. Instead of the non-inverting input being swept for a trip, the compdac is swept instead.

    The code works by setting the buffered dac at midcode and sweeping comph and compl for a trip. You will need to to connect the output of the buffered dac externally to the non-inverting input of the respective cmpss. If this is not possible on your board, you can use an external voltage source instead and set that to 1.65v but i would prefer if you used the buffered dac for this test.

    Place the attached code in cmpss_asynch example code from C2000Ware.

    Run it on all 6 cmpss and report back what you find for comph_untrip_code, comph_trip_code, compl_untrip_code and compl_trip_code for each cmpss.

    /cfs-file/__key/communityserver-discussions-components-files/171/cmpss_5F00_trip_5F00_cpu01.c

  • Hi Frank,

    I think I understand what you meant to do.

    I'll give to your code a try, even if I can't attach the dac output to the input pins of the non inverting comp, so I think I will use an external voltage, but I think I can give you the value of  comph_untrip_code, comph_trip_code, compl_untrip_code and compl_trip_code for each cmpss.

    I just need some time as today is almost finished, tomorrow I am in Holiday and Friday is Public Holiday, so until monday I will not work on this topic.

    I'll let you know when I'll finish.

    Thank you Frank

    Andrea.

  • Good evening Frank,

    I analyzed the code you gave me and it helped a lot to find the issue, which was related to my test equipment. So, at the end, the DAC and the comparator are working fine.

    This actually close my issue, but before saying hello to you I would like to ask you what do you suggest, the asynchronous output or the digital filter output like the one you use?

    Thank you very much for your help and advices,

    Best regards,

    Andrea Marcianesi.

  • Andrea,

    Glad to hear the issue is resolved!

    Asynchronous or filter output depends on your application. If you want the fastest speed out of the cmpss, you will need to use asynchronous output. However, if you use asynchronous, the likelihood of false trips is very high if the two inputs levels are very close together and your system is noisy. On the other hand, if you want a stable system, you should use the filter output. However, that also has a downside because using the filter delays your trip.

    So in the end, its a trade-off you will need to make. I think in most cases, filter will be adequate as you can play around with the window and threshold settings to find the maximum acceptable delay for your application.