Page 3 of 3

Re: Loading SPI_CLK is no good

Posted: Tue Oct 03, 2017 6:48 pm
by Gothmag
Ok, the filter should be removed as harmonics are up there. The digital isn't useful because we want the real time correlated signals, the digital will have filtering, doesn't give rise and fall times. You could include it but we know this works without the scope so it probably wouldn't have any useful data. You could do a mosi, miso and a clk mosi data and can piece it together that way. Rise times for all could be useful. Want to see if the signals look the way the adapter expects per datasheet.

Re: Loading SPI_CLK is no good

Posted: Tue Oct 03, 2017 7:22 pm
by aclassifier
Here are SPI_CLK and MOSI OK (fig1) and stops (fig2). Rise of SPI_CLK when failing has a pause at the middle.

Another comment coming since I can't attach them all in one.

Re: Loading SPI_CLK is no good

Posted: Tue Oct 03, 2017 7:35 pm
by aclassifier
MISO and MOSI all works (fig3) and MISO and MOSI fails (fig4). Measurement at the bottom not calculated by PicoScope, it probably doesn't find the extremal points it needs to define any wanted parameter.

Of the GND-end of SPI_CLK and 47pF par 1M, I let it float (as I do when OK), and then put my pinger on the GND point instead (was that clear). When I did auto triggering I could not see any difference when I took my finger on and off. So the impedance with respect to 50Hz is rather low, I assume. What I'm trying to say is that what you see is not a radio (we have shut down all the FM transmitters in Norway, only DAB+, but it shouldn't be that either). So what you get is probably what is there. I use the probes with the standard clips on the points, so it's not logical clips with 15 cm unshielded wire.

This is fun. Just ask!

Re: Loading SPI_CLK is no good

Posted: Tue Oct 03, 2017 8:28 pm
by Gothmag
Did you happen to try adding a ~22ohm resistor on the clock line yet? It almost looks as if you need one on all the SPI lines. I'll be able to look at these better in about 2.5 hours but they do look a bit like they need something to control the reflections but it is tough to say what is the signal and what is the probe. I also want to verify how their SPI module works.

Re: Loading SPI_CLK is no good

Posted: Wed Oct 04, 2017 9:05 am
by aclassifier
No, even if I yesterday did look through your comments from earlier and saw that you suggested a series resistor. I guess that would balance the line better. There is a lot of overshhot/undershoot. But..

I guess that would be of theoretical value only, since I cannot in practice open the wiring on the PCB. I could do it on this test layout since I have a breakout board I made myself [1] (but even then I have to break a connector wire that woud cost me a lot of work), and I could do it on the new breakoutboard I'm making right now from a cut in two XMOS Slice Breakout Card [2] that I'm going to mount an Adafruit ATWINC1500 instead (in some days, easier). But then, it works without the 1M par 47pF to GND, so I struggle with the motivation. And the pulses look "ok" without the 1M par 47pF, don't they?

Did you notice the difference betweeen the startKIT and the XCORE-200 eXplorerKIT?

[1] http://www.teigfam.net/oyvind/home/wp-c ... d_x900.jpg
[2] https://www.xcore.com/viewtopic.php?f=26&t=6086

Re: Loading SPI_CLK is no good

Posted: Wed Oct 04, 2017 9:18 am
by Gothmag
Ok, so I just looked at the records. The clock signal when it didn't work had awful rise and fall times of almost 100ns which should be more than an entire clock cycle. I still suspect this is an issue with your adapter configuration. If you can't get a low value resistor in series(I know it's alot of work for almost nothing) you could try dropping the SPI speed to see if you can scope and function at the same time then. I'd probably try 8MHZ just to start, and go from there. 12.5MHZ really isn't so fast that I think you'd NEED the termination resistors it's just something to try.

I don't have time to look at your code right now, which I think you posted earlier in the thread but the SPI library is written in a way that it can take advantage of buffered ports which basically means that if you have large capacitance/inductance issues it won't know anything about them and you'll have issues due to the XMOS driving the line but it not actually reaching the level in time. I do believe the wifi library uses this mode of operation. In summary I'm not entirely sure what the issue is but adding a series resistor(They spec 33 on the xtag lines so that's probably a good value to start) on the clock near the xmos could help, as well as cutting the SPI speed(datasheet says 0-16MHZ). If you manage to scope the signals with module plugged into startkit, and it looks ok you could probably guarantee the build of the adapter is the issue. Although if you can accept not being able to scope the signals then it's not really an issue at all.

Also yes, the signals look fine from when it was functioning. I can't really compare apples to apples between eXplorerKIT and startKIT though since it was two different scopes you used and the first one was pretty much incapable of checking the signal. I'm in California, United States of America(Can't find the email you'd sent to respond).

Re: Loading SPI_CLK is no good

Posted: Wed Oct 04, 2017 11:44 am
by aclassifier
I'll scope the startKIT. I have modified one to measure on, and it's tight (ie. short cables).

I'll try slower speed with the eXplorerKIT and my breakout board.

The code, for all practical means is XMOS code.
you'll have issues due to the XMOS driving the line but it not actually reaching the level in time.
I do believe the wifi library uses this mode of operation. In summary I'm not entirely sure what the issue is
I guess that the end is where I started, with a question of why the eXplorerKIT processor stops with no exception etc.
It just stops, by some fiddling with a scope. At least as seen from the logs. Bad rise time is no excuse.

There should be silicon enough in there to detect and issue something like a ET_CASCADED_CLOCK_VIA_PORT_PIN_HAS_STOPPED_PROCESSOR.
But I guess this would be an input to XMOS engineers. (Great, CA. So there is some time difference. Hi!-)

Re: Loading SPI_CLK is no good

Posted: Wed Oct 04, 2017 4:27 pm
by Gothmag
Some difference but I only sleep 3-4 hours a day so it's usually just an issue of free time. If you get no response before I have a chance, about 2 weeks, I'll buy a Wi-Fi slice and test your code out recording the SPI bus at the same time. I'm curious why the PC is getting corrupted. If you happen to test at slower SPI speeds please post the results.

Re: Loading SPI_CLK is no good

Posted: Wed Oct 04, 2017 5:57 pm
by aclassifier
Great!

In the meantime I'll do what I promised (slower speed scoped), and then make a subsitute for the XMOS WiFi sliceCARD named like a fairy tale:
"WiFi1500 sliceCARD" built with half an XMOS Slice Breakout Card LF1037KB from Axxon for an Adafruit ATWINC1500 WiFi Breakout board.
I'm on for more than two weeks for that. I'll tell about it on a blog note.

Re: Loading SPI_CLK is no good

Posted: Sat Oct 07, 2017 10:45 am
by aclassifier
I have now updated to 14.3.1. It did make my aquarium project run since [1] has been fixed. Great!

However, it did not help with this situation. I have now tried SPI_CLK 6.25 MHz by setting DEFAULT_SPI_CLOCK_DIV to 8 instead of 4 (the default 12.5 MHz) in spi_conf.h in module_wifi_tiwisl master. There is no change in behaviour at all.

--- PC=-1
Since you, Gothmag, was talking about investigating the
xrun: Program received signal ET_ILLEGAL_PC, Illegal program counter.
situation I have tried to repeat it now, without success (12.5 MHz). I now only have stops with no warning from xrun.
I did try to connect the BitScope again like in my initial posting. I have not tried to reuse the old code that I posted for download ("2017 09 20 A ..."). That code was indeed repeatable at the time. However, I cannot guarantee that it will be again, neither for me nor you. However, I will retry it with that code if you want me to. I have tried both with 14.3.0 and 14.3.1.
-> IDEA: it may be because I now use debug_print, which I didn't in that code. And the stack trace pointed towards that. But still, at the time I thought it strange that SPI_CLK 1M par 47pF to GND should cause this. There was something about the combination there. My gut feeling is that this has not been explained at all.

[1] http://www.teigfam.net/oyvind/home/tech ... ck_on_1430

--- Another matter
If, on the screen clips posted earlier curves look unlogical I may have swapped MISO/MOSI and SPI_CLK/MOSI so that they would have to be the other way around. But I believe it was the general rise times we were after, then that may be ok. Sorry