The Loopback test only involves MISO and MOSI lines that leaves CS and CLK
as potential source of errors.
I have made some measurements with an oscilloscope and it shows two notable
differences between 4.4 and 3.8:
- For 3.8 CS toggles between high and low. For 4.4 CS is always low after
an sho
Hi,
I did some more testing on a 4.4.41-ti-r83 and a 3.8.13-ti-rxx.
I tested with the spi-test tool (I copied some version not used the one
shipped with the respective kernel) in loopback mode.
Interestingly this seems to work on both kernel versions while my board
only works with the 3.8 as exp
I just try to start the software from the board's supplier. The software is
known to work (tested myself) and on the mentioned kernels on the BBB.
So I think we can rule out the software part. When starting the software,
it cannot find/ connect to the board -- that's the "does not work case".
--
>
> Now I can use the board with its user space software (no kernel driver
> whatsoever involved).
> The setup *works* with 3.8 and 4.1 kernels but *not* with 4.4 and 4.9.
> Below I have the output of
>
So maybe if you're a bit more verbose with what you mean by "it doesn't
work". What you're tryi
Thomas,
I don't rightly know. I've done plenty of bare metal SPI, or enough of it
anyway. The only thing I've done with SPI on the beaglebone, is a lot of
reading. No actual hands on, Honestly I'm not sure if the edma fix would
work for your situation or not. I think the edma fix was more or less
On Thu, Jan 19, 2017 at 3:43 PM, Thomas Hoppe wrote:
> Maybe there was a misunderstanding, I do have the SPI devices with all the
> kernels I mention!
> And that is because I have the lines on the bottom in uEnv.txt. So again the
> existence of the devices is not my problem,
> it just does not wor
Maybe there was a misunderstanding, I do have the SPI devices with all the
kernels I mention!
And that is because I have the lines on the bottom in uEnv.txt. So again
the existence of the devices is not my problem,
it just does not work. Do you think the patch you mention can be the reason
for t
Additional information:
I seem to recall there was an issue with SPI loading at boot. This had
something to do with having to enable the spi software module in main board
overlay file. Of which there has been several posts over the last few
months. So see those for the exact details. So basically
*root@beaglebone:~#* cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-19
*root@beaglebone:~#* uname -r
4.4.43-bone-rt-r16
*root@beaglebone:~#* ls /lib/firmware/ |grep SPI
BB-SPI0-MCP3008-00A0.dtbo
BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo
*root@beaglebone:~#* ls /dev |
Hi,
I have a board attached via SPI0 to a BBB (also tested with Green).
I'm activating SPI0 via uEnv.txt entries which I read is the best practice.
Now I can use the board with its user space software (no kernel driver
whatsoever involved).
The setup *works* with 3.8 and 4.1 kernels but *not* wit
Thanks Scott and Emile! I am now zero initializing the structure. Everything
seems to be working now. Quite a learning experience! Watching the io on the
logic analyzer has definitely helped me understand how this all works. Another
issue I mentioned in my original post was that I wasn't ge
On Wednesday, September 30, 2015 at 8:25:47 AM UTC-3,
scottellis...@gmail.com wrote:
>
> You need to set the tx_nbits and rx_nbits fields of the spi_ioc_transfer
> struct
> to something valid. Zero will do.
>
>
Better would be to first zero-initialize the entire struct using memset.
Then you set
You need to set the tx_nbits and rx_nbits fields of the spi_ioc_transfer
struct
to something valid. Zero will do.
If you are using a stack variable (which your code snippet implied), the
tx_nbits
and rx_nbits fields are likely random garbage.
You might just be getting lucky now.
--- from inclu
printf() debugging at it's best ;) You're welcome hehe
On Tue, Sep 29, 2015 at 9:45 PM, Larry M wrote:
> William, thank you so much! That put me on the right track. The error I
> got was "invalid argument". The ioctl was within a function. Not really
> sure what the exact problem was, but ta
William, thank you so much! That put me on the right track. The error I
got was "invalid argument". The ioctl was within a function. Not really
sure what the exact problem was, but taking it out of the function fixed
the problem. Perhaps it was recasting the &transfer address, which is
som
#include
. . .
int status = ioctl(fd, SPI_IOC_MESSAGE(1), &transfer);
if(status == -1)
/* Google the error messege - Pay close attention to
stackoverflow.com posts */
printf("error: %s\n", strerror(errno));
. . .
On Tue, Sep 29, 2015 at 5:25 PM, Larry M wrote:
> I'm looking
I'm looking for help from someone much more knowledgeable than me, or my
BBB is likely to go flying out the window!
I am running Debian Jessie 8.2
(BBB-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2015-09-20-4gb) on a BBB Rev C,
with Kernel 4.0.8 PREEMPT RT.
I have spidev1.0 enabled, currently con
17 matches
Mail list logo
