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.

image

 

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.

image

 

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.

Measuring small currents with an oscilloscope

When designing systems with microcontrollers, it is often necessary to make them low power and to ensure they draw minimal current.  Unfortunately, common desktop instruments do not allow for easy verification of these currents.  A DMM can really only show DC currents and can’t capture transients.  An oscilloscope typically can only measure down on the order of 2mV per division range.  These limitations pose a problem for microcontroller systems that typically have to wake up periodically to check things and then go back to sleep:  the current waveform is too active for the DMM to measure and too small for the oscilloscope to resolve.  A simple and obvious method around this is to amplify the current measurement so that a scope can reliably show the current waveform.  This blog entry describes one, easy-to-implement method for accomplishing this.

The figure below shows the schematic for the amplification circuit using an instrumentation amplifier.  A brief description of the circuit follows. 

current sense amplifier.

  • The instrumentation amplifier is the Linear Technologies LT1920. This is a basic instrumentation amp (IA) that comes in a DIP package so it is easy to prototype and even breadboard with. It is readily available from Digi Key.
  • The gain of the circuit is set to 1000. With the expected minimum current of the DUT(on the order of 100uA) and a gain of 1000, the output will be about 100mV. This is an easy voltage to see with a scope. In addition the maximum current is about 5mA, so a gain of 1000 gives an output voltage about 5V. Again, this is easy to see with a scope.
  • The gain bandwidth product of the IA is large enough to show the transitions of the circuit.
  • The circuit is run off of +-10V so there is enough headroom to output the approximate +5V output. Dual supplies are necessary because the minimum allowed voltage input is V- + 1.5V.
  • The 10k provides a load so that output of the IA has a return path.
  • Pin 5 is tied to ground so that the output is referenced to ground.
  • Outside of the circuit are the Device Under Test (DUT) power supply, the DUT, and the current sense resistor. The current sense resistor is sized to ensure that the current can be adequately measured and that it does not affect the DUT performance. In this case a 1-ohm resistor is used because it meets these requirements and allows for easier math (see below).
  • The amplifier circuit was only bread-boarded so the actual accuracy is not dialed in, but the results are close enough to show the idea.

A typical low-power micro spends most of the time in a low-power state an wakes up periodically to check conditions.  The average current can be modeled as shown in the equation below.

clip_image002

To get the total average current the amplifier can be used to show the current on an oscilloscope and then the equation can be filled in.  Below is a scope capture of a typical micro current consumption while in a sleep condition.  The asleep/awake behavior can be seen. For approximately 80% of the time the current is low – the voltage is approximately 250mV which is equivalent to 250uA.  For the remaining 20% of the time, the micro is waking up and then for a real short time it is at full power as it performs its actions before it goes back to sleep.

image

By zooming in on the higher current portions the following times and currents can be found for the DUT.

Micro State Duration Current (Measured Voltage/1000)
Asleep 813ms 250uA
Waking Up 185ms 925uA
Active 2ms 5.5mA

Using these measured values, the average current equation can be filled out as shown below.

clip_image002[7]

So in this case, the average current for the micro system is 385uA. 

This method can be modified to measure smaller currents by increasing the current measurement resistor and/or increasing the gain of the IA.  Also, more accurate measurements can be made by placing this circuit on a PCB.  Also other IA ICs can be used to get better performance.  Hopefully there are some ideas that you use to help troubleshooting in the future.

The travails of fixing an old design

 

data_erase

 

Recently I had the opportunity to fix a design I did way back in 2005.   It turned out to be a bit more trouble than I anticipated.  In the past I have talked about the need for good record-keeping and how that gets harder  and harder to do as the technology in question gets older and older.  Fortunately for me we had been conscientious enough to retain enough of our old-technology to allow me to fix the problem . . . . barely.

[Read more…]

Tracking days, hours, minutes, seconds with Excel

When testing different projects, sometimes it is helpful to know how long something has been running.  I recently ran into this while doing some final testing for a countdown timer for a client. For this particular design, I needed to test a circuit once a day for about a month. Unfortunately, I could not automate the test – I had to do it manually. Time to bust out a table.

 Microsoft Excel is usually my go-to application when I need to tabulate and collate some test information.   Excel is incredibly powerful and has a myriad of built-in functionality and programmability.  I am not an expert in Excel, but I can usually wrestle it into submission and get it what I want it to do.  For this particular testing procedure, I came up with a formula that may be of use to some of you out there.  Excel has some fairly powerful arithmetic capabilities built in.  Unfortunately, there appears to be a split between the Years, Months, Days operations and the Hours, Minutes, Seconds operations.  There are not any built in functions that allow the two types of operations.  I needed to roll my own.

