Resume: the new mcp23017 datasheet (2022) says that GPA7 and GPB7 pins are now outputs only. 
2 Likes
A serious issue for zynthian designs, that use all 16 inputs from older chips. Shit!!
2 Likes
yes indeed !
and without any modification of the manufacturerâs commercial reference, I canât even believe it.
Product Change Notification / SYST-30BCIH037 states, âNOTE: Please be advised that this is a change to the document only the product has not been changed.â
Someone needs to verify whether any behaviour has changed. It seems pretty unlikely that Microchip would change the behaviour of a device like this.
From looking at the comments in the linked page those two i/oâs have been buggy for a long time. Thereâs also suggestions of using PCA9535 instead although itâs not a drop-in replacement.
device is supported in Linux kernel and by RBPi.
But I canât find it in WiringPi âŠ
PCA9535 is not supported by wiringPI library. I was tempted to change to this IC some months ago, when designing the V5 control board and MCP23017 was impossible to find, but i considered all factors, including software rewriting & debugging, and finally decided to bet on MCP23017.
By the comments in the page linked by @le51 and the note copy/pasted by @riban, the change in documentation could be some kind of back-guard for the manufacturer. If the design is buggy and the GPA7 and GPB7 fail under some circumstance, this change in the data-sheet is an un-elegant, but pragmatic way of covering their back from future claims. This comment from hackadayâs page is quite relevant:
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.
and this one has a lot of sense too:
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.
It seems they are not going to change the manufacturing photo-liths in the short term. Probably is not so easy, given this is an old design and the software used for it could be unavailable. Perhaps they canât load these project files in any modern software and they have to re-design the IC from schematic plots. Funny thoughts ⊠
Regards!
1 Like
I must say, and Mr. @riban could confirm, that we experienced strange behaviour from this chip while writing/debugging the zyncore library. Specially when not using de-bouncing capacitors, we reached to totally knock-out a full GPIO bank / interrupt, being GPA7/GPB7 the issue-triggering pins.
With the de-bouncing capacitors it seems the issue is solved, but probably, if some of you insist long-enough in moving very aggressively the knobs, you could experience the chip failure.
All the best!
1 Like
Hi all,
explanation to this problem is here :
https://microchip.my.site.com/s/article/GPA7---GPB7-Cannot-Be-Used-as-Inputs-In-MCP23017
In fact, Microchip DID NOT remove the two inputs physically on the chip, but they have noticed a problem in the chip design (the two inputs are acting badly on SDA line, corrupting the data). So they simply say : donât use the two pins as inputs or you will have problems.
Or if you prefer : use them as inputs at your own risk
This is not the first time (and not the last time) a chip manufacturer does that. 30 years ago, I got a similar problem with a board equipped with a Z80 processor. The distributor told me when I wanted to buy chips for the production âI have some stock, but the chips have a small issue on the RESET pin which does not act exactly like described on the datasheetâ. I donât remember exactly the issue but I had to add a gate somewhere to make the board start.
Back to the MCP23017 : if it can help in a way or another, I have created an FPGA clone prototype for the MCP23017 based on the Lattice iCE40HX1K. The FPGA costs around 5⏠but it provides a lot of I/Os (it has 96 I/Os, so it can replace up to 8 MCP23017). This may be a solution if you need to make a board revision
Benoit
2 Likes
Wow - that is interesting - I think it is unlikely we would use it to replace this MCP23017, but might use it for other things. Is there a project page you can point us to?
1 Like
Hi Tunagenes,
I work a lot with FPGAs but I donât publish a lot of things, for various reasons (one being that open source with FPGA is quite a complex topic to handle - if you want, this is something I can explain in private message)
The MCP23017 is something I started when it became impossible to find the chips during the Covid crisis. To be honnest, I have to take a look back at the project, as it was more a proof of concept than a complete design (but the core is working).
You can take a look to this page to see the kind of things I have done :
https://hackaday.io/project/158286-stebus-fpga-board
This is a FPGA board I created for the STEBus (I designed the hardware and the FPGA source code) and I allowed the project leader to publish all files
And on my Github you can see what I have done for the Olimex Lattice FPGA board
I also started a projects to recreate synthesizer chips (like the DOC 5506 used in Ensoniq synthesizers), but I did not publish the VHDL code for this.
Note that I also wrote a Raspberry module to load the Lattice FPGA using the RPi SPI port (the FPGA requires an extra memory chip otherwise)
Benoit
2 Likes