Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

spurious low pulse on CS0 #113

Closed
MikeD2-mnb opened this issue Dec 21, 2020 · 28 comments
Closed

spurious low pulse on CS0 #113

MikeD2-mnb opened this issue Dec 21, 2020 · 28 comments

Comments

@MikeD2-mnb
Copy link

SPIDEV Ver 3.4
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
Running On raspberry pi B
I've found a very short spurious low pulse from CS0 (CS1 not checked) after sending 4 bytes of data using spi.xfer() function. Whilst this would not normally be a problem, this is setting communication alarms in the chip that I'm talking to. This second pulse is occurring after the CS line goes high, about 4 bytes later (equivalent time) .
How can this be eliminated?

spi = spidev.SpiDev()
spi.open(0,0)
spi.max_speed_hz = 1000000
spi.mode = 0

20201221_154602
Top trace shows the burst of the SCLK being 8 bits x 4 bytes, lower trace is the CE0 line, showing the second pulse which should not be there...
(FYI Horizontal is 20uS per div approximately. ) (old analogue scope...)
Mike
@MikeD2-mnb
Copy link
Author

Upgrading to spidev-3.5 did not fix this issue!

@jfernandz
Copy link

I'm having exactly the same problem

DS0002

Apparently it's a known behavior https://www.raspberrypi.org/forums/viewtopic.php?p=1781304#p1777594

@MikeD2-mnb
Copy link
Author

the function writedata() doesn't do this, so why should xfer()? (xfer2 & 3 also do this.
lines in the source code indicate that the author / maintainer are aware of the problem, and have tried to fix it:

// WA:
// in CS_HIGH mode CS isn't pulled to low after transfer, but after read
// reading 0 bytes doesnt matter but brings cs down
// tomdean:
// Stop generating an extra CS except in mode CS_HOGH
if (self->mode & SPI_CS_HIGH) status = read(self->fd, &rxbuf[0], 0);

@jfernandz
Copy link

@MikeD2-mnb what's actually the difference between xfer() and writedata()?

@semininja
Copy link

@jfernandz xfer() writes data and reads the response at the same time, while writedata() ignores the MISO line (returned data).

@Inbethath
Copy link

So - I had this issue as well @MikeD2-mnb

I've had to manually go into the spidev_module.c file and simply commented the if statement.

// WA:
// in CS_HIGH mode CS isn't pulled to low after transfer, but after read
// reading 0 bytes doesnt matter but brings cs down
// tomdean:
// Stop generating an extra CS except in mode CS_HOGH
// if (self->mode & SPI_CS_HIGH) status = read(self->fd, &rxbuf[0], 0);

Then I rebuilt it using pip install . directly from the source

I suspect it might've been a bug at some point so it was necessary for the driver to read 0 bytes. I'm unsure if it remains an issue but simply commenting that code fixed the issue for me and SPI seems to be working properly again.

For reference here's how it looks like now (I'm using a logic analyzer):
image

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Jan 2, 2021 via email

@MikeD2-mnb
Copy link
Author

Thanks MetaStasisa, This IS the fix, but needs to be applied in 3 places xfer, xfer2 and xfer3. The package can then be re-installed using "sudo python3 setup.py install|" from the directory with the source.

@Inbethath Inbethath mentioned this issue Feb 12, 2021
Closed
@fgr1986
Copy link

fgr1986 commented Feb 13, 2021

Hi, @MikeD2-mnb , @MetaStasisa
Will this patch be incorporated in the main branch in the future? or shall we re-patch with every release?

Thanks

@Inbethath
Copy link

Hey @fgr1986 ,

It appears that code was baked in due to a certain bug - I'm unsure if that bug has been resolved or not. Therefore, I haven't put in a pull request for these changes.

I think @doceme might be the best person to answer this if they're available.

Thanks,

Meta

@MikeD2-mnb
Copy link
Author

@fgr1968,
Until the maintainer of the code realises that the additional lines need commenting out again, the patch will have to be done by hand. As the code is stable at the moment - I haven;'t found any other bugs - I think that we are going to have to check for this bug after every update. So if you have an application where this is critical (I have 2) this will be a pain. Target slave devices SHOULD ignore stray chip enable pulses if there is no valid start condition, but particularly wit chips for the automotive industry, this seems not to be the case. Mike.

@antgraf antgraf mentioned this issue Aug 16, 2022
Closed
@antgraf
Copy link

antgraf commented Aug 16, 2022

I do confirm the same for xfer3(). I'd say it's a major bug which blocks a number of devices from operation. Such as ADS7066 from Texas Instruments.
See green signal:
pi

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

The extra read referenced in this issue has been disabled by default as of version 3.6 and can be re-enabled using the read0 flag for any platform that still requires it.

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

If you explicitly set the read0 flag to False before the transfer, are you still seeing the spurious low pulses on CS for BBB?

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

Sorry, I misunderstood. You're saying the problem exists in the Adafruit BBIO library, not py-spidev. Yes, that project has an unconditional read here and here that will have to be fixed in that project.

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

Version 3.6 was just released last night. You should be able to do: sudo pip install spidev --upgrade

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

Did you try with the --upgrade flag after pip install spidev? Yes, I was up late last night. 😴

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

Are you using a 64-bit kernel? What is the output of uname -a command?

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 3, 2022 via email

@doceme
Copy link
Owner

doceme commented Nov 3, 2022

I forgot to upload the source along with the binary when I released version 3.6 to PyPI, so piwheels didn't pick it up. I have since uploaded the source. Can you try pip install spidev --upgrade again?

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 4, 2022 via email

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Nov 4, 2022 via email

@MikeD2-mnb
Copy link
Author

MikeD2-mnb commented Jun 2, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@doceme @antgraf @jfernandz @fgr1986 @semininja @Inbethath @MikeD2-mnb