I was going to run the test unit for 24 days.  I wanted to enter in a time and have the Excel sheet show me how much time would be left on the unit.  Here is the spreadsheet I came up with.  I will describe how each of the cells is derived along with some background.

image

A note on Microsoft Excel Time format.  Microsoft has a fairly unique time format for Excel.  See this link for information how it works.

The basic test was this: I put 24 days on my test unit and had it start count down.  Every day I would check to ensure that the test unit was counting down correctly.  Cell B3 shows the start of the test.  Cell C4 shows that 24 days are on the test unit.  Column B (Starting at Row 7) shows when the time was checked.  I could simply enter in the time and date in column B and the spreadsheet would take care of the rest.  After entered the time  into column B, Excel converted it to the Excel format.  I did that by simply setting the cell format to “General”.

Column D simply subtracts the converted time in column C from the converted start time.  So in D7, the “0.02083333” represents a half hour.  Column E shows what the time on the unit should be in the Excel format.  So in E7 the “23.97916667” represents 23 days, 23 hours, 30 minutes in Excel format.  Unfortunately, that is not easy to read.  Column F is where the magic happens.  The value in column F is given in the format of DAYS:HOURS:MINUTES:SECONDS.  So F7 is 23 Days, 23 Hours, 30 minutes, and the seconds values I don’t care about.  The formula to convert the E column value to the F value is given below:

=INT(E7)&":"& INT(MOD(E7,INT(E7))*24)&":" &  MINUTE(E7) & ":XX"

Here is how it works:

DAYS = INT(E7) – this is simply the integer value in E7, which in this case is “23”

HOURS = INT(MOD(E7,INT(E7))*24) – the “MOD” function, takes the decimal portion of E7.  By multiplying it by 24 (number of hours in a day), it gives the number of hours, in this case “23”.

MINUTES = MINUTE(E7) – this is a built in function that Excel has that tells how many minutes are in a cell, after all of the hours have been taken out.

With the help from Google. I was able to get a quick a dirty Excel spreadsheet to do what I needed.  Hopefully it will be of use to you.

Using the new Solutions Cubed USB to Serial Converter

I’ve been working on a project for a client over the last few months.  Like most embedded systems, it needs a simple communications interface for use during manufacturing.  The interface is used for such things as testing, calibration, and fine-tuning.  For a bunch of embedded systems, the easiest and most cost effective solution is a serial interface.  In an effort to reduce cost, all of the level conversion circuitry and the serial connecter were removed from the PCB.  Logic level signals needed to interface directly to the system.  So, in the factory, a separate dongle is necessary to provide the level conversion.  In addition, the vast majority of computers now days no longer have serial ports – they only have USB ports.

Luckily Solutions Cubed has recently come out with a small USB to Serial convertor in our Breakout Module line: the BM010. Taking something off the shelf to use made it very easy to quickly get a convertor up and running for our customer.  I simply laid out a PCB to carry the BM010 and the connector to the client’s board.  I used the $33 PCB special from Advanced Circuits to get a low cost dongle for our client.  The photo below shows the carrier board with the USB to Serial Converter attached;  the BM010 is in the lower left corner.

convertor

The neat thing about the convertor is that it is based on an FTDI FT232R IC, so the USB drivers downloaded automatically in Windows and I was able to get rolling quickly.  The device showed up as a COM port that I was able to access with a Visual Basic program and I could then run the client’s system through its paces.  The picture below shows the dongle attached to the target system.  I knew that the the break out modules were going to be slick, but even I was impressed by how easy everything came together for the USB to serial converter.

full system

A few Microchip 24F series A/D measurement tricks

 

clip_image002[4]

The Microchip 24F series of microcontrollers has an internal 10-bit A/D. A block diagram of it is shown above. There are a couple of things to note about the diagram – first is that it allows for independent inputs for VREF+ and VREF-. This allows the user to set the dynamic range of the A/D to whatever is appropriate for the input signal. If a very precise and accurate reference is used, accurate absolute A/D measurements can be made. This is a very handy feature. If VREF- is tied to ground, the A/D results are given with the following equation:

clip_image004[4]

So if the Input voltage was 1.250V and Vref was 2.048V, the resulting AD Counts result would be 625. That takes care of the standard ‘vanilla’ use case of the A/D.

Also note in the block diagram there is an internal band-gap reference that can be measured by the A/D: VBG. The information about the band-gap is shown in the table below. It has a +/- 5% accuracy. Unfortunately, this reference cannot be routed to the VREF inputs. An external reference must be used to automatically scale the A/D results.

clip_image006[4]

In cost-sensitive designs, this could cause a problem. Because there is an accurate reference on-board, workaround would be nice.

I ran across this issue just recently. Here is a trick I came up with that allows for using the internal band-gap and alleviating the need for an external reference.

Measuring Vdd

In battery powered designs, it is common for the micro to be powered directly from a battery, without an intervening regulator. In this case, it is common to need to measure the battery voltage to check how much battery life is left. However, if Vdd is used at the Vref, an accurate battery measurement cannot be made. However, if a known voltage is measured the reference voltage (Vdd) can be inferred. The equation below shows how this is done.

clip_image008[4]

In this case, VBG = 1.2V, MaxADCounts = 1024. So, if the A/D Counts = 410, Vdd would be 2.997V. If A/D Counts = 450, Vdd would be 2.73V.

 

Further Uses

By measuring VBG periodically, Vdd can be determined. If the A/D is used with Vdd as VREF+, accurate absolute measurements can be made by doing ratiometric adjustments. The full equation for this given below.

clip_image010[4]

And Vref is given by

clip_image012[4]

Which gives the complete equation:

clip_image014[4]

SHA-512 encryption–the easy way

Over the last couple of months, we have been working a project for a new client.  It is a custom-user interface that requires encryption.  We have done encryption before for the financial industry, implementing 3DES with DUKPT key management.  We’ve also done MD5 hash algorithms and AES.  In all of these cases  we’ve had to “roll our own” code.  We found the relevant standards and implemented the code.  It was a time consuming and mind-numbing process.  This is doubly so for the 1DES and 3DES code, when we accomplished this task by writing it in assembly!  However, over the past five years, most microcontroller suppliers have really filled out their offerings with encryption.  Over the past week, this has really come in handy.

The new design is defined using the SHA-2 algorithm.  Specifically the SHA-512 implementation – the big daddy.   After checking out the specification, and getting a mild case of code phobia, I decided to see if there was some help on the web.  We are using a 24FJ-series microcontroller from Microchip.  I did a quick spin through the Microchip website looking for encryption ap-notes or libraries.  Unfortunately, their published libraries only covered algorithms through SHA-1.  Things were looking grim – we were going to have to code up the SHA-2 from scratch.  As a last gasp, I contacted Microchip directly through their normal tech support channel and asked if there was a SHA-512 ap-note I had not seen.  They did NOT; however, they did have some beta code for an ap-note/library they are working on and they provided it to me.

I tried the Microchip SHA-512 algorithm out and spent about 10 hours with it, making sure everything worked with standard test vectors and with the test vectors from the back-end of the system we are interfacing to.  Success!  I was able to get this chunk of the design roughed in in about 20% of the time I was budgeting.  Microchip really saved my bacon.  I am really impressed with Microchip and their “above and beyond” approach.  More on this project later.

Helping the USFS fight fires

The day after the Thanksgiving break, I had the opportunity to give a training to the US Forest Service at the Air National Guard base in Oxnard California.  During the winter, the USFS performs maintenance and upgrades to their aerial fire fighting equipment.  In this case it was for their MAFFS program.  Even more specifically, their MAFFSII program.  About ten years ago, Solutions Cubed developed the electronic controller for the fire fighting system.  It reads inputs such as drop amount and flow rate and then controls the output so that the right amount of retardant is dropped for the right amount of time.  We were sub-contracted to the main company that produced this system.  Unfortunately, during the economic downturn, they went bankrupt and the USFS is now scrambling to cover the support issues with the system and its continued operation.  That is where the Solutions Cubed training comes in.

There are about ten mechanics that service all of the MAFFS systems, but they were not around during the initial design and development of the system.  In addition, they are not super techno-savvy.  Also, because the MAFFSII system is loaded into Air National Guard C-130 airplanes, there is a layer of military rules and regulations on top of the USFS layer.  So the training and resource materials we provided had to be very straight-forward and super easy to follow.  I was able to accomplish both goals, but just barely.  When I started the two hour talk, it soon became apparent, I was approaching the training from a too-technical direction.  I was able to change things up on the fly and things went smoothly from there.

Solutions Cubed redesigned some interface software for the controller, so we demonstrated its use and detailed all of the functions of the controller.  The mechanics and the USFS representatives were receptive to the training and appreciated the contents.  After the classroom portion of the training we were able to try out the new software on an actual system that had been removed from a C-130 and was on a trailer.  The photo shows the size of the system and its complexity.  After we hooked up the software, we went through a couple of procedures in the manual.  We found a couple of problems with the documentation that Solutions Cubed will have to change, but overall it was a good training.  I look forward to seeing the planes flying and fighting fires again.

 

2012-11-26 12.54.09

New product initial prototyping

We’re excited that the first five of our new open-source modules are on the shelf and the next five are hot on their heels.  I have been working on a new product on and off for the past six months.  Unfortunately, I ran into problems during the design.  Because the new product is aimed squarely at the Maker-set, easy Arduino interfacing is a must.  My original design accomplished this, but ran at +3.3V.  This made interfacing sometimes problematical and I kept having to make design compromises.  Eventually the tradeoffs became too much and I decided to start from the beginning and try to overcome the majority of the tradeoffs.

To that end, I switched the main microcontroller over to a +5V capable one, the Microchip PIC18F25K50.  For my purposes, the important attributes of this controller is that it runs from +2V to +5V so it can interface to a wide range of host controllers.  It has an internal oscillator, a USB port, serial port, EEPROM, and 14 channels of A/D.  In addition to changing the controller, we have changed the product’s approach to line up with the new modules:  the initial version will be open source hardware, and use the castellation/pin-header capability that the new modules have. Standardizing the connection methodology will make all of our modules easier to use.

In order to speed up the development and reduce said-development costs, I have bread-boarded the initial design.   As seen below, it is a bit of a rats nest, but the basic functionality is there.  I’ve done some basic testing and the new schematic with the new microcontroller seem to work well.  With the old design, I had the code about 75% done, but with the new design I have to change a bunch of my code to match the new controller.  Then I need basically retest everything.  Hopefully I will be back to where I was in about 3 weeks.  However, I am pretty excited with the new direction of this product.  Within about six to eight weeks we should be able to announce the actual product.  Keep your eyes peeled for more information.

2012-10-31 05.09.42

Plotter nemesis defeated

I have a love-hate relationship (as do most folks in our office) with our HP 450C D-sheet plotter.  On the positive side of the ledger:  it prints out D-size sheets in color.  This proves valuable for schematics – having the entire circuit on one legible page makes understanding and troubleshooting designs much easier than having the schematic on a screen or paging through a bunch of 8 1/2” X 11 “ pieces of paper.  On the negative side:  it uses 12-year old ink-jet technology, so the ink pots dry out, unless a couple of full color pages are printed a week; loading a roll of paper, while theoretically easy, tends to become a half-hour adventure in “hoping the plotter accepts the paper this time”; sometimes it does not print certain symbols on the schematic; it is 12 years old, so it is obsolete and HP does not seem too keen on supporting it.  All that aside, the plotter is a workhorse in our company.  Because plotters are such a low volume item, the price of a new replacement is on the order of $2500 – pretty big pill to swallow when the plotter “mostly works”.

Unfortunately, last Thursday, the plotter gremlins decided to strike.  I was plotting a schematic for a new test circuit when the plotter made the most ungodly noise and stopped working altogether.  All three of the error indicators were blinking an ominous orange.  Upon further exploration, I was able to see that the main drive belt appeared shredded.  Much to my chagrin, there is no easy way to replace this.  Luckily I was able to find the actual service manual on line and disassemble the plotter.  Because of the way the plotter is assembled, this project would have been much more difficult without the manual.  There are a bunch of “hidden” screws and odd orders of operation.

IMG_0707

After some teeth-gnashing and hair pulling, I removed the offending belt.  Obviously, there was no way to salvage it.  I think the belt was the original – so the 12 year old rubber was probably due to fail.

IMG_0706

I ordered a new belt through Amazon.  It showed up the next day (amazing!).  I was able to get the plotter back together on Friday – it all looked good.  But I was unable to load the paper before I had to leave – my first try ended in heartache.  This morning I tried again and 20 minutes later, I had the plotter back up and running.  Now I should be able to get back to designing cool stuff, and the rest of the office can plot in peace.

IMG_0708