SC16IS752 Interrupt bug? #3340
Comments
|
Those devices, or rather that device driver, has been the source of many problems over the years. We've found and fixed a number of bugs, but we can't offer more than time-permitting support on third-party devices and driver software. The kernel log doesn't give any clue as to how much data was successfully delivered before the failure occurred. Please try systematically sending single bytes to each port individually and report the outcomes. One thing I do notices is that one of your IRQ GPIOs (6) naturally pulls high while the others (12, 13) pull low, and the overlay makes no attempt to set the pull states. Do you have any kind of external pull-ups? What does the datasheet say on the matter? After booting but before using the serial ports, try forcing the pulls to a consistent state on all three GPIOs using raspi-gpio: or: Does that change the behaviour? |
|
Hi pellwell, What do you mean with sending single bytes to each port? Physically on the uart side? |
|
Please try watching the state of the IRQ lines using raspi-gpio while you try starting one of the interfaces: You can adjust the sleep time (in seconds) to watch with finer granularity. Before initialising the UART all three should be high, then afterwards I would expect no more than one to go low, and only momentarilty so. If you don't see any of the lines flicker, try removing the sleep and logging to a file. You could also install Joan's PiScope (http://abyz.me.uk/rpi/pigpio/piscope.html) - I've not tried it myself, but it looks like it could be useful here if you don't have any other kind of logic analyser or oscilloscope. |
|
I have done this. All Interrupt GPIO are all the Time high!
All Intterupt GPIO´s high before and after I configurate a UART Interface....
|
|
The scope will definitely tell you more (and more accurately). Start with the IRQ lines, then we can take it from there. |
|
The Interrupt works correct. |
|
If I start the Pi together with the SC16IS752 it does not work. If I start the Pi and then Power up the SC16IS752 all works fine. The SC16IS752 seems to need the I2C runs before it starts... |
|
By the way I think it´s an issue that all devices displayed as configurated and recognized: Thank´s for your Help!!! |
|
Hi I'm hoping this is the correct spot for this question. I'd like to re-open this issue/look into this issue as I'm experiencing exactly the same problem as Thomas-GeDaD did, but with only x2 devices (SC16IS752). I find that individually (i.e only one overlay enabled at a time in config.txt), each of the two devices work as expected, yet when I enable both overlays neither of them works (not TX or RX). works: works: does not work: I have 1k pullups on the interrupt pins. Both devices seem to initialise correctly as I'm seeing "UU" at both addresses using i2cdetect. I have other hardware on the bus too as you can see below, yet they have been behaving just fine. ls /dev yields the expected ttySC0, ttySC1, ttySC2, ttySC3 I have tried:
RPI model: 3b Any help/tips/ideas on this would be much appreciated! Overlays I'm using, with config.txt parameters as needed: config.txt Here is a dtc -Ifs /proc/device-tree > devicetree4.txt dump: |
|
Your system is showing its age.
|
|
This is what i add to the boot config and it works fine since the fix in all versions until now: |
|
Thanks for contributing, Thomas - which kernel are you running? |
|
Hi Pelwell and Thomas, thanks for the advice, I was bit hesitant to update the OS as I have a lot of pre-configured/installed python modules that I use. It would take quite a bit of time setting that all up again. But being on buster it appears that I can update to bullseye (5.10) using these steps without having to start from scratch: https://www.tomshardware.com/how-to/upgrade-raspberry-pi-os-to-bullseye-from-buster I have backups of my data, so should be good to go. Also, just to make sure, I'm using the SC16IS752 overlay from here: jason77-wang/eoan-rpi-pull@9bf908c Is this the correct one to use? It appears to be the most recent. So in summary, I will:
dtoverlay=sc16is752-i2c,int_pin=6,addr=0x48 Hopefully I get some joy out of these changes. |
|
Also Thomas, to get the three devices working for you, did you have to power up or reset the SC16IS752 devices after the RPI booted? Or did that not make a difference in the end? |
|
We use several Kernels. We sell the MCS in a shop and there are many >500 in the market. I have nerver heard about an issue of the i2c-Serial interfaces, so i think it works on every Kernel version after this, old issue. |
|
Thanks for the updated feedback Thomas, that sounds good, I will give it a try now that I know the 4.19.x seems to be the issue. |
|
no there was no issue with 4.19. This issue here was based on the sc16is752. The chip has a problem, when there is at first VDD before the i2c is availible. then you get an addressconflict when you use the scl/sda line for adressing the chip. I have change the addresses of the board so i dont need a i2c line for addressing. only use the VDD/gnd for the adresspins! |
|
But that's a bit strange as for that very reason I avoided using those addresses that use the SDA and SCL lines in the first place. So I'm also just using the VDD/GND for addressing (e.g 0x48, 0x4d, 0x4c etc), But still I'm experiencing this multiple device issue? Anyway I will update the OS first and let you know how it went. |
|
Thomas is correct in that you don't need to install any overlays - it is already present and verified to work. |
|
Thanks Pelwell, I take note of that. |
Uh oh!
There was an error while loading. Please reload this page.
I´m not sure if it is the right place for the Problem:
I use 3x SC16is752 devices on a Pi 4 with buster (4.19.75-v7l+ #1270)
All 3 devices works if I only use 1 or 2 of them:
In config.txt:
works:
works:
works:
with all configuration I get ttySC0-ttySC3 and can send an recieve data from a GPS (NMEA)
All works perfectly.
But If I use all three devices I get problems=>
After startup the Pi dmesg seems fine without any issue.
the devicetree:
and the i2c detect:
....... 0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU UU UU -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- `
I think all is fine.
But if I use one of the ttySC Port the following happened:
sudo stty 19200 -F /dev/ttySC0In dmesg:
At this time there are physical no data on the UART.
This passes infinitely until i restart.
The amazing think is, that this only happened if I use ttySC0,ttySC1,ttySC4,ttySC5
But It can not be a physical problem because all devices in two pairs or alone worked....
I think it´s a driver Issue?
Thanks....
The text was updated successfully, but these errors were encountered: