ESP8266 Community Forum

- Sun Jul 10, 2016 10:15 am #50501

Fixed

I added the following line to the init code:

Code: Select allSPI1C2 |= 1 << SPIC2MISODM_S;

Nice catch !!!
Congrat !

- Sun Jul 10, 2016 12:26 pm #50510

Nice catch !!!
Congrat !

Just standing on shoulders of giants

One thing I have to grasp now is if and how the ESP can work as a slave without the "command-data" protocol.
The sample by Me-no-dev uses a command-data protocol, "command" being 01,02,03 or 04 followed by 00 to write status, write data, read data and read status, respectively. But the device I'm spying on seems to only generate the following 3 message formats :
08 FF FF (heartbeat)
54 x x x x (update display)
A4 x x (update leds)

Is there any reference available for those registers, other than the header files or D.av.id.'s blog ? It's weird to work with such a widespread component with virtually no datasheet...

Kind regards,

Vicne

- Sun Jul 10, 2016 4:29 pm #50527 Good catch on that option! Honestly I never tested ESP <-> ESP over SPI and have always used AVR Arduino for testing. Probably that is the reason I never saw such error and ended up in your situation.
The command bytes can be changed to something else through the registers, but the general protocol must stay the same. SPI1S3 is the register in question.

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

- Sun Jul 10, 2016 6:12 pm #50532 Hi, Me-no-dev,

Good catch on that option! Honestly I never tested ESP <-> ESP over SPI and have always used AVR Arduino for testing. Probably that is the reason I never saw such error and ended up in your situation.

Well, if the behaviour is not the same when the master is an AVR vs an ESP, then it would be interesting to check that the generated signal is really the same, because the issue could be in the clock generation logic in the SPI master code.

I took a look at that code and there's something weird in the code for setting the mode:

Code: Select all    if(CPOL) {
        SPI1P |= 1<<29;
    } else {
        SPI1P &= ~(1<<29);
        //todo test whether it is correct to set CPOL like this.
    }

This "TODO" comment, plus the fact that the field is accessed by number (29) and not by a #define'd name, does not sound reassuring.
The SPI1P register has no documented field in esp8266_peri.h and in the spi_register.h compiled by metalphreak, bit 29 is called SPI_IDLE_EDGE, but that register seems to be related to the CS pin, not the CLK polarity...

What is your opinion ?

What I intend to do tomorrow is rewire an Arduino, run the exact same "master" sketch and check that the generated signal (CS/CLK/command byte) has exactly the same shape.

In the meantime, I tested the communication in SPI_MODE3 (clock idle high), using the same "setDataMode" code in the SPISlave as in the master SPI library.
The situation showed a symmetric issue: the questions from the master were not understood by the slave until I added the equivalent workaround to read the master signal:

Code: Select allSPI1C2 |= 1 << SPIC2MOSIDM_S;

So definitely, there's a difference in default clock polarity handling...

The command bytes can be changed to something else through the registers, but the general protocol must stay the same. SPI1S3 is the register in question.

Oh I see. Thanks.
Well, I read that the SPI1U register can also be configured with no "command" phase at all (SPIUCOMMAND=0).
I am thinking of clearing all the "phases" except SPI_USR_MISO, and set the SPI_USR_MISO_BITLEN field to 24 bits in SPI1U1. Hopefully I should then retrieve the 3 first bytes of each message, and fortunately, the only 5-bytes message always ends with 2 null bytes, so probably I won't need them.
Alternately I can configure the length for 40 bytes and see if a "premature" end of message due to CS coming back also triggers a "data received" interrupt.

Mmmh, so many things to try, I guess it will take a little time

Anyway, thanks a lot for the pointers and the explanations.

Kind regards,

Vicne