The MCP23017, a 16-bit I2C GPIO expander, has always been a tasty chip. With 16 GPIOs addressable over I2C, proper push/pull outputs, software-enabled pull-ups, eight addresses, maskable interrupts for all pins, and reasonably low price, there’s a reason it’s so popular. No doubt due in part to that popularity, it’s been consistently out of stock during the past year and a half, as those of us unlucky enough to rely on it in our projects will testify.
Now, the chip is back in stock, with 23,000 of them to go around on Mouser alone, but there’s a catch. Apparently, the lengthy out-of-stock period has taken a heavy toll on the IC. Whether it’s the recession or perhaps the gas shortages, the gist is — the MCP23017 now a 14/16-bit expander, with two of the pins (GPA7 and GPB7) losing their input capabilities. The chips look the same, are called the same, and act mostly the same — if you don’t download the latest version of the datasheet (Revision D), you’d never know that there’s been a change. This kind of update is bound to cause a special kind of a debugging evening for a hobbyist, and makes the chip way less suitable for quite a few applications.
It’s baffling to think about such a change happening nearly 20 years after the chip was initially released, and we wonder what could have caused it. This applies to the I2C version specifically — the SPI counterpart, MCP23S17, stays unaffected. Perhaps, using a microcontroller or shift registers for your GPIO expansion isn’t as unattractive of an option after all. Microcontroller GPIO errata are at least expected to happen, and shift registers seem to have stayed the same since the dawn of time.
The reasons for MCP23017 silicon getting cut in such a way, we might never know. At least now, hopefully, this change will be less of a bitter surprise to those of us happy to just see the chip back in stock — and for hackers who have already restocked their MCP23017 hoards, may your shelved boards magically turn out to have a compatible pinout.
Eish! Why not give it a slightly different part number to distinguish it 🤦🏽♀️
Because that would cost more for packaging, website updating, yada yada lol
You have no idea what your talking about. Changes nothing for packaging. They had to update the site anyways to put the new data sheet up, yada, yada, yada…
I worked at a company where we had to change the features on a consumer electronics device which caused a redesign because the lead time on the packaging change was too long.
A HARDWARE REDESIGN because of a cardboard box. You’d be surprised how ridiculous companies can be.
Pfft. YOU have no idea what you’re talking about. When we make a package marking change it is a lot of work. We have to update wafersort and final test program names so we can split out the FT data for the product engineers so they can track wafer yield changes separately. We have to regenerate new test limits, in some cases we have to requalify HTOL and HAST, we have to make a new project in our project management tools so that we can separately order leadframes for the two types (you don’t just get to go raiding the leadframe suppliers, because they’re backlogged by months and you order based on project priority and expected sales) and all the pricing and the pricing markdown schedule have to be regenerated, spin the spice models, spin the datasheet, and I don’t even know how they track this in the factory that actually does the package marking because we outsource that and this means a whole new set of orders and inventory management with them as well. It’s not like developing a new core, but it’s a silicon spin and takes just as much work as any other spin.
I have never heard of this happening before on a non programmable chip. Should have had a new part number. I’ll bet someone screwed up a die shrink for cost savings.
That was my immediate thought too. Probably discovered after the volume run. Will likely catch many out :(
Sort of my first thought. These are essentially “seconds”. They’ve got a couple hundred chips that maybe had one or two bad transistors on the input of those two pins. But due to the shortages and long lead times, they just put them out there as is.
There really can’t be any savings to removing input capability on two pins. Even so, the price could be raised. Has to be a mistake. I hope someone grabs a few and de-lids them to see what happened.
Definitely should have a new part number though. That’s going to be a mess.
There have always been issues with using these ports as inputs. You probably still can, but it is now explicitely stated you shouldn’t.
Technically, the parts are distinguishable: It is revision C and Revision D.
You should never assume compatibility between different revisions of the same part.
Sometimes the same partnumber is used and the part produced by different manufacturers. The functionality is the same, although the specs might not be.
You should never assume a part of one manufacturer can be used as a drop-in replacement for another.
You might get away with it almost every single time,but not always…
You can get away with it EVERY SINGLE TIME, 50% of the time.
Perhaps they had a bunch of wafers with one input failed. The failed wafers could be grouped by what failed and have modified microcode and leadframes so that you get a chip with two fewer inputs made from what t would have been waste. Kind of like how Intel is rumored to have made I7, I5 and I3 chips from Xeon wafers…
This is outrageous for them not to change the part number in some way! This is going to burn so many people. Why? The countless purchasing agents just waiting for this to come back in stock so they can start building boards and shipping product again are NEVER going to think that its was changed in some way because of the same part #.
Hackaday, Now this is some real reporting!
> Perhaps, using a microcontroller […] for your GPIO expansion
I’m betting 20€ that I’ll donate to a charity of consensus if someone can show that a microchip-produced GPIO expander is not just a packaged PIC microcontroller with factory-burned firmware. I haven’t found a decap of that chip yet.
That would probably be significantly more expensive, since it would require much more silicon (CPU, flash, RAM, etc.) than just making the thing in logic gates, especially 20 years ago.
Also, it would have to run on an internal oscillator, which would cause an easily detectable current ripple on the power supply, it would introduce a significant delay from the input pin change to the interrupt signal output (datasheet says max. 600ns). Lastly, it would be quite difficult (I’d say impossible) to get a 1uA standby current while monitoring for data and pin changes.
It isn’t that farfetched. Microchip’s USB to UART bridge chips are preprogrammed PICs. They’re making huge numbers of PICs so reusing one is an easy decision.
Well the FAE is going to get an ear full. I just released a new product with this chip that uses both pins as inputs. I used it because we had 500 it in our inventory. This change will require a board respin which the tooling alone will cost more then those 500 chips. I guess they don’t want our business.
What are they thinking!
I bet they’re shaking in their boots.
Ha ha ha!
Well did the two pins work as input on the earlier revision in the first place? Maybe it was a hidden silicon “feature”? ;-)
The silicon on this chip is quite buggy with a ton of weird edge case behaviours.
A serious erratum relating to the use of these two pins as inputs has been known since 2014 (there are discussions about it on microchip support forums) but had not made it into any official documentation.
I guess, after 9 years, the manufacturer decided that this erratum was worth putting into the datasheet.
I’m guessing they remembered they had a failed batch in storage they realized they could unload. Or the first batch after they restarted was faulty; however would work for most use cases.
Either way they felt like unloading it.
I wonder how many chips / projects can be replaced by a modern RP2040 chip for example. Poor Arduino is losing a lot to them. Real Raspberry boards are at parity with bottom of the barrel Arduino knockoff boards while boasting much more in compute power/features.
The main difference between them though is the rpi0 is a cortex m0 which is a von Neumann architecture, the arduino uses a modified Harvard which can make it better suited to some applications where the m0 might bottleneck and viceversa in terms of other attributes
It’s comments like these that keep me coming back to hackaday. That being said Arduino does have boards with 32bit atmel chips that use cortex m0 architecture among others.
Even if he’s wrong, he’s probably not gonna care about it, what with your know it all superiority complex, your nose stuck everest-high in the air, good lord.
Actually I completed my studies on systems architecture, thanks. I think you are the one who needs to go back to studying buddy, and maybe take some personal development courses so you can improve those social skills on not being a prick to people :D
P.s. The cortex M0 is a Von-Neumann – Go read up on it and stop acting like a total ass with your superiority complex! Wowzers.
Source A: https://developer.arm.com/Processors/Cortex-M0
Source B: https://wikipedia.org/wiki/Arm_Cortex-M (Just in case you prefer wiki over the horses mouth)
Johnathan, superiority complex? You’re projecting. Either add something to the conversation or stay quiet. You’re not a white knight, Ron’t not going to ‘be your friend’.
Ron, go back to school and this time pay attention. Your first link doesn’t say what you seem to think it says. It actually supports what I’ve been telling you. Your second link is to a non-existant page. I’m done trying to educate.
I don’t even know who you are and your first contact with me is to start with hostile comments out of nowhere. Either seek medical help for whatever mental state you’re in that is that is causing you to perceive me as some villain in your mind motivating you to go one whatever personal crusade this is for you, or engage in discussion like a stable minded adult. You haven’t even quoted anything in the source material I gave you that supports your case, and you’ve offered it with nothing but hostility and immature sentiment. So kindly point me to where it says exactly that, which proves what I originally said was explicitly incorrect.
I said in my original post that the two chips; the Cortex M0 and the AVR (on the original Arduino) were different design paradigms Von Neumann and Modified Harvard and that outside of apples to apples comparisons, they have their advantages in some cases where one may be favorable over the other in those specific use cases – to further expand on what i was saying.
I’m not claiming one is objectively better than the other, just that they are different and suit different design needs. I don’t understand why this simple statement sparked such random and exaggerated nerd rage from you; to start questioning my educational background with such extreme hostility what you literally have no idea who I even am or anything about me.
I’ve added to this conversation, you’ve added nothing of substance so far, so kindly stop projecting.
Unless your next reply to me is either a light apology for being a toxic butthole, and/or actual citations to back up your claim that the M0 isn’t a Von Neumann architecture – Kindly cease.
FYI, here’s the repaired wiki url since you were too lazy to fix it yourself
https://en.wikipedia.org/wiki/ARM_Cortex-M
From the linked to page: “NOTE: Please be advised that this is a change to the document only the product has not been changed.”
It looks like the device did not change, meaning it was always 14 bits of input but the docs were wrong all along.
I have some of them running with 8 inputs and 8 outputs. Bought the chips a year ago.
I know both GPA7 and GPB7 work as inputs on the I2C version of MCP23017-E/SS as I am using both as inputs on a product my company produces. So I don’t think their note it is correct.
Yup. I found this thread on the microchip forums from 2014 where the answer is “don’t use GPA7/GPB7” as inputs. They seem to have some issues, at least with the I2C part. So maybe there has always been a problem with these two pins and the documentation is finally been changed to deal with it.
https://www.microchip.com/forums/tm.aspx?m=831656&mpage=1
I notice that it’s now automotive qualified, where it wasn’t previously. Automotive testing is a LOT more rigorous, and it’s possible that they could previously get enough chips through that passed all pins but now that they’re trying to supply automotive customers, the yield dropped so much that they gave up trying. So now they see a yield increase, to automotive test specs, but a note in the datasheet that they no longer guarantee those two pins to work.
I think this must be correct – searching before google is polluted by this article gave these as #1 result: https://www.microchip.com/forums/m831656.aspx , quoting [Jonas]: “Problem confirmed by Microchip support. Don’t use pin 7 of Port A or B as inputs. ;-)”.
This was 2014, so they took their time – perhaps it’s just buggy input, not entirely broken, but not to spec timings either.
this threw me off too! however, I myself have a product that uses all pins as inputs/outputs, so I can be certain it always worked this way.
Silicon bug, has been there since the beginning but not mentioned on the datasheet. It did byte me on a product I designed, and it caused us many headaches until it was replicated.
Part of me thinks that changing a chip’s internal functionality without updating the part number should be classed as a crime. Afterall, consider the chaos or outright damage it could cause to an electronic system if someone unknowingly puts in a chip of the old vs new type. Some people might want the old type, others might want the new type, there can be applications where substituting either for the other could be very damaging. Particularly nasty would be in an electromechanical system where one is relying on that, now missing, input channel for an end-stop switch. And imagine if you have a stock of these chips, some old, some new and you don’t know which are which? Furthermore a lot of sellers might actually have old ones in stock, old ones could be getting released by companies that temporarily hoarded them while new oens weren;t being made, a buyer won;t know which sort they are getting. I’ve seen companies change a part number just because a part used to come on grey tape strips and now comes on white, or because it was lead free in pratice but now its officialy lead free too, so why aren’t they changing the number when there is an ACTUAL FUNCTIONALITY CHANGE!
some other people did research and found that those two pins were never intended to be inputs or at least could be buggy
If they want to take shortcuts wit the silicon and change functionality, then sure, if the market will accept it. But to do this without changing the part number is a really silly move.
You can get many gpios in /sys/class/gpio via a USB i2c adapter with a spécial kernel driver and an mcp23017:
http://www.zoobab.com/ch341-usb-spi-i2c-uart-isp-dongle#toc17
This part sounds extremely similar in capability to the TI TCA9555 chip.
NXP sells the 9555 as a PCA9555 instead of the TCA. Their is also a 9535 that is also similar. Neither are footprint compatible with the MCP23017, but both are available
Luckily for my DomoNode 2.1 I migrated to PCA9555: cheaper, easier to code (registers don’t change meaning) and guarantees pin states at power up (can be quite important). And all IOs are equivalent :)
A modified part number on the die would have been the right move. This dampens my trust in Microchip Technology products.
I don’t know which is sadder, that Microchip changed the Datasheet, or that you trusted Microchip.
B^)
This reminds me of my IKEA Tundra laminate flooring. Due to flooding and later wear, I have had to replace a part of one room’s floor twice. The same product name and number (I would have never checked that, but if I did, I’d be none the wiser) has had three different connection systems that were incompatible. Twice I have bought half a room’s worth of Tundra then having to buy another half.
The quality has also gone down: while the first one showed minor wear after rolling a chair over it for 10+ years, the last version is already showing wear after half a year in my bedroom, where I never walk on anything other than soft-soled loafers or barefeet.
Just a question: Anyone have need of MCP23s17’s – I bought a partial reel of 1500 NOS ones [TSSOP], and was wondering if I should put them up on ebay?
What is your price? We use tons of these.
send me an email wackerkarl64 at gmail dot com [junkmail account] – I will email via my real accout
3$-4$ each, based on qty
Sounds exactly like something they would do. Found a silicon bug in their MCP16312, and they refused acknowledging it despite solid documentation from our side. They kept blaming our design around the chip until I made a video showing the issue on their own evaluation kit for the part. Then they silently made an errata regarding the issue, without even answering our queries as to whether the issue could be recurrent, while publishing said information in the errata.
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/Errata/MCP16311-Family-Data-Sheet-Errata-DS80000983A.pdf
Lately we observed some undocumented behavior with some of their LDOs, this time I just designed the part out and didn’t bother dealing with them.
How does something happen once in a device lifetime (where this event does not kill the device)? Also after 45 to 300s? Is it some kind of fuse that needs to be blown?
They said it was traced to gate oxide breakdown from accumulated charge in some part of the bias network. Apparently it doesn’t break the device, but causes an increase in idle current consumption. It’s related to temperature and time, and happens after some three to five minutes at room temperature.
This is due to a known problem in silicon. It cannot handle pulsing on these inputs as it scrambles the i2c communication.. had a lot of problems with this in a product..
It is also recognized by microchip itself though they apparently deleted the page about it.
https://forums.raspberrypi.com/viewtopic.php?t=91209&sid=e596150013435c4fcad537a4aa5e1a5c&start=25
Seems like a dream subject for another decap anslysis video!!!
Release [Ken Shirriff]!
I had just started using the MCP23017 IC when the supply crunch started. Ended up respining the design using the PCA9535 i2C GPIO expander IC. As other have stated it’s cheaper as well.
We use this part at my company, so I was very curious about this post. This is indeed not a change to the die. The last die revision for this product was in 2005!
Vaguely reminds me of the 486SX and 486DX in the past.
Yeah, but back then most folks buying just the standalone chip knew the differences. As opposed to a less technical savvy person just buying a complete computer with either already installed.
This is pure unadulterated evil.
I’ve got dozens of products which use this IC. I wondered why a bunch of parts suddenly showed up in Distribution a few months back. I snatched up 125 of the parts and felt lucky. Just went through my bag full of tubes. Fortunately, I’ve still got a few tubes of Rev C parts but now I’m stuck with the task up updating all my project webpages to add this painful caveat. And the customers who rely on me to deliver consistent products in the future will need explanations.
Upside is I can probably sell Rev C chips for a huge premium.
Microchip, you let me down. Different product – needs new part number not some mere update via PCN.
But, but…
It’s no different than Honda finding out their timing belts were breaking prematurely, so they issued an update to the Owner’s Manuals telling owners to replace the belts every 60,000 miles.
Check other comments: it’s a bug that has existed from at least as far back as 2014, they just finally got around to updating their docs.
This type of increment would surely mean part qualification needs to take place and a go no-go signal to manufacturing be sent. QA lab stuff.
And just yesteday I read a reddit post about somebody finding the hard way why his led were all defect – for the same reason at this post.
They switched the led polarity and just updated their datasheet, no different part number.
Except I would be really mad for a scenario like the MCP23017
I remember buying a pack of assorted LEDs at RadioShack. Each one needed to be tested for polarity, as the length of the leads or flat side of the plastic lens could not be trusted. If the plastic was clear enough, one could look in and see the shape of the lead termination.
So I was thinking… why not use RP2040 and control it over SWD?
It’s a two-wire interface and the it can be clocked pretty high. Think tens of MHz. Via SWD you can read/write to memory to control the hardware registers, meaning you can remotely toggle and read GPIO pins, ADC, configure PWM, measure PWM frequency and/or duty cycle, read temperature, even upload and run a PIO program (to decode multiple rotary encoders, for example). You can even store ingested data in circular memory buffers using DMA and then read them out once in a while.
You don’t have to add neither crystal (if you don’t need that precise timing) nor flash. If you want better timing cheaply, you could PWM the XIN via a separate line at 27 MHz.
It might even be possible to drive it via the same clock used for SWD, provided the data line idles high to always reset the protocol when unused. (I am not sure about that, it would need some testing.)
All you really need to add are 4 decoupling capacitors. Maybe just 2 if you test the design rigorously.
Sure, it doesn’t idle that well, but that’s nothing a $0.01 P-channel MOSFET wouldn’t solve if you really, really need those μAmps.
even if the initial characterization of this as a change, rather than the admission of a long-running fault that it seems to be was accurate, there are weirder, bigger issues than this buried deeper in revision notes all the time. the entire industry does this. this clearly updated data sheet is rather refreshingly decent.
And of course there’s no mention in the errata. And their own app note (4×4 keypad interface) uses port 7 as an input! I remember way back when Microchip was a great company.