Undocumented Microchip Errata Strike Again

Two years ago, I found an issue with the open drain performance of one of the I/O lines of a PIC24FJ32GB002 microcontroller.  I got it confirmed from Microchip, but they never actually put out an errata on that behavior.  This time, I have found an even larger problem, that I am sure will rise to the level of an official errata.

I was trying to use a PIC24FJ64GC010 microcontroller in a design for a client.  The design has a capacitive sensing keypad that has worked well in the past with a slightly different Microchip microcontroller.  I moved to the PIC24FJ64GC010 because it had some other features that were necessary for the design.  Unfortunately, migrating to the new micro would prove to be problematical.  The capacitive keypad was implemented as shown in the schematic below.  In order to get the best performance, each button was implemented on its own.  In addition, the CTMU output current was routed through the internal op-amp as a voltage follower so that the noise immunity of the keypad would be greater.  Little did I know that dragons lurked in this approach.



Problems arose when I started shaking out the PCB.  For the life of me I could not get some I/O lines to output a current pulse.  The scope capture below shows the problem.  The yellow trace shows the output of the op-amp.  Every time the current from the I/O goes up, the current on the op-amp should ramp up.  The current is turned off and then a different I/O is selected.  Every time a button is sampled, the micro would toggle an I/O as shown with the green trace of the scope capture.  As can be seen from the scope capture, only 8 current ramps are shown.  However, there are 12 toggles on showing that the micro was trying to output current with the CTMU.



At this point, I put on my troubleshooting cap and went to work, because when problem like this arise it is almost always the engineers fault.  I individually addressed the I/Os shown in the schematic in digital mode – I could read inputs and set outputs as desired on ALL I/O lines.  I could also read analog inputs on all of the I/O lines (which due to the new A/D architecture is a feat in itself and will be detailed in an upcoming blog).  I could individually turn on and off the internal pull up resistors.  However, I could not make 4 of the I/O lines output CTMU pulses.  I even lifted individual I/O pins off of the PCB to ensure that the problem was not somehow related to the PCB layout.

I spent some time trying to cajole the Microchip application engineers that there was a problem and could they help me.  After fending off their initial dismissive replies (ie – “try using our sample code”, “it works here”, “have you used our demo board”, “you are overdriving the outputs, they should not clip”, etc), after 2 weeks, I was finally able to convince them to look at the problem for real.  I had to send them my hardware. and from there it was easy for them to confirm the problem.  Another engineer here was able to initially figure out the pattern that allowed the diagnosis, which is fairly odd:

“The CTMU will NOT output on any A/D that is even and less than 15”.  For example, RB4(AN4) will not output CTMU pulses while RB1(AN1) will.  Unfortunately for me, I had randomly selected four of the offending analog I/O lines.  This was a setback to the schedule and my stress level.  However, at least I know I am not crazy and I did everything I could to get the part to work.  In order to get the design to work, I needed to reroute the board and leave off these bad I/Os.

Unfortunately, I do not know if this is a family-wide problem, or a problem with any of the new advanced analog micros, or just related to the PIC24FJ64GC010.  It will be interesting to see what the errata says.  Microchip put out a new errata sheet on 4-20-14 (about 3 weeks after they confirmed the problem), but this issue is not listed.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.