Loading SPI_CLK is no good

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Gothmag
Experienced Member
Posts: 103
Joined: Wed May 11, 2016 3:50 pm
Contact:

Re: Loading SPI_CLK is no good

Postby Gothmag » Thu Sep 21, 2017 4:10 pm

There is no drive difference but it has a more direct connection which can be important. As of now it looks like you have a lot of solder connections, long pin headers(high capacitance and inductance relatively along with small antennas), a free wire connection, then finally to the pci. This is in addition to the traces on the wifi slice and the explorerkit. If you can try a low value series resistor on that line you could potentially find the issue is signal integrity. Being able to see the raw signal at pcie port could help to see what's happening.

As for the SPI as long as you are not adding prints into the spi module itself you shouldn't have problems related to timing from your prints if you keep them within reason since xmos is the master.
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Fri Sep 22, 2017 1:24 pm

infiniteimprobability
Hmm - does definitely sound like this issue about cascaded clocks going via the output pad.
xCORE-200 drive is the same drive strength - 4mA, although the pin in reality drives pretty hard (hence why series resistors on clock lines are a good idea). A handful of pins are 8mA:

Yes, I too tend to think this hypothesis a string to pull. If so, is there some kind of rewrite at the driver level where it may be tested?


I have now moved the SW over to a startKIT. I modified it to get the WiFi sliceCARD connections out on a connector (picture 1).

I simply exchanged #TARGET = XCORE-200-EXPLORER with #TARGET = STARTKIT in the makefile, cleaned the project and recompiled.

When I loaded SPI_CLK with the scope nothing bad happened during startup. I did this several times and it always worked.

This might indicate that the startKIT processor is somewhat different from the xCORE-200 eXplorerKIT processor.

You may see (picture 2) that my scope doesn't sample fast enough for the SPI_CLK 12.5 MHz (20 MS/S). (I may resolve that within a week or two:-)

Ø

1 - Wifi sliceCARD setup with startKIT

Image

2 - BitScope BS10 sampling at 20 MS with WifI sliceCARD LED1 and the fast SPI_CLK 15 MHz not sampled enough on startKIT #3

Image
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sat Sep 23, 2017 11:09 am

This probably is off topic, but I post it here anyway:

Observation: The code runs substantially faster on the startKIT than on the xCORE-200 eXplorerKIT:

Image

Another observation: If I do Target I/O = XSCOPE (via xCONNECT/UART) I seem to get quite varying response times on the xCORE-200 eXplorerKIT. I don't know if that is the parameter, or it it is the wifi or whatever, However I have never seen up to 3 seconds any time before:

Code: Select all

[465 ms] **WELCOME TO THE SIMPLE WEBSERVER DEMO**
[520 ms] Switching on Wi-Fi module....
[2842 ms] Connecting to OM11-4
(9738 ms) not httpd_handle_event 9 XTCP_IFUP new ip address
[9738 ms] #### #### IP Address:  192.168.1.8

(16366 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(16394 ms) httpd_handle_event 1 XTCP_RECV_DATA
(16445 ms) GET "Hello World! 1"

(16763 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(16820 ms) httpd_handle_event 3 XTCP_SENT_DATA
(18989 ms) #### #### Unsolicited event 4

(19993 ms) httpd_handle_event 7 XTCP_CLOSED

-- 3627 ms

(22392 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(22447 ms) httpd_handle_event 1 XTCP_RECV_DATA
(22499 ms) GET "Hello World! 2"

(22763 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(22793 ms) httpd_handle_event 3 XTCP_SENT_DATA
(23847 ms) #### #### Unsolicited event 4

(24002 ms) httpd_handle_event 7 XTCP_CLOSED

-- 1610 ms

(26036 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(26075 ms) httpd_handle_event 1 XTCP_RECV_DATA
(26126 ms) GET "Hello World! 3"

(26183 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(26228 ms) httpd_handle_event 3 XTCP_SENT_DATA
(27282 ms) #### #### Unsolicited event 4

(28012 ms) httpd_handle_event 7 XTCP_CLOSED

-- 1976 ms
..

(7860 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(7891 ms) httpd_handle_event 1 XTCP_RECV_DATA
(7942 ms) GET "Hello World! 4"

(8245 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(8281 ms) httpd_handle_event 3 XTCP_SENT_DATA
(10030 ms) #### #### Unsolicited event 4

(11032 ms) httpd_handle_event 7 XTCP_CLOSED

-- 3172 ms

(13116 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(13168 ms) httpd_handle_event 1 XTCP_RECV_DATA
(13220 ms) GET "Hello World! 5"

(13349 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(13408 ms) httpd_handle_event 3 XTCP_SENT_DATA
(14463 ms) #### #### Unsolicited event 4

(15041 ms) httpd_handle_event 7 XTCP_CLOSED

-- 1925 ms

(17075 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(17123 ms) httpd_handle_event 1 XTCP_RECV_DATA
(17174 ms) GET "Hello World! 6"

(17231 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(17277 ms) httpd_handle_event 3 XTCP_SENT_DATA
(18336 ms) #### #### Unsolicited event 4

(19050 ms) httpd_handle_event 7 XTCP_CLOSED

-- 1975 ms

(21084 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(21123 ms) httpd_handle_event 1 XTCP_RECV_DATA
(21175 ms) GET "Hello World! 7"

(21233 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(21280 ms) httpd_handle_event 3 XTCP_SENT_DATA
(22339 ms) #### #### Unsolicited event 4

(23059 ms) httpd_handle_event 7 XTCP_CLOSED

-- 1975 ms
Gothmag
Experienced Member
Posts: 103
Joined: Wed May 11, 2016 3:50 pm
Contact:

Postby Gothmag » Sat Sep 23, 2017 3:53 pm

Xs1 can run cores at 125mhz, xs2 has max speed of 100mhz. That might be the difference.
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sun Sep 24, 2017 6:00 pm

Gothmag wrote:
Xs1 can run cores at 125mhz, xs2 has max speed of 100mhz. That might be the difference.

But I believe it's mostly timer driven. In wifi_tiwisl_server.xc in module_wifi_tiwisl we have:

Code: Select all

#define TIWISL_POLL 10000 // 1 us is 100 since XS1_TIMER_MHZ is 100U -> This is 100 us

This should be independent of processor speed.

This is used in wifi_tiwisl_server when it's not in a session, to start "periodically check for new connections, data to send and incoming data".

And there is no error checking and retransmit of the SPI bus, so that shouldn't make it slower I guess.

Gothmag earlier wrote:
SPI timing is not forgiving at all.

Why is this so? I thought that as a master one had full control of the CLK? This example https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Example_of_bit-banging_the_master_protocol would indicate to me that it shouldn't be critical. Disclaimer: I have no experience with SPI from my work.
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sun Oct 01, 2017 12:04 pm

I now have a SPI_CLK scope screen clip. Now with a PicoScope 2208B MSO that does 1GS/S:



And this is what 47 pF par 1M to gnd of SPI_CLK signal looks like. This causes the program to halt after init, as earlier described:

User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Oct 03, 2017 3:09 pm

Here is the full pulse train on SPI_CLK when all works, as a reference. You will see in my next comment, where I add the same situation when it stops at startup, that the only difference seems to be on the falling and rising edges. The number of 8-bit SPI cycles is the same.
Attachments
2017_10_03_F_fig2.tiff
SPI_CLK normal when it works start all pulses zoomed on last pulse train
(1.79 MiB) Not downloaded yet
2017_10_03_F_fig2.tiff
SPI_CLK normal when it works start all pulses zoomed on last pulse train
(1.79 MiB) Not downloaded yet
2017_10_03_E_fig1.tiff
SPI_CLK normal when it works start all pulses
(1.6 MiB) Not downloaded yet
2017_10_03_E_fig1.tiff
SPI_CLK normal when it works start all pulses
(1.6 MiB) Not downloaded yet
Last edited by aclassifier on Tue Oct 03, 2017 3:21 pm, edited 1 time in total.
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Oct 03, 2017 3:20 pm

Here is the scope pictures for a system that stops, since I have added 47pF par 1M to GND.

I cannot read from these scope pictures anything else than - I would look inside the processor for an explanation. So I guess infiniteimprobabiliy's hypothesis
Hmm - does definitely sound like this issue about cascaded clocks going via the output pad.

now even more needs elaboration by XMOS engineers.

I see that most readers are just readers now. It's only me here, quite natural since I have the circuitry, and I guess all hypothesis have been stated.

There is not much more I can do in this case. If cascading clocks going via a port pin might be a problem, and if this cannot be coded around (why should it, when that solution is how it's done), then I will just close this thread and say that it's "solved". But I'll let it hang for a few days. Thanks.
Attachments
2017_10_03_H_fig4.tiff
2017 10 03 H SPI_CLK stops SPI_CLK 47pf par 1M to GND all pulses zomed on last pulse train
(1.77 MiB) Not downloaded yet
2017_10_03_H_fig4.tiff
2017 10 03 H SPI_CLK stops SPI_CLK 47pf par 1M to GND all pulses zomed on last pulse train
(1.77 MiB) Not downloaded yet
2017_10_03_G_fig3.tiff
SPI_CLK stops SPI_CLK 47pf par 1M to GND all pulses
(1.49 MiB) Not downloaded yet
2017_10_03_G_fig3.tiff
SPI_CLK stops SPI_CLK 47pf par 1M to GND all pulses
(1.49 MiB) Not downloaded yet
Gothmag
Experienced Member
Posts: 103
Joined: Wed May 11, 2016 3:50 pm
Contact:

Postby Gothmag » Tue Oct 03, 2017 4:26 pm

I've been pretty busy and haven't had a chance to look closely yet but could you also scope both clk and mosi at the same time(with and without card in)? Needs to be zoomed in enough to see timing details. Also what is actual rise time for clock? All I can be sure of is it's measured in nS from the pictures. If you could mosi miso and clk would be great but shouldn't need miso just gives a better idea of what wifi card sees. I'll also respond on previous post then, I really just haven't had time yet.
User avatar
aclassifier
XCore Addict
Posts: 196
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Oct 03, 2017 5:27 pm

Great. Trying to get closer to the root cause. I guess you would like (since it's a two channel scope, but I also have 16 digital inputs [1])

  • SPI_CLK (X0D25,A8) and MOSI/SPI_MO/SPI_DI (X0D34,B10)
  • SPI_CLK (X0D25,A8) and MISO/SPI_MI/SPI_DO (X0D24,B15)
as seen in http://www.teigfam.net/oyvind/home/wp-content/uploads/2017/08/143_fig5_xmos_xcore_200_explorerkit_wifi_slicecard_breakout_board_diagram_.pdf

I guess both would reveal actual rise time for the clock, or both?

Is it enough with the first clock after power-up, then? Even if we don't know where it stops, it might even be after two two pulse trains you see. (Update: I see now that MOSI appears not on the first CLK of course).

And I would remove the 30 MHz filter?

Yes, it samples at 1GS/S div numchannels = per chanel 500 MS/S i.e. 2 ns/S per channel. So we should be able to spot some differences.

[1] http://www.teigfam.net/oyvind/home/technology/153-my-picoscope-notes/ - standard disclaimer: no money, ads, gifts etc.

Return to “Other XMOS Development Kits”

Who is online

Users browsing this forum: No registered users and 8 guests