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