SPI Comm between LogiBone and BBB

Kumar

Is there a recommended test app to test the SPI comm between the Logibone and BBB?  I'm using Logibone R1.5 and BBB on Linux arm 3.8.13-bone63.  I prefer getting my hands on the hw and sw source code as I believe I would eventually integrate them to my application.  

I tried the logi-com-test in the logi-hard git repo, however the test_wishbone failed with error message "Transfer Failed".  On the hw side, I replaced the ucf in logi-com-test with the ucf file logibone_r1_5.ucf from the master_ucf section of the git.  I generated the bit file (logibone_com_test_spi.bit) using Xilinx ISE and loaded the bit file using the logi_loader.  On the sw side, I ran the makefile to generate the "test_wishbone" executable.  After loading the bit file I ran the test_wishbone executable and this is the error message I get. 

Time in Microsecond=132

W Speed=====121 KB/Sec

Time in Microsecond=73

R Speed=====219 KB/Sec

Transfer failed [0] = 0000

Transfer failed [1] = 0000

Transfer failed [2] = 2000

Transfer failed [3] = b6ef

Transfer failed [4] = 0000

Transfer failed [5] = 0000

Transfer failed [6] = 0000

Transfer failed [7] = 0000

Time in Microsecond=10

W Speed=====1600 KB/Sec

Time in Microsecond=9

R Speed=====1777 KB/Sec

Transfer failed [0] = 0000

Transfer failed [1] = 0000

Transfer failed [2] = 2000

Transfer failed [3] = b6ef

Transfer failed [4] = 0000

Transfer failed [5] = 0000

Transfer failed [6] = 0000

Transfer failed [7] = 0000

Appreciate any pointers in solving this issue.

Thanks,

Kumar

mjones

Hi @Kumar

The Lbone design shares some IO functions, based upon pin constraints and the number IO needed for all of the ports, etc.  It is also assumed that GPMC is the main means of communication between the Lbone/BBB.  That being the case, on the R1.5 and later, the SPI SCLK and MOSI pins, by default, are disconnected from the FPGA so that the FPGA has no conflict accessing the SPI flash on the shared lines.  But, the MOSI and SCLK pins can easily be enabled by selecting OE# on the buffer IC.  

You will need to select configure the GPIO expander to pull the OE# pin low to re-connect these signals to the FPGA as is done when using the LOGI loader.  If SPI is going to be used frequently by users we may enable the buffer by default, but for now you will need to manually enable the OE# with the expander.  You can reference the logi_loader source for sample code of changing the IO pins on the expander.  

https://github.com/fpga-logi/logi-tools/tree/master/unified_loader

Let us know if there is still a problem after ensuring the OE# is enabled.

jpiat

If you used logi_loader (unified_loader), the OE enable pin is configured to enable SPI communication. The problem you have is that you loaded the SPI com test in the hardware and that the com test in the software repository uses the GPMC bus to communicate with the platform. If you want to run the com test with the spi, you need to modify the example for the logipi in sw/logipi. The onely modification you need to make is to edit the wishbone_wrapper.h file and change the line :

static const char * device = "/dev/spidev0.0";

into

static const char * device = "/dev/spidev1.0

The compile on the BBB and run the code.

Regards,

Jonathan Piat

Kumar

Thank you Jones and Piat for your inputs.  I'll try your suggestions and post an update.

Kumar

So I tried the suggestion Jonathan had but the SPI communication still failed.  

Here is what I did:

Modified the spi device to "/dev/spidev1.0" in file "logi-com-test/sw/logipi/wishbone_wrapper.c".

Note that the hw hdl code is from "logi-com-test/hw/logibone/hw/hdl/logibone_com_test.vhd"

jpiat

I will vive it à try and let you know

jpiat

can you just tell me where you downloaded your kernel (for the logibone) from ? So we can be sure to have the same version.

Kumar

The LOGI Bone Ubuntu image is from here,

http://valentfx.com/doc/logi-image/logibone/logibone_150429_ubuntu-14.04-console-armhf-2014-08-13.img.zip

Kumar

My UCF file on SPI connections is like this.  I've also attached the ucf file i'm using for your reference.

NET "SYS_SPI_MISO"    LOC = "P82" | IOSTANDARD = LVTTL;

NET "SYS_SPI_SCK"     LOC = "P70" | IOSTANDARD = LVTTL | CLOCK_DEDICATED_ROUTE = FALSE;

NET "SYS_SPI_SS"      LOC = "P81" | IOSTANDARD = LVTTL;        

NET "SYS_SPI_MOSI"    LOC = "P65" | IOSTANDARD = LVTTL;

jpiat

I don't think its a ucf problem. In a old device tree config we had the SPI configuration all wrong and this would prevent the processor from reading data from the FPGA. I need to check that the kernel we delivered is not based on that device tree config.

jpiat

I got the communication over spi working with and eMMC booted beaglebone green (the new one from seeed) and this should apply also to BBB. You need to edit /boot/uEnv.txt and add :

cape_enable=capemgr.enable_partno=BB-SPIDEV1

to enable spi. Then you can configure your image with logi-tools. In the init_logibone.sh script comment the lines :

#cd init_logibone
#sudo ./init_eeprom.sh

This will avoid the init script to flash the cape eeprom and will disable the auto-loading of the cape.

Once done, you can use the com test project with SPI (i have updated the project on the git). Just make sure that unused pins are left floating by doing a right click on "generate programming file" -> process properties -> COnfiguration Options -> Unused Pins -> Floating.

Then you can use the sw logibone_spi from the git (logi-com-test/sw/logibone_spi) on the beaglebone to test the communication. I have tested with a SPI clock of 48MHz and it seem to work fine( but speed is lower than what i get on the rapsberry pi with same clock speed).

jpiat

it seems that the dts for spi limits the spi speed to 16MHz while it can go up to 48MHz. I get ~1MB/s transfer speed, so 3x clock rate could got ~3MB/s with the proper dts.

Kumar

Thanks J,  the SPI comm works now.  I was getting around 700 kB/s transfer speed at 16 MHZ spi clock rate.

joesan

Hello, Thanks for your useful information. Seems that we can work with SPI and the logibone.

Could you summarize the steps to get running SPI on the logibone, please?

Thanks.

joesan

I've just followed the steps to use the spi sw (logi-com-test/sw/logibone_spi) and I've got:

Time in Microsecond=198
W Speed=====80 KB/Sec
Time in Microsecond=803
R Speed=====19 KB/Sec
Transfer failed [0] = 0000
Transfer failed [1] = 0000
Transfer failed [2] = 0000
Transfer failed [3] = 0000
Transfer failed [4] = 0000
Transfer failed [5] = 0000
Transfer failed [6] = 0000
Transfer failed [7] = 0000
Time in Microsecond=185
W Speed=====86 KB/Sec
Time in Microsecond=145
R Speed=====110 KB/Sec
Transfer failed [0] = 0000
Transfer failed [1] = 0000
Transfer failed [2] = 0000
Transfer failed [3] = 0000
Transfer failed [4] = 0000
Transfer failed [5] = 0000
Transfer failed [6] = 0000
Transfer failed [7] = 0000

I have the same ubuntu image loaded into the SD card, the only thing I did'nt find the same was the changes in "init_logibone.sh" I've got "install_logibone.sh" instead but I did the same changes for it.

Appreciate any help about that.
Thanks.

mjones

Hi @joesan  We will be creating an image with SPI enabled by default and run from the debian image on emmc.  We will let you know when we have it ready.  

joesan

Thank you very much for your answer mjones, would be great to have a similar solution for the SPI like there's for the GPMC.
But in the meantime I'm trying to get it ready, reading this post seems to be possible...

I made some progress, I can check that I've got the SPI signals working.I did manage to setup a easy VHDL code only with spi_wishbone_wrapper.vhd the intercon.vhd and my custom testing code in order to test if the data is correct.

The transmision MOSI is working, I'm able to check that the data transmited is correct, the problem comes whe I'm trying to read back this data, I'm getting a nice 0.

Is there any setup about the SPI that I did miss? seems like the receiving module is not working fine...
Any ideas?

Thanks!

joesan

I forgot in the sw I've got it modified only with the functions to write and read from the spi:

                gettimeofday(&temp1,NULL);
                if((i = wishbone_write(writeVals, 2, 0x0000)) < 2){
                        printf("Write error !, returned %d \n", i);
                }
                gettimeofday(&temp2,NULL);
                gettimeofday(&temp1,NULL);
                if((i = wishbone_read(readVals, 2, 0x0000)) < 2){
                        printf("Read error !, returned %d \n", i);
                }
                gettimeofday(&temp2,NULL);
                for (i=0;i<2;i++){
                        printf("returned %i \n", readVals[i]);
                }
Thanks in advance.

jpiat

Hi,

