Ahmed Atlam
Posts: 4
Joined: Sun Feb 28, 2016 6:40 am

RPI Compute SPI Signal Problem

Sun Feb 28, 2016 11:11 am

I am working with a Compute Module and the IO Board. Just moved from STM32F4 (which performed great, but just doesnt pack enough power for the application in mind). I am trying to interface a metering SPI chip using the PI Compute as an alternative to the STM32F4, however the results are rather strange.

Let me explain the setup:
1) running a Raspbain Jessie Lite.
2) using the pigpio c library

Here is the test code:

Code: Select all

int version;
	if((version = gpioInitialise()) < 0)
	{
		printf("version: %d\n", version);
		exit(1);
	}
	{
		printf("version: %d\n", version);
	}

	int SPI_Handle = spiOpen(0,32000000,0);

	char Rxbuffer[1000];
	char Txbuffer[1000];
	int i = 0;
	while( i< 1000)
	{
		if((i%2)==0)
		{
			Txbuffer[i] = 0XAA;
		}
		else
		{
			Txbuffer[i] = 0XF0;
		}
		i++;
	}

	while(1)
	{
		spiXfer(SPI_Handle,&Txbuffer[0],&Rxbuffer[0],sizeof Txbuffer);
	}

	gpioTerminate();

This code simply produces an SPI clock on Pin_11 and a series of 0XAA(B10101010) followed by 0XF0(B11110000) which are very easy to see on a scope.

I ran this code multiple times using different speeds and captured the results on the scope,with yellow channel for the MOSI line and Blue channel for the Clock.

Result @ 1Mhz:
1Mhz.png
1Mhz.png (14.08 KiB) Viewed 2539 times
Which is a typical SPI signal ... exactly what you would expect (didnt check the frequency though, because my problem is much more severe at higher frequencies)

Result @ 4 Mhz:
4Mhz.png
4Mhz.png (15.72 KiB) Viewed 2539 times
This is still a valid signal. The data values and the clock edges are still right so I guess it will work.

