We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

spidev fails



  • Hello Everyone,

    I am trying to run SPI half-duplex for my gateway(LORA) and when I run (Spi_test) utility of gateway it shows some random data read and when I connect it to USB analyzer it works as expected.it shows all data read on MOSI is correct. but in software it is not as expected. and when I run same SPI utility with Raspberry pi it works perfectly.
    kindly help me.

    Regards


  • administrators

    @rahul2413 You'll need to double-check that the program is actually using half-duplex SPI. Some programs have a full duplex vs half duplex switch.

    Another option to explore:
    Since LoRa radios have a pretty low datarate, you can also get away with using a software-based SPI bus. More info in this FAQ post.



  • I double checked it. its half duplex communication and same happens with python spidev .when I try to read single register value using xfer3 function it is reading 0x00 and it should be 0x12 but when i run it on raspberry pi using same function it gives the result and when i checked it on usb analyser with onion it shows that it reads 0x12.but not in same index but in [index-1] so when i try to read previous index using xfer3 it reads correctly.

    e.g.
    spi.max_speed_hz = 1000000
    spi.mode = 0b00
    spi.open(0, 1)
    addr=0x5600+6
    (its five byte transmit)
    readVals = spi.xfer3([0x00,(0x00 | ((addr >>8) & 0x7F)),((addr >> 0) &0xFF),0x00,0x00],2) when i try to read using this it gives 0x00. and in rpi it gives result as expected.

    (its four byte transmit)
    readVals = spi.xfer3([0x00,(0x00 | ((addr >>8) & 0x7F)),((addr >> 0) &0xFF),0x00],2)
    this gives result 0x12.

    but according to datasheet of lora IC five byte transmit is the way its given..


  • administrators

    @rahul2413 said in spidev fails:

    but not in same index but in [index-1] so when i try to read previous index using xfer3 it reads correctly.

    Sorry, I'm a little confused. Does this resolve your issue?



  • no its not solved I am just reading the single register value of lora chip using python spidev by modified some bytes but I have to run this application on C language that is not working because full stack of lora gateway is available on C language so that's why I want run it. i want to know that if there is some problem in spidev.



  • I'm curious: How did you check that it is using half-duplex?
    Full-duplex on anything with a Mediatek-7688 MCU won't work due to a silicon bug.
    You can simulate full duplex by using two SPI transactions, a write, followed by a read, without dropping the CS line inbetween.

    I use SPI from C++ on My Oemags S2+ without any problems. (In half-duplex!)



  • @SpiderKenny

    I am sharing code can you tell me whats wrong with it. this similar code works with raspberry pi.

    #define READ_ACCESS 0x00
    #define WRITE_ACCESS 0x80
    #define LGW_SPI_MUX_TARGET_SX1302 0x0000
    #define SX1302_REG_COMMON 0x5600
    my spi is spidev 0.1

    //Function to Read Register for chip version...

    x = lgw_spi_r(LGW_COM_SPI,LGW_SPI_MUX_TARGET_SX1302, SX1302_REG_COMMON + 6, &data);
    if (x != 0) {
        printf("ERROR (%d): failed to read register\n", __LINE__);
        exit_failure();
    }
    printf("SX1302 version: 0x%02X\n", data);
    

    int lgw_spi_r(void *com_target, uint8_t spi_mux_target, uint16_t address, uint8_t *data) {
    int spi_device;
    uint8_t out_buf[5];
    uint8_t command_size;
    uint8_t in_buf[ARRAY_SIZE(out_buf)];
    struct spi_ioc_transfer k;
    int a;

    /* check input variables */
    CHECK_NULL(com_target);
    CHECK_NULL(data);
    
    spi_device = *(int *)com_target; /* must check that com_target is not null beforehand*/
    
    /* prepare frame to be sent */
    out_buf[0] = spi_mux_target;   //spi_mux_target 0x00
    out_buf[1] = READ_ACCESS | ((address >> 8) & 0x7F);    //addrress=0x5600 //READ_ACCESS = 0x00
    
    out_buf[2] =  ((address >> 0) & 0xFF);
    out_buf[3] = 0x00;
    out_buf[4] = 0x00;
    command_size = 5;
    
    /* I/O transaction */
    memset(&k, 0, sizeof(k)); /* clear k */
    k.tx_buf = (unsigned long) out_buf;
    k.rx_buf = (unsigned long) in_buf;
    k.len = command_size;
    k.cs_change = 0;
    a = ioctl(spi_device, SPI_IOC_MESSAGE(1), &k);
    
    /* determine return code */
    if (a != (int)k.len) {
        DEBUG_MSG("ERROR: SPI READ FAILURE\n");
        return LGW_SPI_ERROR;
    } else {
        DEBUG_MSG("Note: SPI read success\n");
        *data = in_buf[command_size - 1];
        return LGW_SPI_SUCCESS;
    }
    

    }

    the output is "SX1302 version: 0x00" output should be 0x12
    I am also sharing datasheet information

    IScreenshot (9).png

    it will work on onion omega 2s+ or not


  • administrators

    @rahul2413 said in spidev fails:

    I am just reading the single register value of lora chip using python spidev by modified some bytes

    Since the python spidev module correctly reads the register, we can conclude the Omega2 is able to communicate with your lora radio module and there is no show-stopping issue in spidev.

    If the python spidev half-duplex transmission worked, and the C program doesn't work, I think it's safe to assume the C program is using full-duplex.

    Again, my recommendations are:

    1. Look at the C code to see if there's a flag or switch for full duplex vs half duplex
    2. Consider using a software-based SPI bus to communicate with the lora module. More info in this FAQ post.

    One more thing:

    @rahul2413 said in spidev fails:

    I am sharing code can you tell me whats wrong with it.

    This is a very large ask for a community forum. In my experience, the best way to resolve and debug technical issues on a forum is through collaboration rather than throwing the whole problem at another user. Please keep that in mind šŸ™‚



  • sorry for this

    but in python spidev its not working as it should be i have to change sending bytes .but in raspberry pi its working without any change. and according to documents of lora chip its half-duplex.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.