do you still have your logibone cape recognized as such (do a "dmesg | grep LOGI" in a console ? If you fail to read from SPI, this can be a BBB mux setup issue. When the LOGIBONE is properly detected it does not set the SPI pins for true SPI but only FPGA programming interface (no need for MISO), so if the cape is detected, the SPI reads might not work.

joesan

Thanks for the reply Jpiat, I beleive as well that could be the problem....Could you tell me how to disable it please? changes to the dts? I've got that:

[    0.577265] bone-capemgr bone_capemgr.9: slot #0: 'BB-BONE-LOGIBONE,00R1,VALENTFX,BB-BONE-LOGIBONE'
[    0.689211] bone-capemgr bone_capemgr.9: loader: before slot-0 BB-BONE-LOGIBONE:00R1 (prio 0)
[    0.689225] bone-capemgr bone_capemgr.9: loader: check slot-0 BB-BONE-LOGIBONE:00R1 (prio 0)
[    0.689785] bone-capemgr bone_capemgr.9: loader: after slot-0 BB-BONE-LOGIBONE:00R1 (prio 0)
[    0.689812] bone-capemgr bone_capemgr.9: slot #0: Requesting firmware 'BB-BONE-LOGIBONE-00R1.dtbo' for board-name 'BB-BONE-LOGIBONE', version '00R1'
[    0.689836] bone-capemgr bone_capemgr.9: slot #0: dtbo 'BB-BONE-LOGIBONE-00R1.dtbo' loaded; converting to live tree
[    0.733852] bone-capemgr bone_capemgr.9: loader: done slot-0 BB-BONE-LOGIBONE:00R1 (prio 0)
[    0.734160] bone-capemgr bone_capemgr.9: slot #4: BB-BONE-EMMC-2G conflict P8.21 (#0:BB-BONE-LOGIBONE)

Many thanks.

jpiat

Non need to change the dts, you only need to disable the cape eeprom with the following command :

sudo sh -c "echo 'abcd' > /sys/bus/i2c/drivers/at24/1-0054/eeprom"

this will overwrite the first bytes of the eeprom and linux won't automatically load the description

joesan

Thanks, I did issue the command and now I've got a problem trying to load the fpga bit file, I've got this message:

Compiled for LOGI-BONE
Board variant is LOGIBONE_R1.5
can't open SPI spi_device
can't open SPI bus
No logi-board detected !!

joesan

How can I restore that?7
thanks.

jpiat

did you ad :

cape_enable=capemgr.enable_partno=BB-SPIDEV1

to uEnv.txt in /boot ?

joesan

Sorry that solution is not working deleted the spi option of the system...
 I just fixed that with intall_logibone.sh
But I still have the problem in the receiving data...

jpiat

Install_logibone.sh restored the eeprom content but its not the solution. You should disable it again, the modify uEnv.txt with the SPI option and check the boot msg to understand why SPI was not loaded (dmesg | grep SPI).

joesan

Hi jpia, thanks for your help,

yes, I've got that line in the uEnv.txt file and all previous steps..

The thing is I've got working the spi but only in trasmision to the FPGA when I'm reading back only I'm reading a 0, as long was the same address which I wrote before otherwise I'm getting high numbers like 65321 o something like that...

I did check the bus lines with a logical analizer and I saw the MISO(working but receiving a 0) line a low level logic and the MOSI (working) at high level...I don't know if this is a clue or not but maybe I have to setup something else in the spi configuration...

Other thing I'm thinking maybe a problem in the sw functions, when I'm compiling the test_wishbone.c file (sudo make) I'm getting a warnings with the values passed to de write and read functions:

test_wishbone.c:74:3: warning: passing argument 1 of ‘wishbone_read’ from incompatible pointer type [enabled by default]
   if((i = wishbone_read(readVals, NB_VAL, 0x0800)) < NB_VAL){
   ^
but it doesn't affect to the transmition...

joesan

Copy/paste of my uEnv.txt file:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.8.13-bone63

#dtb=

uuid=9c9ea694-43de-45a4-9e35-0190f1f19063

cmdline=quiet

##Example
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v2.sh
cape_enable=capemgr.enable_partno=BB-SPIDEV1


thanks.

jpiat

Can you pm me so I can send you a known to work bitfile later today ?

joesan

Sorry, I add a  screenshot the weird lines that I'm getting through spi:



The weird thing is the transmision works even with the strange clock signal supposed to be continuous, I mean 8 clocks per byte...I don't know what is going on...

joesan

the image: