ESP8266 Community Forum

- Mon Jul 11, 2016 1:56 am #50554 Hi Vicne, I think that SPI1U1 register is for the master works and not for the slave, so changing things there might not influence the result at all.

Async HTTP and WebSocket Server for ESP8266
Async TCP Library for ESP8266
ESP8266 Exception Stack Trace Decoder

- Tue Jul 12, 2016 8:12 am #50638

I think that SPI1U1 register is for the master works and not for the slave, so changing things there might not influence the result at all.

Mmmh. Not so cool
Well I might try to make it consider that the first byte received is a command... I will check that.
Thanks.

- Tue Jul 12, 2016 8:46 am #50641 Hi,

In the meantime, I performed more tests on AVR vs ESP, and here are the first results.

I first tried your "SafeMaster" sample with an added SPI.beginTransaction() call to make sure we use SPI Mode 0, and flashed it on both an AVR and an ESP, just to compare the MOSI signal wrt CS and CLK.
This part is reassuring:
AVR MOSI:

MasterAVR_SPIMode0.png

ESP8266 MOSI:

MasterESP_SPIMode0.png

There are differences (shorter CS pulse on ESP, MOSI is idle low on ESP, MOSI staying high for some time after the last bit on AVR), but all in all, they are both clear "MODE0" signals, with clock low in idle and MOSI changing on falling edge to be sampled on rising edge.
Very good.

Both of these signals are received without any problem by the unmodified (except for a serial dump of the answer) SPISlave sample you provided, as expected.

Things get a bit more complex on for the "answer" part using the MISO line.
I confirm your observation that the answer sent by your SPISlave sample is indeed received and understood correctly by the AVR :

Communication_seems_reliable_with_an_Arduino_master.png

Now looking at the scope, here's what we get:

Answer wrongly decoded by the scope on rising edge.png

Zooming on the end of question (ch4, left) and start of answer (ch3, right):

Same image with the end of question (ch4, left) and start of answer (ch3, right).png

Zooming more on MOSI, edges are OK, as above:

Zoom on end of question. Bits change on falling to be sampled on rising.png

But on MISO, edges are not OK, because bits change on rising clock edge to be sampled on falling:

Zoom on start of answer. Bits change on rising to be sampled on falling.png

Zooming more on the edge of MISO, we can see that the delay after the clock edge is really small (about 50ns):

Zoom more on start of answer - Delay for MISO settling is around 50ns.png

So my interpretateion of this is that the MISO signal is wrongly aligned, but as the slave ESP takes much less time to change the MISO after the clock edge than the AVR takes time to sample the MOSI after the edge. Consequently, I would think the AVR handles the MISO correctly by pure luck.

What do you think ?

Going on with the tests...

Kind regards,

Vicne

You do not have the required permissions to view the files attached to this post.

- Tue Jul 12, 2016 10:24 am #50652 Edit: this post was related to erratic behaviour due to a distorted clock signal (spurious oscillations on edges were wrongly counted as clock cycles by the ESP). Make sure you have clean signals and skip this post

Hi,
The next tests I performed are much more worrying and leave me puzzled...
I wanted to make sure that adding my "fix" that made inter-ESP communication work was harmless for AVR-ESP communication... but it's not.
I really don't understand why, but it seems that once I add the "SPI1C2 |= 1 << SPIC2MISODM_S;" line to the code, the slave ESP cannot emit correct replies anymore. They sometimes start with one character ("A") or two ("Al") OK, but the rest is garbage:

0-Corrupt_replies.png

You can also see that most replies are randomly aborted, leading to a stream of 0xFF (ÿ) characters

And the more I dig, the less I understand, because the scope clearly show that it's not an AVR decoding issue, it's the MISO signal that's corrupt:

1-Corrupt on scope too.png

(0x41 58 87 49 should really be 0x41 6C 69 76 for "Aliv")

I first checked the edges but they are OK:
Here's the end of command and start of answer:

3-end of question + start of answer.png

With a zoom on end of command, switching on falling and stable on rising clk edge:

4-zoom on end of question.png

and a zoom on start of answer, with the same convention:

5 - zoom on start of answer.png

Then I proceeded to decode the 3 first bytes of the answer by hand:
The first is OK:

6- 1st byte of reply.png

But then:

7- 2nd byte of reply - annotated.png

And then:

8- 3rd byte of reply - annotated.png

As one can see, the MISO is not just shifted by one bit, or jittery or noisy. It's a perfectly clean corrupt signal

That leaves me speechless because that's the part where the AVR doesn't do anything except drive the clock !
So how on earth can the same slave code reply differently if the clock is driven by an AVR vs an ESP ???

Clock timing, or amplitude, or noise could explain it, but they all look pretty OK to me. Moreover the slave ESP is able to read that AVR clock to decode the MOSI, but would be unable to use the same sync signal to drive the MISO ? That makes no sense...
And also, why does it work when the setting is left to transitions on the reverse edge ?

OK, I am going to let the slave untouched and flash an ESP with the exact same master code as the AVR and rewire it as the master to check that I can reproduce the good behaviour I had yesterday.

More on this soon...

Vicne

You do not have the required permissions to view the files attached to this post.

Last edited by Vicne on Fri Jul 15, 2016 10:30 am, edited 1 time in total.