Result @ 8 Mhz:
8Mhz.png
8Mhz.png (15.98 KiB) Viewed 2539 times
Now the Data and the Clock Edges are actually out of sync at points. This signal will not work ( and only at 8Mhz !! I personally tried much higher than this on the STM32F4 and the square waves looked much better, also I tried the ENC28J6 SPI to Ethernet Module which is supposed to be working at 16Mhz and worked (much slower, but it did work meaning the signal definitely didnt look like that). Also Notice that the clock signal doesnt reach zero anymore.

https://www.dropbox.com/s/fso5fa0h0zr6n ... z.png?dl=0(sorry cannot attach more than 3 files)


Now the pigpio library, wiringPi and a long list of others claim that you could clock the SPI on the pi up to 32Mhz so here is what this looks like:

Result @ 32Mhz:
https://www.dropbox.com/s/fso5fa0h0zr6n ... z.png?dl=0
https://www.dropbox.com/s/dfr92lltqr2cc ... K.png?dl=0 (here if you look at the delta Time between 2 time spikes, you will find that it would result in ~83MHZ if the clock signal was intact, which is rather strange)

Now can someone please tell me is this a case of poor signal termination (I am scoping the pins directly without any device connected as the device obviously did not work at high frequencies)? or if pigpio doesnt utilize the actual SPI device (/dev/spidev0.0) and is bit banging ?? I was under the impression that the RPI-Compute Module has built in pull up resistors for SPI (please correct me if I am wrong), but after these results I am starting to doubt it. Also alot of people claim they actually got the SPI working at frequencies around 32Mhz, can someone provide a repeatable working setup to recreate the transmissions at 32Mhz? Does the internal pull up resistors require special initialization ? (not already initialized during the alternate function initialization ??)

Thank you very much and any and all help is greatly appreciated !
Best regards,
Ahmed

danjperron
Posts: 3522
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: RPI Compute SPI Signal Problem

Sun Feb 28, 2016 1:35 pm

Even at 8MHz the signal is ok! If you look at the rising edge of the clock the signal is correct.

The problem looks to be the capacitive charge you have using the oscilloscope probe. Did you have any load on the gpio pins (or too much of it)?

Try to put some pull up 4k7 resistor and see if it does change the signal.

Ahmed Atlam
Posts: 4
Joined: Sun Feb 28, 2016 6:40 am

Re: RPI Compute SPI Signal Problem

Mon Feb 29, 2016 1:34 am

Thank you very much for your response !!
I did try adding pull ups and the signal doesnt change ... it just shifts the whole curve up or down depending on the value of R pullup, but thats it.

One thing I noticed is that the traces on the IO Compute Module are rather long (compared to a regular RPI) and the signal goes through a DDR2 Connector (although RAM modules mounted in the same connector work at much higher speeds), never the less, do you think that might be the cause of signal degradation ?? Also, please take a look at the signal @ 1Mhz. Why is there a delay between each byte ? on the STM32F4 MUC there was no delay at all between bytes (unless there is something being done by software in between) but for a burst buffer transfer, the clock signal was continuous until buffer transfer is complete, THEN there is a delay until the next buffer is loaded into transmission. It seems to me that the library is loading the buffer byte by byte instead of loading the memory address and having the (SPI/DMA) controller combo increment the memory address until length (was under the impression that buffer transfers work that way and single read and writes work byte by byte). I have a strong feeling that this is a software problem rather than hardware.

User avatar
joan
Posts: 15043
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: RPI Compute SPI Signal Problem

Mon Feb 29, 2016 5:06 am

Ahmed Atlam wrote: ...
Also, please take a look at the signal @ 1Mhz. Why is there a delay between each byte ? on the STM32F4 MUC there was no delay at all between bytes (unless there is something being done by software in between) but for a burst buffer transfer, the clock signal was continuous until buffer transfer is complete, THEN there is a delay until the next buffer is loaded into transmission. It seems to me that the library is loading the buffer byte by byte instead of loading the memory address and having the (SPI/DMA) controller combo increment the memory address until length (was under the impression that buffer transfers work that way and single read and writes work byte by byte). I have a strong feeling that this is a software problem rather than hardware.
The Broadcom SPI hardware introduces a (I think) 1.5 bit time delay between each word (a word is usually 8 bits long). I don't know why.

Ahmed Atlam
Posts: 4
Joined: Sun Feb 28, 2016 6:40 am

Re: RPI Compute SPI Signal Problem

Tue Mar 01, 2016 5:28 am

joan wrote:
Ahmed Atlam wrote: ...
Also, please take a look at the signal @ 1Mhz. Why is there a delay between each byte ? on the STM32F4 MUC there was no delay at all between bytes (unless there is something being done by software in between) but for a burst buffer transfer, the clock signal was continuous until buffer transfer is complete, THEN there is a delay until the next buffer is loaded into transmission. It seems to me that the library is loading the buffer byte by byte instead of loading the memory address and having the (SPI/DMA) controller combo increment the memory address until length (was under the impression that buffer transfers work that way and single read and writes work byte by byte). I have a strong feeling that this is a software problem rather than hardware.
The Broadcom SPI hardware introduces a (I think) 1.5 bit time delay between each word (a word is usually 8 bits long). I don't know why.
Its very nice to hear from you Joan !! I have made extensive testing using your library and multiple others as well down to direct register access (almost bare metal but not quite!!) ... I have done same tests on the Compute Module-IO board and a regular RPI2. The signal looks better (still distorted beyond being functional, but better) on the RPI2 than on the Compute Module which brings me to the conclusion that this has nothing to do with software and your library and that the limitation is from the actual hardware traces and pins. While the Broadcoms chip actually supports much higher SPI rates, I dont think that anything can be operated at more than 8Mhz reliably from the pin headers, maybe 16Mhz and thats pushing it a bit, but definitely not the 32Mhz band. Unfortunately, my application requires an absolute minimum transfer rate of 21.86 Mhz without accounting for any processing time in between samples (350 bytes / sample) * (7810 samples / second) and with the 1.5 bit delay you mentioned that inflates that figure by roughly 18.75 % making that 25.95 Mhz.

I think the only thing left for me is to change the RPI platform altogether for something more robust at high speeds (32Mhz or higher if possible). Please let me know if you have any recommendations and if you have started implementing the same library for a different target platform, would love to use your library.

Thank you very much for your amazing work !!

User avatar
gordon@drogon.net
Posts: 2022
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website Twitter

Re: RPI Compute SPI Signal Problem

Tue Mar 01, 2016 7:34 am

The issue would be more hardware related than software, so it matters little if you use pigpio, wiringPi, direct kernel, or direct register access... The SPI can generate clock speeds of over 32Mb/sec but if you can't get those signals off the board in an electrically stable manner, then it's not going to matter what speed you use.

-Gordon
--
Gordons projects: https://projects.drogon.net/

Ahmed Atlam
Posts: 4
Joined: Sun Feb 28, 2016 6:40 am

Re: RPI Compute SPI Signal Problem

Tue Mar 01, 2016 8:51 am

gordon@drogon.net wrote:The issue would be more hardware related than software, so it matters little if you use pigpio, wiringPi, direct kernel, or direct register access... The SPI can generate clock speeds of over 32Mb/sec but if you can't get those signals off the board in an electrically stable manner, then it's not going to matter what speed you use.

-Gordon
Thanks alot for your feedback Gordon !
I completely agree with you ... I have a question though, I have been getting almost identical curves probing open circuit voltage (without the device connected) and loaded circuit (thought that perhaps the bus termination on the device evaluation board could help, but it didnt). From my limited understanding, the fast changing voltages are not the source of cross talk issues, its when the SPI bus is connected to a load and an actual current flows and alternates between on and off states at high speeds is what generates the emf and results in cross talk, parasitic effects of components(in this case capacitance I believe ... the curves look like a RCL circuit about to resonate, if i keep increasing frequency the CLK and Data lines will eventually flat out) ect ... now assuming this is correct (please correct me if this is not the case) and I am using a more or less decent scope (Tektronix TBS 1102B) not a hand held chines model, the problem of poor signaling (electrical instability) should occur only when the SPI bus is loaded and not during open circuit probing (no current flowing). This is not the case, so I am thinking its
  • 1) This is a bug (or rather a design flaw with the 2835/36) --- Highly unlikely as the SD card and eMMC flash memories work well at high speeds
    2) This is poor design and traces issue with the RPI board it self (Highly unlikely, would appreciate anyone providing documented repeatable cases of SPI operation above 32Mhz)
    3) I am missing something as usual (Most likely the case)
By any chance did you perform testing to verify the attainable speeds in your library ? You once mentioned (cant remember where exactly but probably on the wiringPi home page) that routing signals around 32Mhz is probably not going to work (of course not going to work for the hobbyist DIY PCB Eagle stuff) but did you mean that generally the PI struggles at these speeds, even if it is equipped with a professionally routed and manufactured hat ? that would be a deal breaker for me.

Thank you very much looking forward to your feedback!!
Ahmed

User avatar
gordon@drogon.net
Posts: 2022
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website Twitter

Re: RPI Compute SPI Signal Problem

Tue Mar 01, 2016 12:44 pm

Ahmed Atlam wrote:
gordon@drogon.net wrote:The issue would be more hardware related than software, so it matters little if you use pigpio, wiringPi, direct kernel, or direct register access... The SPI can generate clock speeds of over 32Mb/sec but if you can't get those signals off the board in an electrically stable manner, then it's not going to matter what speed you use.

-Gordon
Thanks alot for your feedback Gordon !
I completely agree with you ... I have a question though, I have been getting almost identical curves probing open circuit voltage (without the device connected) and loaded circuit (thought that perhaps the bus termination on the device evaluation board could help, but it didnt). From my limited understanding, the fast changing voltages are not the source of cross talk issues, its when the SPI bus is connected to a load and an actual current flows and alternates between on and off states at high speeds is what generates the emf and results in cross talk, parasitic effects of components(in this case capacitance I believe ... the curves look like a RCL circuit about to resonate, if i keep increasing frequency the CLK and Data lines will eventually flat out) ect ... now assuming this is correct (please correct me if this is not the case) and I am using a more or less decent scope (Tektronix TBS 1102B) not a hand held chines model, the problem of poor signaling (electrical instability) should occur only when the SPI bus is loaded and not during open circuit probing (no current flowing). This is not the case, so I am thinking its
  • 1) This is a bug (or rather a design flaw with the 2835/36) --- Highly unlikely as the SD card and eMMC flash memories work well at high speeds
    2) This is poor design and traces issue with the RPI board it self (Highly unlikely, would appreciate anyone providing documented repeatable cases of SPI operation above 32Mhz)
    3) I am missing something as usual (Most likely the case)
By any chance did you perform testing to verify the attainable speeds in your library ? You once mentioned (cant remember where exactly but probably on the wiringPi home page) that routing signals around 32Mhz is probably not going to work (of course not going to work for the hobbyist DIY PCB Eagle stuff) but did you mean that generally the PI struggles at these speeds, even if it is equipped with a professionally routed and manufactured hat ? that would be a deal breaker for me.

Thank you very much looking forward to your feedback!!
Ahmed
Testing I've personally done (On a Raspberry Pi, not a CM) -- basically connect up (relatively) low-speed devices - 1-4Mhz clocks. e.g. gpio expanders, ADC/DACs, etc. Since these just worked for me, I've never looked at the waveforms.

I have used an LCD display thing which I wrote some driver software for. This ran the SPI at 32Mhz. The board was plugged directly on-top of the Pi, so the signal lengths were very short. The board worked well and I was able to do relatively large transfers over it.

This was very similar to the current LCD/TFT panels that plug on-top of the Pi - e.g. from Adafruit, etc. I'm fairly sure I saw one of them claim to be driving the SPI at 48Mb/sec, but not sure.

The only time I've stuck a 'scope onto a bus signal on a Pi was to check the I2C bus - I was trying to make it run at 1.2Mb/sec. It was failing miserably and the signals were quite rounded. At 800Kb/sec the signals were still slightly rounded, but the devices I was using worked just fine.

I'm not a "hard-core" EE designer, but I'd look carefully at things like routing of the HDMI signals & camera/display interfaces on the CM/CMIO reference board and mimic them for SPI if you're trying to run it above a few MHz.

-Gordon
--
Gordons projects: https://projects.drogon.net/

Return to “C/C++”