Did I Fry my Op Amps?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

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.

0 Likes
30 Replies
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 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

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Here's another scope shot showing the rise time.

   

Don

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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
 

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

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

   

Don

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

   

Can it be a wiring error.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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

   

 

   

int16 ADC_GetResult16(uint32 chan)

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

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.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

 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.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

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)

0 Likes
Anonymous
Not applicable

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!

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Here is the result fro, Tech support on OpAmp current limiting -

   

 

   

    

   

          

   

Hello Dana Knight,

   

 

   

I reproduced the issue here. When the opamp output is short circuited, it will provide very high load current

   

much greater than the datasheet specification. This will cause damage the opamp or damage the device.

   

It is recommended not to exceed the opamp datasheet specification. For better operation, please use the

   

load resistor which is greater than output voltage/25mA.

   

 

   

Please let me know do you have any more queries.

   

 

   

Thanks and Regards,

   

Ramesh B

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

When I probe the resistance between an opamp's output and the connected output pin in the analog view using the ohm meter I get a result of ~550 ohms. So the current when shorted should not exceed 9mA @5V. Where do I go wrong? Is there a secret path with only 200 ohms? Or even some negative resistors?? 😉

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I get the absurd opposite result, but note no switches are in

   

the path, eg. its a direct route.

   

 

   

Also the tolerance as stated is - 57% to +83% for the ohmmeter readings.

   

 

   

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Apollogize! I had opened a PSoC5 project and the question was for a PSoC4.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Here is a 5LP result where I let tool pick pin, result a direct

   

route -

   

 

   

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Obviously not my day at all, I probed a PGA instead of the opamp. Sackcloth and ashes...

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Quick update: I finally had a chance to do some more extensive hardware testing on two separate BLE Pioneer Kits. The first is the one I wrote about in the original post, where I thought I had fried the opamps. The second was used, unfortunately, on the same project although only briefly, and I unplugged it as soon as I saw it wasn't working. I still have a factory-wrapped board at the office, so maybe I will try to retrieve it later this weekend for a similar test.

   

 

   

The results: all four op amps on both boards work just fine as voltage followers. When configured as non-inverting op amps with a gain of about 1.45, only three of the op amps on each board worked. On both boards, OA3 did not work and only put out about 50 mV regardless of input. As I had noted earlier, for an op amp to work as a follower and not as an op amp, the only thing that changes between the two cases is external pin P1.4.

   

 

   

Any thoughts on how I could have fried P1.4 on two separate boards, and how I can avoid doing that again in the future, would be most appreciated. I am attaching the very simple project that I created to do these tests.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

You are frying a pin configed as input, no appreciable current flow

   

due to FDBK R's.

   

 

   

First thought that comes to mind is taking this pin outside either rail by a diode

   

drop, then its parasitic diodes will draw a lot of current. May cause part latchup.

   

 

   

Or ESD and pin gate oxide in the inputs getting blown.

   

 

   

I have not looked at TRM, but can you route that OA to a pin other than P1.4, or is

   

it constrained ? Probably the latter since it is PSOC 4, which is highly constrained.

   

 

   

One thought, since pin is connected to OA input, hence not drawing current, temporarily

   

puts a series R of say 1 K to pin, so that if you are causing transients due to L effects

   

somewhere in circuit that will limit current. Note that will do nothing for ESD unless you

   

add a couple of diodes as well to pins to turn on when pin is taken outside Vssa, Vdda.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Okay, I think there might be an actual bug here...

   

 

   

I took a brand new PSoC 4 BLE Pioneer Kit out of it's still-factory-shrink-wrapped box and the very first thing I did was a simple op amp test of OA3. It didn't work. I was even carfeul to be sure the board was powered off while I made the connections.

   

 

   

I then tested OA3 as a follower and that did work. I then tested all the remaining op amps on the board and they all worked as both op amps and followers. Remember that this was also the case on two other boards, although they weren't as brand-new as this one.

   

 

   

 

   

Trying to eliminate all possibilities, I connected my test circuit directly to the headers on the PSoC 4 BLE module, only drawing VDD and GND from the base board, and...

   

 

   

OA1 worked as an op amp!!!!

   

 

   

Could there be a bug in the base board? Or could it be because P1.4 also has to act as the UART RX for Arduino shields? I think I will create a case for this one.

   

 

   

Thank you all for the help.

   

 

   

Don

0 Likes
Anonymous
Not applicable

 Further follow-up:

   

 

   

I redid my test of OA3 as an op amp (versus a follower) with the PSoC module back in the baseboard, but with the baseboard powered from a USB wall-wart as opposed to the USB port of my development laptop. It worked. I then tried it with the baseboard powered by the 2032 coin cell. That also worked, but the opamp topped out at 2.4 V instead of the 3.3 V I can get out of the op amps when powered by USB with the 3.3 V setting selected by J15.

   

 

   

I did create a case for this, but I am wondering if it has something to do with P1.4 being the RX of the USB UART. Strange, though, that P1.5, which is the TX for the USB UART, doesn't seem to be affected by that.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I think you are seeing the effects of P1_4 connected to a PSOC 5LP output

   

pin, whereas P1_5 is connected to a PSOC 5LP input pin. From the user

   

manual -

   

 

   

   

 

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Uh-Uh 😞

   

UART-RX means the the PSoC is on the receiving side, and this line gets driven by the PSoC5 KitProg. UART-TX means that the PSoC4 is on the sending side and the PSoC5 is receiving.

   

In your case this means that probably the PSoC5 was driving to line low, while the PSoC4 tried to pull it to a higher voltage (this might even be the case for all your tests). I'm not sure whether the PSoC5 UART is only active (meaning driving the lines actively) when the board is attached to a PC with the drivers loaded.

   

Your test seem to indicate that the port is still working. You can either, in your project, use other pins and force usage of other OpAmps that way. Or you remove R52/R53 on the base board to split the UART lines.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I think there should be some (prominent) warning in the kit user guide about that - it means that one of the OpAmps cannot be used fully.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Sure enough I did have the pins reversed.

   

 

   

   

 

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Not the pins, but the devices 🙂

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Re the shorted output case.

   

 

   

I did a test on the OpAmp output N Channel and P Channel, I got 7.8 ohms on the former, ~ 4 ohms on the latter.

   

Odd in that normally source bulk effect on P Channel causes it to have higher Rdson. Could be a f() of the non

   

linearity of the Idac, not sure.

   

 

   

So in short, no pun intended, the output if shorted to either rail, while OpAmp is being driven to the other, will cause

   

mucho mA to flow. My guess is it could take out metal layer route to source/drain of the output P or N channel on

   

the die.

   

 

   

 

   

   

 

   

Regards, Dana.

0 Likes