SC16IS752 overlay question

[sdmill]

Hello,

New guy here and I apologize in advance if I'm breaking etiquette. I submitted this to a prior thread (https://www.raspberrypi.org/forums/view ... x&start=50), but this strikes me as a slightly different problem and so I'm starting a new one. My issue is related to the SC16IS752 expansion hat. I'm trying to construct a simple device to test upwards of 17 serial connections quickly and thought the SC16IS752 would be the answer. I've read every thread I can find on the topic and while no doubt a ton of things have been ironed out I haven't found a solution to this particular hiccup.

My setup - Pi Zero W w/ full Buster update + rpi update. I have two SC16IS752 expansion hats currently. The two hats are addressed for 0x48 and 0x49. The additional serial ports appear in 'ls /dev/ttySC*' as ttySC0-3. They are enabled via the overlay entry of 'dtoverlay=sc16is752-i2c,int_pin=XX,addr=0xXX', where my int_pins used are 23 and 24. When running a 'i2cdetect -y 1' they both appear as UU in their respective columns. No other I2C device is attached.

The problem - full functionality follows which ever overlay is assigned int_pin=24. While I can Tx on the other board, (as checked by sending messages to the AMA0 port), I cannot receive anything. While looking at the signal with a meter, I can see the IRQ leg is high when I do not have a terminal open watching it. As soon as I establish a miniterm or puTTY session, the IRQ falls low and stays low. Through a fluke occurrence I noticed that if I apply and disconnect a load to the Pi's 5v bus I can inadvertently trigger the IRQ to go high which causes messages to appear, but then the IRQ goes back low a moment later and I'm back to where I was. I ran a 'gpio readall' to get a list of default low pins and have tried several with no success. As I mentioned earlier, I can move int_pin=24 between 0x48 and 0x49 and which ever board has it, works perfectly so I don't feel like its a hardware issue.

Any help with this would be greatly appreciated. Thank you!

[PhilE]

I don't understand why GPIO23 would behave any differently than GPIO24. What I can see is that the overlay doesn't change the pin properties, so both GPIOs will have a pull down - not ideal for an active low (falling edge) IRQ. If the the pin is permanently low, whether or not the device is driving it low, there will never be an edge so you'll never get an interrupt.

1. Confirm the pin states with "raspi-gpio get 23,24". You can try with and without the HAT connected.
2. Add the following to config.txt:

Code: Select all

gpio=23,24=ip,pu

Reboot and re-run 1 to confirm that the change has worked.
3. See if the interrupt behaviour has changed.

There was a user with similar-sounding setup on GitHub (https://github.com/raspberrypi/linux/is ... -555119872) who eventually tracked his problem down to a power-up sequencing issue.

[sdmill]

Hello,

After making the change to config.txt, raspi-gpio get shows:

GPIO 23: level=1 fsel=0 func=INPUT
GPIO 24: level=1 fsel=0 func=INPUT

No change to performance though. The overlay assigned 24 continues to Tx/Rx successfully while the other does not receive. I read through thread you provided, I don't have a means to replicate it at the moment but will give it a shot as soon as I can. Does there happen to be a manual way of cycling the 3.3v GPIO pin that's powering these things?

[PhilE]

As far as I know the Pi Zero W has a fixed DC->DC converter for 3V3 and 1V8, and the only way to toggle them is to remove 5V.