Comparative technical support with tortuous tricky technical problems

Article By : Aubrey Kagan

To understand a problem caused by the interconnection of two ICs, I resorted to using tech support from the respective companies. The difference in their approach to a customer’s problem was stark.

Not for the first time, our own inimitable Max the Magnificent has provided a segue into one of my blogs. In his “Tortuously Tricky Technical Problems” (TTTP) he concluded:

“These are the sorts of problems that can keep you up at night. They are also the ones that, when you finally figure them out, cause you to leap into the air punching the sky and hooting and hollering with a great big smile on your face. Speaking of which, do you have any weird and wonderful experiences of this kind that you would care to share with the rest of us?”

Well I am sharing – blame Max! Often when I am faced with a TTTP no one really knows the answer, but it helps when there is someone with sufficient insight who can ask the right questions that prompts an investigation that leads to the answer. My employer is a small organization and so there aren’t many people to ask. In addition I am of an age that I am that person others ask for insight. When I have a problem I sometimes have to turn to technical support of the chip manufacturers and their responses can sometimes be helpful and sometimes, not so much.

Let me set the problem for you. I had designed a project and when it came back from manufacture I passed the hardware to a neophyte engineer along with a specification and asked him to design the firmware and then complete the design.

I love Maxim parts – Maxim is a company with innovative, inspirational and reliable parts and really good data sheets. My record also shows that I am an ardent PSoC supporter. My overall hardware design was a crib of a successful previous one with a slightly different I/O that used a part from both Maxim and Cypress. I prefer external watchdogs in microcontroller designs and I had designed in a Maxim MAX824L, an integrated circuit I have used successfully several times before. It is coupled with a Cypress PSoC4 microcontroller. The nub of the design as it affects the impending problem is shown in Figure 1.

click for larger image

Figure 1- Portion of the circuit pertinent to my reset problem. My apologies – the symbol for the MAX824 was created in PCAD. Altium didn’t do a great job in translation. (Source: Author)

Because of the interaction of the microcontroller debug/programming connection (plugged in on P2) the reset output of the watchdog is separated from the reset input of the micro by a jumper P3. Connection across jumper P3 is done towards the end of the development when it is possible to disconnect the debugger and test the watchdog operation. Let me add that according to the PSoC data sheet, the XRES input has a 5K pullup resistor that is permanently enabled.

The watchdog and micro both worked without the jumper installed, but when P3 was shorted the micro stayed permanently reset. My colleague initially reported to me that the XRES line of the micro (which is the /RST line on the watchdog) was continuously low. This was surprising to me because the source project seemed to work fine.

The tests I suggested and then executed as the problem persisted were manifold and here are only some of them. First we replaced the MAX824L with a MAX824R. The “L” version has a threshold of 4.63V, whilst the “R” version has a threshold of 2.63V. This was not inspirational – we thought the original device had been damaged and the “R” it was the only stock we had. This worked, but when we looked at other modules with the “L” part the problem persisted. Worse, the original project exhibited the same symptoms when the micro was blank.

At the risk of perhaps insulting your intelligence, let me explain. If the micro is unprogrammed then the /RST line of the watchdog should oscillate at about 1 Hz. In our case it was in a (reported by my colleague) continuous reset state. This seemed to suggest that the micro was somehow draining enough current from the /RST pin to appear to the MAX824 that the supply voltage was below the threshold (since the 2.63V part worked).

The MAX824 has a push-pull output so it can source current as well as sink it. I placed a 10K series resistor between /RST and XRES first to decouple and then to monitor the current. The MAX824 oscillated as it was supposed to. There was no significant current when /RST was high and when low the resistance divider created with the PSoC4 internal resistor confirmed that it was an internal 5K resistor. When I changed the series resistor to 5K (with resultant voltage of 2.5V on XRES) the PSoC remained held in the reset state. I also wondered if there was a current source in the PSoC and tried a Schottky diode in place of the external resistor in either direction. In addition I tried pullup and pulldown resistors in parallel with the XRES input. Again no conclusion – there went that theory.

I though there may be some other faulty connection on the board and so I disconnected pin 32 (XRES) of the micro. Another dead end.


Figure 2- Internals of the MAX824. (Source Maxim Integrated Products)

That evening in the shower I had an epiphany. The MAX824 has a feature that if the WDI input is left floating, the watchdog function is disabled and although the PSoC4 will supposedly set the output to a predetermined value on reset, I thought maybe whilst the reset was active the output wasn’t being defined leaving the watchdog inoperative in a perpetual motion feedback loop. You can see in Figure 2 the feedback buffer on the WDI input, which I thought may be influencing the setup. I woke up at 4AM thinking that it didn’t quite explain the circumstances, but I went ahead and removed the WDI input from the board and connected a pullup to it. No difference to the problem. Epiphanies aren’t always right! Which begs the question, if an epiphany isn’t right, is it really an epiphany? That’s enough philosophy; let’s get back to the problem at hand.

I then tried a MAX1232 (note the “1” before the “232”. This is not the famous serial port part, but a newer version of the Dallas Semiconductor (now Maxim) DS1232) as a watchdog instead. I have also used this part extensively and had stock to experiment with. The MAX1232 has an open collector output, just to take a different approach. It also monitored the XRES line for myself and noticed a very short 34us pulse every ~1 sec. At that point I decided that the PSoC was feeding back a reset signal to the watchdog and was about to insert a logic gate to prevent it affecting the reset from the MAX824. Conveniently a tech support provided the answer at that point, but before I get to the solution let me contrast the tech support I received.

In order to shorten this blog, I was going to break here for a month to leave you, dear reader, to see if you could think what the problem might be, but the solution is so far outside the details I have described, that it wouldn’t be fair. Also the powers-that-be disapprove of two parters. Still, if you want to give it a shot, go get a cup of coffee and think about what you might do next.

Continue reading on Embedded.com

Virtual Event - PowerUP Asia 2024 is coming (May 21-23, 2024)

Power Semiconductor Innovations Toward Green Goals, Decarbonization and Sustainability

Day 1: GaN and SiC Semiconductors

Day 2: Power Semiconductors in Low- and High-Power Applications

Day 3: Power Semiconductor Packaging Technologies and Renewable Energy

Register to watch 30+ conference speeches and visit booths, download technical whitepapers.

Leave a comment