BBB Industrial: SPI CS Always high

Hi to all. I need help with SPI communication. The problem is that during a transaction, CS0 is always HIGH

I’m running Debian image for BeagleBone Black on-board eMMC flash Kernel: 5.10.168-ti-r71 U-Boot: v2022.04

Just added this line to uEnv.txt (no other changes)

uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo

Tried also to execute

config-pin p9_17 spi_cs
config-pin p9_18 spi
config-pin p9_21 spi
config-pin p9_22 spi_sclk

but this seems irrelevant.

Actually my code is just derived from classic spi example

    #define SPI_DEVICE_PATH "/dev/spidev0.1"

    // Open the SPI device
    if ((spi_file = open(SPI_DEVICE_PATH, O_RDWR)) < 0) {
        perror("Failed to open SPI device");
        return -1;
    }

    // Configure SPI mode and bits per word
    uint8_t mode = SPI_MODE_3;
    uint8_t bits = 8;
    if (ioctl(spi_file, SPI_IOC_WR_MODE, &mode) < 0) {
        perror("Failed to set SPI mode");
        close(spi_file);
        return -1;
    }
    if (ioctl(spi_file, SPI_IOC_WR_BITS_PER_WORD, &bits) < 0) {
        perror("Failed to set SPI bits per word");
        close(spi_file);
        return -1;
    }

    // Perform SPI transfer
    struct spi_ioc_transfer transfer = {
        .tx_buf = (unsigned long)tx_buffer,
        .rx_buf = (unsigned long)rx_buffer,
        .len = sizeof(tx_buffer),
        .delay_usecs = 0,
        .speed_hz = 1000000,  // SPI speed in Hz
        .bits_per_word = 8,
        .cs_change = 1,
    };

    if (ioctl(spi_file, SPI_IOC_MESSAGE(1), &transfer) < 0) {
        perror("Failed to perform SPI transfer");
        close(spi_file);
        return -1;
    }

I've no glue where the problem is. Everything is ok, but not the CS.

Can you manually toggle the cs pin using libgpiod commands?

You’re right; config-pin won’t do anything, so don’t worry about that.

I am however curious about other overlays loaded; how many do you have in total,
and what are they (in case you have any others) ?

Hi, here my uEnv.txt

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=5.10.168-ti-r71
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=BB-I2C2-00A0.dtbo
#uboot_overlay_addr1=<file1>.dtbo
#uboot_overlay_addr2=<file2>.dtbo
#uboot_overlay_addr3=<file3>.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo
#uboot_overlay_addr5=<file5>.dtbo
#uboot_overlay_addr6=<file6>.dtbo
#uboot_overlay_addr7=<file7>.dtbo
###
###Custom Cape
#dtb_overlay=<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

console=ttyS0,115200n8
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
#cmdline=init=/usr/sbin/init-beagle-flasher


Thx :wink:

Hi, I made some test with BBBiolib (McSPI) and CS is driven correctly. But the library doesn’t feet my requirements, so I would like to give a try to ioctl mode.

(in the scope image in OP, CS is the yellow one)

At first glance I don’t see any offenders.

Interesting. Did you study the source for that to see how they manage to wiggle the CS pin?

If you are referring to BBBiolib, it uses a low level approach, writes registers directly and does not work in user mode. I’ve had the BBB for a few days and to understand how it works you need to have in-depth knowledge of the AM3358 registry.

Can you see if it’s poking directly to the CS pin,
i.e. using it as a GPIO instead of letting the SPI device have direct control of it?
That could tell us if the PINMUX for it is in the wrong mode…

As an alternative, you could also consider using gpioinfo and gpioset duo to check
if you’re able to affect the CS pin with the overlay loaded (you shouldn’t).

Ok, Monday I will try to give you more information. I’m curios if I the only one with this problem. It seems really strange to me.

Thank you

Just for kicks, can you post the output of:
tree /proc/device-tree/chosen ?

Could be interesting to see exactly what you have loaded at the moment…

Just a supplementary question:

Are you actually using /dev/spidev0.1 as suggested by the code snippet in your first post?
(I hope not)

If so, please change to 0.0 instead; you might be trying to use CS1

This is what I see:

when I do a: ./spidev_test -D /dev/spidev0.0 -s 50000 -v on my BBGW.

1 Like

lranders, thank you for your effort. Running spidev_test seems to works fine with spidev0.0. But I was expecting that it was on 0.1 for pins 17,18,21,22. Anyway my programs doesn’t works neither with 0.0 (CS always low) nor 0.1 (CS always hi), so I’m doing some error. I’ll recheck everything.

Ok, found it. cs_change on struct spi_ioc works differently from what I’ve read (or I think I’ve read).

cs_change = 1 (leave CS low after the transaction)
cs_change = 0 (set CS Hi after the transaction, normal mode)

And yes, spidev0.0 must be used.

Thank you

Good to hear that you’re moving forward.

Could I trouble you to mark an answer as the solution,
so that we might consider the issue closed?

:+1: