1. Hardware & Machines
  3. Driver Boards
  5. Mesa 7i90 in SPI mode

Mesa 7i90 in SPI mode

More
21 Mar 2016 22:50 #72000 by jepler
Replied by jepler on topic Mesa 7i90 in SPI mode 
if (spi_read(&(board->llio), HM2_COOKIE_REG, &buf, sizeof(buf)) < 0) {
        return;
    }
    
    if(memcmp(buf, cookie, sizeof(cookie))) {
        fprintf(stderr, "Unexpected cookie at 0000..000c:\n%08x %08x %08x\n",
            buf[0], buf[1], buf[2]);
        return;
    }

mesaflash is trying to read the cookie at the normal location (HM2_COOKIE_REG is 0x0100), just the message is incorrect about what location it tried to read. The expected value of the cookie is
u32 cookie[] = {0x55aacafe, 0x54534f48, 0x32544f4d};

It looks like two independent users of spidev are both reading all zeroes instead of the expected value (hm2_spi and mesaflash do not share any source code, though I think I wrote both sets of code), so I would look at the kernel driver or the wiring as the source of the problem.

There are spidev test programs out there and you can just loop the output back to the input to see whether the kernel driver and hardware are working properly. I'd do that before continuing with mesaflash or linuxcnc, just so you know the odroid's spi hardware and the kernel driver are working like you expect
The following user(s) said Thank You: kaklik

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 10:32 - 22 Mar 2016 11:08 #72009 by kaklik
Replied by kaklik on topic Mesa 7i90 in SPI mode
I tested the SPI by looping the master SPI IN and OUT signals as jepler suggested. Then I noticed the 7i90 SPI output always responds by the same word as in case where SPI IN is connected to the ODROID's master SPI or not..

The data word responded is 0xAAAAAAAA as is mentioned in hm2_spi.c source. Therefore I expect the root of the problem is in fact that 7i90 board do not understand to the SPI data sent by ODROID.

Copy of hm2_spi.c source code. where the A code is expected? - I do not understand this code well.
    // because linux manages SPI chip select behind our backs, we can't know
    // whether to expect the "AAAAAAAA" cookie to appear in the first
    // word of the response.  that's too bad, because checking this
    // would give a minimum level of detection of gross problems such as
    // a disconnected cable.
    uint32_t *buf = this->trxbuf;
    uint32_t **scatter = this->scatter;
    int i=0;
    for(i=0; i<this->nbuf; i++) {
        uint32_t *target = scatter[i];
        if(target) *target = buf[i];
    }

    this->nbuf = 0;
    return 1;
}

But If I look on the SPI IN signal (At the 7i90 board side with using the 7i90 board ground) The data signal looks fine without any significant signal integrity failures. The oscilloscope image follows. The blue line is SPI data IN (MASTER output) and yellow line is SPI clock signal..



Have you some suggestion what other signal parameters may affect the SPI transmission and could be different from Jeff Epler ODROID-U3 setup? The TXB0104 voltage level translator used in case of ODROID-U3 is non-inverting. Therefore the signal polarity must be the same as in case of direct signal connection between ODROID-C1 and 7i90 board.
Attachments:
Last edit: 22 Mar 2016 11:08 by kaklik.

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 12:16 #72013 by jepler
Replied by jepler on topic Mesa 7i90 in SPI mode
Without fully refreshing my memory, the 7i90 will echo AAAAAAAA for the first dummy data under some condition. The comment implies it has to do with the /CS signal but the source says
if (FrameTimerMSB = '1') and (FrameTimerMSBD = '0') then    -- always set header on frame timeout
         SPIHeader <= '1';             -- async set header
         SPIRegOut <= x"AAAAAAAA";
      end if;
so the comment is just saying that that whatever the specific condition was, I couldn't figure out a way to use it for a basic "is device connected" test in the hm2_spi driver.

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 15:12 - 22 Mar 2016 16:13 #72032 by PCW
Replied by PCW on topic Mesa 7i90 in SPI mode
The AAAAAAAA is transmitted when there has been a frame timeout (SPI master idle for more than 50 usec) so can be used for detecting the card as long as you guarantee 50 usec of idle time before checking

The SPI "data in" looks bogus in your scope plot, you would expect the first doubleword of a burst
to have a 0xA or 0xB (read or write) command, but it does not (32/64 bit issue?)
Last edit: 22 Mar 2016 16:13 by PCW.

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 16:33 #72039 by kaklik
Replied by kaklik on topic Mesa 7i90 in SPI mode
OK, it looks like a problem with 32bit block write on ODROID-C1 SPI interface.
What is correct frame which should be send to the 7i90 board to get correct cookie response ? eg. {0x55aacafe, 0x54534f48, 0x32544f4d}

I do not know how could be possible to make trouble to odroid to realize 32bit transfers. Because according my understanding of hm2_spi.c driver github.com/LinuxCNC/linuxcnc/blob/master...stmot2/hm2_spi.c#L92
The data are sent per bytes.

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 16:37 #72040 by jepler
Replied by jepler on topic Mesa 7i90 in SPI mode
I think ODROID-C1 is 32-bit so it's probably not a 64/32 issue (the recent -C2 is 64-bit if I'm not mistaken). armhf is same endian as x86, so it shouldn't be an endian issue, and if it was it should have turned up on my U3 (though in general hostmot2 is riddled with lack of attention to endianness and probably only works properly on little-endian systems)

We make the following settings via ioctl, checking the result for an error at each step:
    int r = spidev_set_lsb_first(fd, false);
    if(r < 0) goto fail_errno;

    r = spidev_set_mode(fd, 0);
    if(r < 0) goto fail_errno;

    r = spidev_set_bits_per_word(fd, 32);
    if(r < 0) goto fail_errno;

    r = spidev_set_max_speed_hz(fd, rate);
    if(r < 0) goto fail_errno;

spidev_set_mode(0) sets SPI_MODE_0, aka SPI_CPHA=0, SPI_CPOL=0.

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 18:21 #72044 by PCW
Replied by PCW on topic Mesa 7i90 in SPI mode
To just read the cookie you would send:
0x0100A010 0x00000000 ( read one doubleword starting at 0x0100 hex )
To read the cookie and the hostmot2 name you would send:
0x0100A830 0x00000000 0x00000000 0x00000000 (read 3 doublewords starting at 0x0100 with autoinc)

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 18:48 #72046 by jepler
Replied by jepler on topic Mesa 7i90 in SPI mode
it should be possible to tell linux the transfer mode is 8-bit but always send a multiple of 4 bytes. As long as linux keeps /CS asserted the whole transfer, I don't think the slave really can tell the difference. I'm not sure what all changes would be needed (how does this affect the order of the bytes in memory vs order of bits on the wire), but I'll be happy to review any proposed change and test it on my U3. If 32-bit transfers really are unsupported, it's a pity that the ioctl() to set the 32-bit transfer width doesn't fail!

Please Log in or Create an account to join the conversation.

More
22 Mar 2016 19:20 #72049 by PCW
Replied by PCW on topic Mesa 7i90 in SPI mode
Yeah looks like the SPI driver and/or hardware has bolluxed up the 32 bit sends
(the hardware sends a burst of 32 clocks correctly but the data is busted)

Please Log in or Create an account to join the conversation.

More
24 Mar 2016 13:50 #72090 by kaklik
Replied by kaklik on topic Mesa 7i90 in SPI mode
Yes, I it is ODROID-C1 spi issue..

I borrowed the OROID-U3 and run the mesaflash uitility on it.. The result is here:


Attachments:

Please Log in or Create an account to join the conversation.

Moderators: PCW, jmelson
  1. Hardware & Machines
  3. Driver Boards
  5. Mesa 7i90 in SPI mode
Time to create page: 0.133 seconds
Powered by Kunena Forum