1 2 3 Previous Next 30 Replies Latest reply on Mar 30, 2015 9:24 PM by user_14586677

    Did I Fry my Op Amps?

    content.librarian

      I modified the ADC_Differential_Preamplifer project to work with a PSoC 4 BLE Pioneer Kit and with a load cell as shown in the attached schematic. It worked initially, reporting mVolt values between about 70 (IIRC) and 1024, which is the maximum.

         

      I then tried to do something fancy by using the redExcite and yellowExcite pins to reverse the polarity of the excitation voltage between ADC readings, intending to subtract the reversed-polarity measurement from the normal-polarity measurement as a means to effectively double the resolution. After failing to get that to work, however, I returned to the project I saved before trying this change.

         

      The problem is, now the first project doesn't work either. The ADC is showing no change of values when the load on the sensor changes. Checking with two DMMs, I can see that the differential voltage going into pins blueSense and whiteSense still varies consistently versus load as it always has. Measuring the voltage between Out_1 and Out_2, however, which should be exactly the same as is being fed to the ADC, reads only 0 V, occasionally drifting to -0.1 mV. Since the firmware only calculates down to values of 1 mV, it makes sense that mVolts is always equal to previousValue so that nothing is being written to the UART.

         

      Did I fry my opamps? Fortunately, I have another kit or two on their way, but I would like to know if the opamps are, in fact, fried, or whether I have some other error in my project that I am missing. I can share the rest of the project too, if that will help.

         

      Thanks, Don.

        • 1. Re: Did I Fry my Op Amps?
          user_14586677

          Quick way is setup a test project, just set OpAmps as followers,

             

          and input a signal and look at outputs. Signal has to be offset,

             

          so look at using R divider edn article attached.

             

           

             

          Regards, Dana.

          • 2. Re: Did I Fry my Op Amps?
            user_1377889

            Welcome in the forum, Don.

               

            When I read your schematic right, you are supplying the excitation voltages by using two PSoC pins., so the input to your opamps will never exceed the limits. It only may be (but your measures show something different) that you blew your output pins by shorting them.

               

            Can it be the case that you changed your code and deleted some of the initialization required for the components?

               

             

               

            Bob

            • 3. Re: Did I Fry my Op Amps?
              user_14586677

              I have filed a CASE to see if shorting OpAmp output pin to either

                 

              rail would result in failure. Most OAs are protected, or intrinsically due to

                 

              device design, not damaged by shorts. They are, however, damaged

                 

              for sure by excessive voltage.

                 

               

                 

              Regards, Dana.

              • 4. Re: Did I Fry my Op Amps?
                content.librarian

                 Thank you both for the input.

                   

                I did try the suggested opamp-follower test and both opamps did pass a 1kHz squre wave unaltered, individually as well as cascaded into each other, regardless of order.

                   

                I also looked at the digital output pins on a scope while alternately writing them high and low within the firmware. Without inserting any delay code, they were oscillating pretty consistently around 166.5 kHz and their rise time was pretty fast, less than 1 microsecond. Aside from providing interesting insight into the pins' operation, this excercise also confirmed that they are working correctly.

                   

                I will have to revisit the firmware for reasons why my project is not working. When I essentially rebuilt the project from scratch, it seemed unlikely that I reintroduced the same error, but apparently that wasn't unlikely enough.

                   

                Thanks again.

                   

                Don

                • 5. Re: Did I Fry my Op Amps?
                  content.librarian

                  Here's another scope shot showing the rise time.

                     

                  Don

                  • 6. Re: Did I Fry my Op Amps?
                    user_1377889

                    When you post your project we all can have a look at and search for careless mistakes. To do so, use
                    Creator->File->Create Workspace Bundle (minimal)
                    and attach the resulting file.



                    Bob
                     

                    • 7. Re: Did I Fry my Op Amps?
                      content.librarian

                       Thank you for offering to help! I've attached the project zip as you suggested. Let's see if I did it correctly.

                         

                      Don

                      • 8. Re: Did I Fry my Op Amps?
                        user_14586677

                        The matching of the 120K ohm Rs crucial to getting good CMR.

                           

                         

                           

                        Analysis attached.

                           

                         

                           

                        You might look at the routing R with the analog ohmmeter tool to see

                           

                        if the routes for the Rfdbks are ~ equal. Or plan on trimming one Rfdbk

                           

                        wih external pot. 12 bits implies ~ .025%

                           

                         

                           

                        Regards, Dana.

                        • 9. Re: Did I Fry my Op Amps?
                          user_1377889

                          Well, I cannot see any bug in settings or coding...

                             

                          Can it be a wiring error.

                             

                           

                             

                          Bob

                          • 10. Re: Did I Fry my Op Amps?
                            user_14586677

                            The channel value in this API is uint32 (you have it set at 16) -

                               

                             

                               

                            int16 ADC_GetResult16(uint32 chan)

                               

                            Regards, Dana.

                            • 11. Re: Did I Fry my Op Amps?
                              user_78878863

                              I'm not sure your interrupt handling is OK. I think the SAR-MUX-ADC raises the "sdone" output when the scan is finished (the doc says so) and you attach an ISR to it. You didn't do that, but catch only the interrupt generated when the input signal leaves the boundaries. Judging by the code thats not what you intented (because you have different flags for data avilable and window OK.

                                 

                              Also, I think its better to read the ADC result in the ISR and store it instead of waiting for the flag - that avoids potential timing problems (when you read the data too late). The SAR ADC has double buffering to avoid concurrent modifications, but still...

                                 

                              @dana: the conversion uint16->uint32 should be handled by the compiler, there aren't that many channels in the PSoC4.

                              • 12. Re: Did I Fry my Op Amps?
                                user_14586677

                                 I think the SAR-MUX-ADC raises the "sdone" output when the scan is finished (the doc says so) and you attach an ISR to it.

                                   

                                 

                                   

                                sdone – Output
                                This signal goes high for one ADC clock to signal that the ADC has sampled the current input
                                channel and that the input mux may be switched. The input multiplexer selection can be changed
                                after sampling is complete even though the conversion has not yet completed

                                   

                                 

                                   

                                This allows changing mux but does not signify conversion is finished.

                                   

                                 

                                   

                                Also, I think its better to read the ADC result in the ISR and store it instead of waiting for the flag - that avoids potential timing problems (when you read the data too late). The SAR ADC has double buffering to avoid concurrent modifications, but still...

                                   

                                 

                                   

                                I agree, good point, especially in light of a SAR at high sample rates.

                                   

                                 

                                   

                                @dana: the conversion uint16->uint32 should be handled by the compiler, there aren't that many channels in the PSoC4.

                                   

                                 

                                   

                                True, only 8 available, so uint16 is excessive as well. You trust compilers to do your

                                   

                                implied casting, not sure I do.

                                   

                                 

                                   

                                Regards, Dana.

                                • 13. Re: Did I Fry my Op Amps?
                                  user_78878863

                                  I think I should go and get a cup of tea before reading data sheets :(

                                     

                                  EOC is whats signalling the end of conversion... (But I looked at the code again - the ISR Don is using should actually get all interrupts, including End-of-scan)

                                  • 14. Re: Did I Fry my Op Amps?
                                    content.librarian

                                    Thank you all for contributing to the discussion. The firmware points are all helpful and I will try to work them into my code. I'm still not getting the diff amp to work, though, even after building the analog front end only - from scratch - in an entirely new project as well as triple-checing my wiring. While trying to understand hohw the op amps could pass Dana's follower test but still not work as op amps, I realized that the analog pin component connected to the inverting input of the op amp is an element that exists in one case and not the other (the feedback is an internal-only connection in the case of the follower). So maybe it is either P1.1 or P1.4, not the opamps, that fried. I am going to test this idea later today by building the diff amp using the other two op amps in the chip and/or trying a different PSoC 4 BLE module that arrived recently.

                                       

                                     

                                       

                                    I have also checked R1 and R2 and they are not that well-matched, with about a 0.3% difference between them. That is something I will have to address, but I don't think that is the root problem here because I'm not getting any output, common-mode or otherwise.

                                       

                                     

                                       

                                    BTW, I will be attending the PSoC 4 BLE workshop tomorrow in Valley Forge, PA, so if any of you are there, be sure to say hi!

                                    1 2 3 Previous Next