Using an Adafruit ESP32-S3 Reverse TFT Feather with a custom board that contains 2 MCP23S17 GPIO expanders. I have SPI communication running properly, utilizing the Adafruit MCP23017 Arduino Library. There is no problem turning a GPIO pin On or Off as a single instance, however any time I try to turn 1 pin on, wait a period of time and turn another pin on, the first pin is reset to LOW.
Code Example comes straight from the Adafruit drive examples:
// Blinks an LED attached to a MCP23XXX pin.
// ok to include only the one needed
// both included here to make things simple for example
#include <Adafruit_MCP23X08.h>
#include <Adafruit_MCP23X17.h>
#define LED_PIN 7 // MCP23XXX pin LED is attached to
// only used for SPI
#define CS_PIN 5
// uncomment appropriate line
//Adafruit_MCP23X08 mcp;
Adafruit_MCP23X17 mcp;
void setup() {
Serial.begin(9600);
//while (!Serial);
Serial.println("MCP23xxx Blink Test!");
// uncomment appropriate mcp.begin
// if (!mcp.begin_I2C()) {
if (!mcp.begin_SPI(CS_PIN, &SPI, 0x20)) {
Serial.println("Error.");
while (1);
}
// configure pin for output
mcp.pinMode(4, OUTPUT);
delay(5);
mcp.pinMode(5, OUTPUT);
delay(5);
mcp.pinMode(6, OUTPUT);
delay(5);
mcp.pinMode(7, OUTPUT);
delay(5);
//mcp.writeGPIO(HIGH, 0);
Serial.println("Looping...");
}
void loop() {
mcp.digitalWrite(4, 1);
delay(5);
mcp.digitalWrite(5, 1);
delay(5);
mcp.digitalWrite(6, 1);
delay(5);
mcp.digitalWrite(7, 1);
delay(5);
mcp.digitalWrite(4, 0);
delay(5);
mcp.digitalWrite(5, 0);
delay(5);
mcp.digitalWrite(6, 0);
delay(5);
mcp.digitalWrite(7, 0);
delay(5);
}
When this is run the output looks as below, each pin that turns HIGH forces the other pins LOW.
What is even more frustrating / confusing - this is not always the case - sometimes a pin will stay high for 2 instances before being forced LOW (as can be seen in the below image in the orange and brown traces) . I am at a complete loss as to why this would happen. any ideas are welcome!
I also notice that you have no fly back diodes on those motors, this will generate a lot of interference for every step you take. Try running this without the motors connected to see if that cures the problem.
Note if it does then each motor will need four diodes.
Thanks for the feedback - in this case the flyback diodes are not required as the motor is a very low current gauge pointer. This is not the core issue however as currently the H bridge is not populated, scope is taken from GPIO output that is currently on open pins.
But your diagram has not enough resolution, zoom in and see it is one indistinguishable blob and another. So it was a valid comment.
Anyway your code is not using the chip select correctly so that it would work with an SPI chip select. You should set one chip select HIGH, and the other to LOW and then call the mcp.digital write function which writes to the MCP23S17, and when that operation is complete, put the LOW one HIGH again, before any other operation.
It doesn't help that you have such bland none descriptive names for your output pins. 4, 5, 6 & 7 it connives little meaning, especially as your schematic doesn't extend to your processor.
Apologies that the diagram is small. Trying a new capture of the signals with SPI included below.
This is hard to read, but the left side is actually correct GPIO behavior! I hit a power cycle in the middle and the right side is the corrupted behavior. Looks like SPI communication is corrupted after power cycle. Now of course, multiple power cycles will not result in correct restoration of correct operation.
(PS clock probe popped off during power cycle which is why its missing)
Resolved! For anyone who has this issue - with 2 chips on the SPI bus, the code did not have the CS line for the 2nd chip pulled high, which left it in an unknown state, and unstable. Pulling CS line high fixed the issue.
Great.
Now mark the post as solved with my post #6 as the solution. This is because it gave you the vital information you needed in order for you to find that your software was not putting the CS line high.
