spurious low pulse on CS0

[MikeD2-mnb]

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

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]

Upgrading to spidev-3.5 did not fix this issue!

[jfernandz]

I'm having exactly the same problem

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

[MikeD2-mnb]

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]

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

[semininja]

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

[Inbethath]

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):

[MikeD2-mnb]

Thanks for the tip;

I did go look at the C code, but have been too busy with other things. I'll try this later, but it looks like the fix.

Mike. On 2/1/21 8:16 pm, MetaStasisa wrote:

So - I had this issue as well @MikeD2-mnb https://github.com/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 https://user-images.githubusercontent.com/34990678/103452720-8e844700-4c8f-11eb-8271-f4045c692c0d.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-753442161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI7TZWJPNTUJXWBXVXDSX3B5NANCNFSM4VDUZURQ.

[MikeD2-mnb]

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.

[fgr1986]

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]

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]

@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]

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:

[doceme]

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]

Hi Stephen,

Thanks, and the correction was appreciated.

However, this issue has cropped up on the Beagelbone black using Adafruit's BBIO.

Mike

On 04/11/2022 00:31, Stephen Caudle wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302030190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI3JGH3YHRVJCFOQCZTWGOWB3ANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[doceme]

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]

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]

Hi Stephen,

Just loaded SPIDEV on the beaglebone, and it has come in at version 3.5. I'll test this shortly to check for operation. How can I force the loading of 3.6?

Also, just looked up the spidev documentation; seen the readflag0 is on version3.6 only. I'm not sure what version my 2 remaining PI's are running.

regards,

Mike

On 04/11/2022 06:40, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302524502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TIYLDFHX3FUOUNYKVD3WGQBLRANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[doceme]

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

[MikeD2-mnb]

@.***:/var/lib/cloud9$ pip3 install spidev Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple Collecting spidev   Downloading https://www.piwheels.org/simple/spidev/spidev-3.5-cp37-cp37m-linux_armv7l.whl (40kB)     100% |████████████████████████████████| 40kB 54kB/s Installing collected packages: spidev Successfully installed spidev-3.5

Hi Stephen, FYI, the above is what the BBB is looking for, I see from the docs that spidev-3.6-cp39-cp39-linux_armv7l.whl is only 8 hours old!!

@.***:/var/lib/cloud9$ sudo pip3 install spidev==3.6 Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple Collecting spidev==3.6   Could not find a version that satisfies the requirement spidev==3.6 (from versions: 2.0, 3.0, 3.1, 3.2, 3.4, 3.5) No matching distribution found for spidev==3.6

can download v3.6-whl folder, but how to use this?

regards, Mike.

On 04/11/2022 06:40, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302524502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TIYLDFHX3FUOUNYKVD3WGQBLRANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[doceme]

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

[MikeD2-mnb]

Hi Stephen,

with --upgrade still comes in at v3.5

Mike.

On 04/11/2022 07:38, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302581696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI2BT7Y2W4FPVGYBMBTWGQID7ANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[MikeD2-mnb]

@.***:/var/lib/cloud9$ python3 -m pip install python/source/spidev-3.6-cp39-cp39-linux_armv7l.whl Defaulting to user installation because normal site-packages is not writeable Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple ERROR: spidev-3.6-cp39-cp39-linux_armv7l.whl is not a supported wheel on this platform.

!?!

never tried doing this before, so not sure if this is the correct way to do this.

regards,

Mike.

On 04/11/2022 07:38, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302581696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI2BT7Y2W4FPVGYBMBTWGQID7ANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[doceme]

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

[MikeD2-mnb]

@.***:/var/lib/cloud9$ uname -a Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

regards,

Mike

On 04/11/2022 07:55, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302596776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI4DJUKRKIDNPKZBE7TWGQKCHANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[doceme]

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]

Hi Stephen,

Finally got round to testing spidev 3.5 on the BBB, no spurious pulse is present. this also is true of spidev3.5 on the pi.

regards,

Mike.

On 04/11/2022 07:55, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302596776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI4DJUKRKIDNPKZBE7TWGQKCHANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[MikeD2-mnb]

Hi Stephen,

Also: spidev upgraded nicely to 3.6 this morning, and no spurious pulse on cs with read0 set to either True or False.

Thank you.

regards,

Mike.

On 04/11/2022 07:55, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302596776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI4DJUKRKIDNPKZBE7TWGQKCHANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>

[MikeD2-mnb]

Hi Stephen,

Just reaching out to see if you have any suggestions.

I'm trying to run some code using V3.4 of SPIDEV on a Beaglebone Green, under Venus OS ( a small os by Victron).

I get the following error:

spi.open(0,0) Traceback (most recent call last):   File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory

running ls on /dev directory, there are no spidev entries.

another Beaglebone (Black running debian) the spidev entries are in the /dev directory.

Any suggestions as to how to fix this are welcome.

regards,

Mike.

On 04/11/2022 07:04, Stephen Caudle wrote:

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

— Reply to this email directly, view it on GitHub https://github.com/doceme/py-spidev/issues/113#issuecomment-1302548174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO65TI2UN2XQTR7KYSLGMZLWGQEEHANCNFSM4VDUZURQ. You are receiving this because you were mentioned.Message ID: @.***>