spidev0.0 on RevPi Connect+ does not transmit and receive the same information

[mochdiprasetya]

Hi Everyone,

I am trying to connect an external SPI sensor on the ConBridge. The spidev0.0 is detected on the device list.

Here is the "/boot/config.txt"

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
dtoverlay=revpi-connect
dtparam=eth0_mac_hi=0xc83ea701
dtparam=eth0_mac_lo=0x93be
dtparam=eth1_mac_hi=0xc83ea701
dtparam=eth1_mac_lo=0x93bf

Here is the "sudo fdtdump /sys/firmware/fdt"

Code: Select all

spi@7e204000 {
            compatible = "brcm,bcm2835-spi";
            reg = <0x7e204000 0x00000200>;
            interrupts = <0x00000002 0x00000016>;
            clocks = <0x00000003 0x00000014>;
            dmas = <0x00000008 0x00000006 0x00000008 0x00000007>;
            dma-names = "tx", "rx";
            #address-cells = <0x00000001>;
            #size-cells = <0x00000000>;
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <0x0000000b 0x0000000c>;
            cs-gpios = <0x0000000d 0x00000024 0x00000001 0x0000000d 0x00000023 0x00000001>;
            phandle = <0x00000021>;
            ethernet@1 {
                phandle = <0x0000007b>;
                status = "okay";
                reset-gpios = <0x0000000d 0x00000028 0x00000001>;
                interrupts = <0x00000008 0x00000008>;
                #interrupt-cells = <0x00000002>;
                interrupt-parent = <0x0000000d>;
                spi-max-frequency = <0x00989680>;
                reg = <0x00000001>;
                compatible = "micrel,ks8851";
            };
            spidev@0 {
                compatible = "spidev";
                reg = <0x00000000>;
                #address-cells = <0x00000001>;
                #size-cells = <0x00000000>;
                spi-max-frequency = <0x07735940>;
                phandle = <0x0000005d>;
            };
            spidev@1 {
                status = "disabled";
                compatible = "spidev";
                reg = <0x00000001>;
                #address-cells = <0x00000001>;
                #size-cells = <0x00000000>;
                spi-max-frequency = <0x07735940>;
                phandle = <0x0000005e>;
            };
        };

Here is the "/etc/modules"

Code: Select all

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

i2c-dev
piControl
spidev

When I tried to run this code : https://github.com/rm-hull/spidev-test
The TX is not the same as RX. I attached ADXL345 on MISO and MOSI.
I have tried it on normal Raspberrypi 4, it transmitted and received the same.
Here what I got on the spidev_test.c on RevPI Connect+

Code: Select all

spi mode: 0x4
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  |......@.........................|
RX | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  |................................|

Am I missing something?

Thank you everyone.

[RR4711]

I have tried it on normal Raspberrypi 4, it transmitted and received the same.

You mean if you directly connect MISO and MOSI as a loopback test you don't receive the same on the RevPi but on the Raspi 4?

[mochdiprasetya]

You mean if you directly connect MISO and MOSI as a loopback test you don't receive the same on the RevPi but on the Raspi 4?

Yes that is what I mean. The TX and the RX should have the same value, with the loopback connection. I tested both with ADXL345
Or is there any way to test the spi on RevPi Connect+?

[RR4711]

Is the CAN driver loaded? There is an option to load the driver for the "CON-CAN" module in the web interface. That's the only thing that I would think may influence the SPI device.

I have an FPGA connected to the SPI bus that acts as SPI Slave and communication works flawless for me for now.

[lukas]

The Con CAN option in webstatus merely loads a devicetree overlay which instantiates the CAN slave below the SPI master (and sets the status of the spidev slave to "disabled").

This looks like the RX line is pulled high. I'd suggest to double-check the wiring and verify whether the correct pins on the Con Bridge are used.

[mochdiprasetya]

So, the Con CAN option is disabled for sure. The MISO line is always high. I already double checked the connection. MISO is on the 5th pin and MOSI is on the 7th pin. I count it based on this : https://revolution.kunbus.com/tutorials ... n-connect/

Here is the connection for the loopback test.


Still, I am getting the same result. I haven't checked it with an oscilloscope by the way.

[RR4711]

You are using the wrong pins. See my post here:

viewtopic.php?f=3&t=1798&p=6865#p6865

The Pins are labeled on my circuit board. From the REAR (== where the DIN rail is) the 4th PIN is MOSI and the 6th Pin is MISO.
You are shorting out #CE0 to CLK if I see it correctly.

(Sorry just saw the Pinout you linked to: KUNBUS starts their counting from the FRONT)
P.S. I'm not sure about Pin 9, for me this is not RESET but a GPIO pin (that may be used to RESET the CON CAN Module), I use it as Onewire Sensor Interface with the proper Overlay to read DS18B20 sensors)

Markus

[mochdiprasetya]

You are amazing. Now it is working.

The Pins are labeled on my circuit board. From the REAR (== where the DIN rail is) the 4th PIN is MOSI and the 6th Pin is MISO.
(Sorry just saw the Pinout you linked to: KUNBUS starts their counting from the FRONT)

Noted.

Thank you very much.