16mhz is the SPI clock frequency. At what frequency is your logic analyzer sampling the signals ? The protocol is 14bits address, 1bit for burst mode, 1bit for read/wr, then the all the data that follows is on 16bits MSB first.
After a few tests I have the logical analizer with the correct setup. It needs to work to more sampling rate in order to get the data correctly, I did setup at 24MHz and now is able to capture data to 16MHz which is the SPI bus speed.
Ok, said that, I can see the correct data in the bus, that means SPI is working and all setups in the BBB are correct (capes,eeprom...etc) and the VHDL code is correct.
These are my results,
Writing stage (here we see the MOSI line only):
Reading stage (here we see both MOSI for the address and MISO for the data send back for the FPGA):
First of all you should be sampling the signals at higher speeds (32MHz) to have a better resolution. Your capture are very interesting, but i don't understand why the MISO lines toggles during the transfer of the first byte which is the addressing phase ...
Thanks jpiat, I don't understand neither....but the interesting thing is that the reading function in the sw is reading 0...and I don't have a clue what is wrong, do you have reception of data with any problems? could be a problem with the SPI drivers? (the kernel I've got is: 3.8.13-bone63)
I'm trying to find out what is the problem and seems to be that the MISO pin is not activated or something similar, even enabling the SPI module I beleive we have to enable the pin as well. Per default the logibone is setup to work with the SPI programing and GPMC for that only it has enabled MOSI CLK and SS it needs to be enable MISO as pull-up input. If I test the voltage at the pin I can read alwas 0 even conecting a pull up resistor fisically on board, that means the pin is not ready to work with SPI even with SPI enabled...
Well said this, I'm trying to activate this pin in the DTS file and I'm doing so following this tutorial:
But once compiled and fisished if I'm checking the pins (cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups) I can not see any changes...still the original setup, if all of this is correct, I have a few doubts if anyone can help me please: Do I have to change the main dts file? Where is it and how I do the changes? I'm I bit lost in this part I would appreciate any help....
I have the SPI fully working, I managed to get it working and fix all issues. I only started from the beginning following the steps in this post. Thanks.
do you have any of what went wrong ? I was a little lost because the same steps on my side did not raise the same issues ... Thanks a lot for the signal capture, as you can see it show that the BBB SPI controller adds a lot of delays between bytes. I don't know if this issue could be solved.
Yes the problem I've been facing was in the software I had incorrect SPI set up in the device tree slots , I had to clean it up and start again. Now is working. I've got a lot of signal data which show this delay between bytes. I've seen this in other similar systems (SoC) and most of the time is because the CPU is taking care of another tasks (always depends of the CPU used), one common improvement I would suggest is using DMA, that would release load to the CPU decreasing the delaying time between bytes.
Another thing is about the SPI VHDL wrapper core, for de example was working ok, when I tried to integrate it in my project it was not working. I've found a issue in terms of delay related to the addresses in the wishbone bus, the addresses were ok but delayed and the reason is the ack signal is not connected anywhere then the spi control doesn't know when the wishbone slaves are ready. You can change or compensate that in your VHDL code but I think the right way is to change it in the SPI wishbone wrapper file.
This is the change I did:
Original: if auto_inc = '1' and data_confn = '1' and bit_count = 7 then if rd_wrn = '1' or (rd_wrn = '0' and data_byte = '1') then addr_bus_latched <= addr_bus_latched + 1 ; end if; end if ;
changed:
if wbm_ack = '1' then --if auto_inc = '1' and data_confn = '1' and bit_count = 7 then --if rd_wrn = '1' or (rd_wrn = '0' and data_byte = '1') then addr_bus_latched <= addr_bus_latched + 1 ; --end if; --end if ; end if;
The part in red is not needed can be deleted.
I'm working and testing my code with that modification and is stable. I hope it was helpful.
Comments
other configuration...
After a few tests I have the logical analizer with the correct setup. It needs to work to more sampling rate in order to get the data correctly, I did setup at 24MHz and now is able to capture data to 16MHz which is the SPI bus speed.
Ok, said that, I can see the correct data in the bus, that means SPI is working and all setups in the BBB are correct (capes,eeprom...etc) and the VHDL code is correct.
These are my results,
Writing stage (here we see the MOSI line only):
Reading stage (here we see both MOSI for the address and MISO for the data send back for the FPGA):
SPI seems to be working, but I'm reading back only 0 despite we can see there's data in the bus...I don't know whats going on but seems to be a problem with the SW I'm using: https://github.com/fpga-logi/logi-projects/tree/master/logi-com-test/sw/logibone_spi I don't know if this is the correct one...
"returned 0000"
Any ideas? Thanks.
I don't understand neither....but the interesting thing is that the reading function in the sw is reading 0...and I don't have a clue what is wrong, do you have reception of data with any problems? could be a problem with the SPI drivers?
(the kernel I've got is: 3.8.13-bone63)
Well said this, I'm trying to activate this pin in the DTS file and I'm doing so following this tutorial:
http://elinux.org/BeagleBone_Black_Enable_SPIDEV
But once compiled and fisished if I'm checking the pins (cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups) I can not see any changes...still the original setup, if all of this is correct, I have a few doubts if anyone can help me please:
Do I have to change the main dts file?
Where is it and how I do the changes?
I'm I bit lost in this part I would appreciate any help....
Thanks in advance.
Regards.
Thanks.
Yes the problem I've been facing was in the software I had incorrect SPI set up in the device tree slots , I had to clean it up and start again. Now is working.
I've got a lot of signal data which show this delay between bytes. I've seen this in other similar systems (SoC) and most of the time is because the CPU is taking care of another tasks (always depends of the CPU used), one common improvement I would suggest is using DMA, that would release load to the CPU decreasing the delaying time between bytes.
Another thing is about the SPI VHDL wrapper core, for de example was working ok, when I tried to integrate it in my project it was not working. I've found a issue in terms of delay related to the addresses in the wishbone bus, the addresses were ok but delayed and the reason is the ack signal is not connected anywhere then the spi control doesn't know when the wishbone slaves are ready. You can change or compensate that in your VHDL code but I think the right way is to change it in the SPI wishbone wrapper file.
This is the change I did:
Original:
if auto_inc = '1' and data_confn = '1' and bit_count = 7 then
if rd_wrn = '1' or (rd_wrn = '0' and data_byte = '1') then
addr_bus_latched <= addr_bus_latched + 1 ;
end if;
end if ;
changed:
if wbm_ack = '1' then
--if auto_inc = '1' and data_confn = '1' and bit_count = 7 then
--if rd_wrn = '1' or (rd_wrn = '0' and data_byte = '1') then
addr_bus_latched <= addr_bus_latched + 1 ;
--end if;
--end if ;
end if;
The part in red is not needed can be deleted.
I'm working and testing my code with that modification and is stable.
I hope it was helpful.
Regards.