This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM437x IDK EVM SPI loop-back test

Other Parts Discussed in Thread: TPS62360, AM4372

Dear all,  

We have bought a AM437x IDK board, and now do SPI loop-test, when use spidev_test , got all the RX value is zero, Could you kindly help to have a look for this. Thanks very much. 

Use SDK : "ti-processor-sdk-linux-am437x-evm-02.00.01.07"

Configuration as below:

spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
0x150 (PIN_INPUT | MUX_MODE0) /* spi0_clk.spi0_clk */
0x154 (PIN_OUTPUT | MUX_MODE0) /* spi0_d0.spi0_d0 */
0x158 (PIN_INPUT | MUX_MODE0) /* spi0_d1.spi0_d1 */
0x15C (PIN_OUTPUT | MUX_MODE0) /* spi0_cs0.spi0_cs0 */
>;
};

&spi0 {
pinctrl-0 = <&spi0_pins>;
status = "okay";

spidev@0 {
compatible = "rohm,dh2228fv";
spi-max-frequency = <24000000>;
reg = <0>;
};
};

Below is test result:

root@am437x-evm:/home# ./spidev_test -D /dev/spidev1.0 -v
[ 98.211555] spidev spi1.0: not using DMA for McSPI
[ 98.216689] spidev spi1.0: not using DMA for McSPI
[ 98.222734] spidev spi1.0: not using DMA for McSPI
spi mode: 0x0
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 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................................

  • Hi,

    The spi configuration in linux kernel is correct. And seeing the log you provide the spi0 device is working.
    Do you have anything connected to SPI0? I'm getting similar results if I run spidev_test on my BBB and don't have anything connected to the spi pins.

    Best Regards,
    Yordan
  • Hi Yordan,
    Thanks very much for your quickly response.

    I short spi0_d0 and spi0_d1 to do loopback. Is anything I missing?

    thanks.
  • Hi,

    Do you call the spidev_test with the -l option, so that you can configure the spidev_test loopback? If not, then the spi will do a write operation of predefined bytes & then a sequential read operation.

    Best Regards,
    Yordan
  • Hi Yordan,

    When call spidev_test with the -l option, I encounter below error message:

    "setup: unsupported mode bits" in driver/spi.c

    So i do following modification in file driver/spi-omap2-mcspi.c

    /* the spi->mode bits understood by this driver: */

    from:

    master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH; 

    to:
    master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP;

    and re-compiler the kernel.

    Then can run with -l option, but result is the same failure.

    Could you help to give more suggestion?

  • This is log with -l option:

    Below is test result:

    root@am437x-evm:/home# ./spidev_test -D /dev/spidev1.0 -v -l
    [ 98.211555] spidev spi1.0: not using DMA for McSPI
    [ 98.216689] spidev spi1.0: not using DMA for McSPI
    [ 98.222734] spidev spi1.0: not using DMA for McSPI
    spi mode: 0x0
    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 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................................
  • sorry ignore above log, see below logs:

    root@am437x-evm:/home# ./spidev_test -D /dev/spidev1.0 -v -l
    [ 98.211555] spidev spi1.0: not using DMA for McSPI
    [ 98.216689] spidev spi1.0: not using DMA for McSPI
    [ 98.222734] spidev spi1.0: not using DMA for McSPI
    spi mode: 0x20
    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 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................................
  • Hi Yordan,

    I have the same issue on AM437x IDK EVM.
    My setting is same as Lindar.
    I've probed the J16_pin24, J16_pin26, J16_pin28 and J16_pin30 on IDK EVM.
    All of them are always high (3.3V) even I use the command "./spidev_test -D /dev/spidev1.0 -l" try to do the loopback test.

    • What loopback mode is "./spidev_test -D /dev/spidev1.0 -l" command used? External or internal?
    • I think the transmitted data is internally transferred to the corresponding receive buffer while using internal loop back mode, so we can't probe any data form scope. Is that correct?

    I tried to use "devmem2" command to get the SPI0 memory information and get the following error message:


    root@am437x-evm:/opt/ltp/testcases/bin/ddt# devmem2 0x4803000
    /dev/mem opened.[ 777.068130] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6fc7000
    [ 777.077042] pgd = ee0bc000
    [ 777.079761] [b6fc7000] *pgd=ae349831, *pte=04803303, *ppte=04803a33
    [ 777.086109] ------------[ cut here ]------------
    [ 777.090771] WARNING: CPU: 0 PID: 830 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x21c/0x348()
    [ 777.100296] 44000000.ocp:L3 Standard Error: MASTER M2 (64-bit) TARGET GPMC (Read Link): At Address: 0x04803000 : Data Access in User mode during Functional access
    [ 777.114874] Modules linked in: ipv6 evdev pm33xx gpio_keys tps62360_regulator omapdrm_pvr(O) dwc3_omap extcon omap_rng cryptodev(O) rng_core spi_ti_qspi rtc_omap omap_wdt
    [ 777.130291] CPU: 0 PID: 830 Comm: devmem2 Tainted: G W O 4.1.13-g8dc6617 #5
    [ 777.138243] Hardware name: Generic AM43 (Flattened Device Tree)
    [ 777.144187] Backtrace:
    [ 777.146676] [<c0012b78>] (dump_backtrace) from [<c0012d98>] (show_stack+0x18/0x1c)
    [ 777.154280] r7:c07eda68 r6:00000093 r5:00000009 r4:00000000
    [ 777.160011] [<c0012d80>] (show_stack) from [<c06478cc>] (dump_stack+0x20/0x28)
    [ 777.167282] [<c06478ac>] (dump_stack) from [<c0039e94>] (warn_slowpath_common+0x7c/0xb4)
    [ 777.175417] [<c0039e18>] (warn_slowpath_common) from [<c0039f04>] (warn_slowpath_fmt+0x38/0x40)
    [ 777.184151] r8:c07edb40 r7:00000004 r6:ee8dd490 r5:c07ed988 r4:c07eda38
    [ 777.190936] [<c0039ed0>] (warn_slowpath_fmt) from [<c030e984>] (l3_interrupt_handler+0x21c/0x348)
    [ 777.199845] r3:ee8dd280 r2:c07eda38
    [ 777.203450] r4:80080001
    [ 777.206015] [<c030e768>] (l3_interrupt_handler) from [<c006c6d4>] (handle_irq_event_percpu+0x7c/0x148)
    [ 777.215360] r10:c08ff45b r9:ee8d9840 r8:00000013 r7:00000000 r6:00000000 r5:ee8dd800
    [ 777.223268] r4:ee8dd800
    [ 777.225827] [<c006c658>] (handle_irq_event_percpu) from [<c006c808>] (handle_irq_event+0x68/0x90)
    [ 777.234736] r10:be9ceb04 r9:eebcc000 r8:ee808000 r7:00000001 r6:00000000 r5:ee8dd800
    [ 777.242643] r4:ee8d9840
    [ 777.245205] [<c006c7a0>] (handle_irq_event) from [<c006f1a0>] (handle_fasteoi_irq+0xb8/0x1ec)
    [ 777.253766] r5:c08c3480 r4:ee8d9840
    [ 777.257381] [<c006f0e8>] (handle_fasteoi_irq) from [<c006bdfc>] (generic_handle_irq+0x30/0x44)
    [ 777.266030] r5:c08d736c r4:00000013
    [ 777.269644] [<c006bdcc>] (generic_handle_irq) from [<c006c05c>] (__handle_domain_irq+0x50/0xb0)
    [ 777.278379] r5:c08d736c r4:00000013
    [ 777.281994] [<c006c00c>] (__handle_domain_irq) from [<c00094b4>] (gic_handle_irq+0x28/0x60)
    [ 777.290380] r9:eebcc000 r8:00000000 r7:fa240100 r6:c08be48c r5:eebcdf48 r4:fa24010c
    [ 777.298213] [<c000948c>] (gic_handle_irq) from [<c064cdc0>] (__irq_svc+0x40/0x74)
    [ 777.305730] Exception stack(0xeebcdf48 to 0xeebcdf90)
    [ 777.310808] df40: eebcdfb0 00000001 00000000 600b0010 eebcc000 00000000
    [ 777.319028] df60: eebcdfb0 10c5387d 00000000 eebcc000 be9ceb04 eebcdfac eebcdfb0 eebcdf90
    [ 777.327243] df80: c000f92c c00127e0 600b0113 ffffffff
    [ 777.332314] r7:eebcdf7c r6:ffffffff r5:600b0113 r4:c00127e0
    [ 777.338043] [<c0012790>] (do_work_pending) from [<c000f92c>] (work_pending+0xc/0x20)
    [ 777.345819] r7:10c5387d r6:ffffffff r5:600b0010 r4:00010854
    [ 777.351536] ---[ end trace 94b3fddd408ea4f0 ]---

    Memory mapped at address 0xb6fc7000.
    Bus error

    • Is there any think that we can do to remove this issue?

    Best Regards,
    Wayne Kuo

  • Hi Yordan,

    I refer to AM335x's SPI device tree setting to setup AM437x IDK SPI0 port.
    I use omap2-mcspi driver to replace the omap4-mcspi in am4372.dtsi file, then I got somethinng on my RX data.

    spi0: spi@48030000 {
    compatible = "ti,am4372-mcspi","ti,omap2-mcspi";
    reg = <0x48030000 0x400>;
    interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
    ti,hwmods = "spi0";
    #address-cells = <1>;
    #size-cells = <0>;
    status = "disabled";
    };

    However, the RX data is not the same as TX data and there is a error message " spidev spi1.0: TXS timed out ".
    Do you have any idea for this?
    Here is my test log:
    root@am437x-evm:~# ./spidev_test -D /dev/spidev1.0 -v -l
    [ 70.337797] spidev spi1.0: not using DMA for McSPI
    [ 70.342910] spidev spi1.0: not using DMA for McSPI
    [ 70.347781] spidev spi1.0: not using DMA for McSPI
    spi mode: 0x20
    bits per word: 8
    max speed: 500000 Hz (500 KHz)
    [ 71.362342] spidev spi1.0: TXS timed out
    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 | 00 80 64 ED 09 2F B7 BE 00 00 00 00 00 00 00 00 2F 76 61 72 2F 6C 6F 67 2F 6D 65 73 73 61 67 65 | .d?/溝......../var/log/message

    Thank you and Regards,
    Wayne Kuo