As you could read in last Log post if you follow this project I'm slowly coding a new IDF component to act as an epaper driver.
And in that process I'm reverse engineering GxEPD that is the library we actually use in CALE Firmware.
Actual branch is:

https://github.com/martinberlin/cale-idf/tree/refactor/oop

Since I'm refactoring the OOP part. And doing so I found out that even that I'm sending the same SPI commands and data than GxEPD some models are refusing to work. My father come up with a great idea:

If you have the face to reverse engineer an existing library then do it well!
Add an ESP32 SPI Slave sniffer and check exactly what the Epaper display receives.

So I put my hands at work:

That's basically the setup, the one labeled as Ein is the SPI slave and the other ESP32 the master. Now that was not going to be so easy as finding an existing working code and modifying it to my needs. First tried with Espressif own SPI slave example in IDF framework. For some reason, mostly because I'm still a beginner with the framework, it didn't work. And then found an Arduino-framework version that did but it was outdated and didn't compiled. So I fixed it:
https://github.com/martinberlin/esp32-spi-slave

Now doing a SPI slave with a CPU based chip is not a task for the faint of the heart. Is not a native SPI slave device and according to Espressif documentation

The ESP32 SPI slave peripherals are designed as general purpose Devices controlled by a CPU. As opposed to dedicated slaves, CPU-based SPI Devices have a limited number of pre-defined registers. All transactions must be handled by the CPU, which means that the transfers and responses are not real-time, and there might be noticeable latency.

And yes there is! Apart of that if you want to this in real-time and output the results via Serial, you will be limited by the UART speed, so the idea was to make the UART high like 500000 instead of default 115200 and also downgrade the SPI speed of the master.

It's working but still loosing 1 or 2 bytes each 44 which is still not good. In the way I found some strange things, like an 0x78 byte that is not sent by the master (otherwise epapers will not work) and also the challenging task of detecting what is a CMD ( in GxEPD a command puts additionally DC - data command GPIO low to send and high after sending) DATA puts only SS pin low/high (CMD toogles both SS & DC to send)
Doing that in real-time is not easy. Additionally I got a cheap Logic-Analyzer that will help me to find out why some of my Epapers won't update with my own class.

If it happens to tick your interest then check the CALE-IDF repository that is starting to take form and soon will be the component, CalEPD epaper driver, detached and pushed in it's own repository so also another people can use it.