New ESP32-C3-Mini-1 INIT Event not received #119

[anoop18pant]

hi @mantriyogesh

We were not able to add comment in following issue https://github.com/espressif/esp-hosted/issues/119 so i have created this new issue to add our new findings.

hi Yogesh,

We have set SPI mode on ESP32(Slave in our case) to MODE 3 and Our host deriver(Master in our case) was also set to SPI mode 3. This setting was not working. After that we have changed it to following: We have set SPI mode on ESP32(Slave in our case) to MODE 0 and Our host deriver(Master in our case) was set to SPI mode 3. This setting started working.

We got the hint related to this from below link https://www.esp32.com/viewtopic.php?t=11578

Can you please confirm why this change fixes the issue ?

I have attached the waveform of ESP32 in all modes (Slave in our case) modes.zip

[mantriyogesh]

Hello @anoop18pant,

• Can you please close the stale open issues?

• Are you using SPI on IO_MUX pins only? Assuming you are using master branch, The MISO,MOSI,CLK,CS pins used at ESP32-C3 end has to be exactly matched to ESP32-C3 SPI Pins

• The issue you had pointed refers to ESP32, which has little different timing requirements as explained here. But as you are using ESP32-C3, Ideally, you should not face these timing issues, as underlying SPI driver doesn't have such limitation for ESP32-S2/ESP32-C3. But overall it looks like you are facing

• What is the SPI CLK frequency at which you are operating?

• Can you please give a trial to reduce the frequency to reduce to 5M?

• Another experiment, Can you please change the SPI mode to 2 at both the sides and confirm if that is working?

• I had checked the graphs, I could not decode the logs. Can you please send data something like 0xaa and set the pin names or explain the diagrams?

[mantriyogesh]

Additionally, Can you also confirm if CS line is facing spikes in between? This can be observed when you zoom-in the Keysight graphs. In logic analyser, you will see very small (unexpected) peaks in CS lines for very short period like 20ns. If these tristates observed, there is possibility of loosing synchronization in between Master and slave.

Interestingly, We had observed such rare problem only in case of MCU (STM32 case) only when the SPI lines used were non IO_MUX (i.e. different from ESP32-C3 SPI Pins above.

The additional setting, SPI_MASTER_KEEP_IO_STATE_ENABLE was only needed at host side when SPI pins at ESP32-C3 were non IO_MUX. It is important to note that SPI pins (at ESP32-C3) when used as IO_MUX pins (as above), this problem was not observed and hence above setting was not needed at all.

[anoop18pant]

Hi @mantriyogesh

What is the SPI CLK frequency at which you are operating?

We are using 1MHz Can you please give a trial to reduce the frequency to reduce to 5M? I guess not needed as already trying with 1Mhz

Another experiment, Can you please change the SPI mode to 2 at both the sides and confirm if that is working?

It also didnt worked

I had checked the graphs, I could not decode the logs.

We are adding new waveform with added one anotation.txt for signal name and color.

Additionally, Can you also confirm if CS line is facing spikes in between? This can be observed when you zoom-in the Keysight graphs.

We have checked but we could not observed also waveform are attached for your reference. esp32_waveform.zip

We are using ESP32C3 IO Mux pins only as mention in above diagram.

[mantriyogesh]

What is the actual bytes transferred ? I could see received bytes at MOSI is all zeros. Considering SPI mode 3, data sampled at falling edge, At MISO,

1. I could observe the data sampled as binary 1 0 1 1 0 1 0 Is this same as the input ? Or
2. Do you get output as 0 1 1 0 1 0 1 despite expected output being 1 0 1 1 0 1 0 ? (basically shifted by 1 symbol)

There ideally should be little gap in between MISO and falling edge. there is Dummy bit workaround in ESP documentation, which to be employed at host side. but I am not yet how can it be accomodated in Linux side code.

[anoop18pant]

hi @mantriyogesh ,

For your information we have set SPI_MODE1 on both side on Host side and ESP32C3 side and its working now.

This configuration is working with old ESP32C3 board as well new ESp32C3 boards.

Now we have captured the waveform for initial handshake and LE scan command executed from Host side.

Can you please confirm that if the waveform is correct as per ESP32C3 MODE1 definitions.

[mantriyogesh]

Hello @anoop18pant,

Good that you have got the breakthrough for this issue. Latest waveforms look good for SPI mode 1, where falling edge is used for data sampling. I hope the SPI mode is not mismatched in your configuration now.

Apologies for last SPI mode3 graph's explanation in earlier post, SPI mode 3 is sampled at rising edge. Considering that, even SPI mode 3 should have ideally worked with your provided graphs, without any changes. I will try to get some explanation for this.

[anoop18pant]

hello @mantriyogesh

Thank you for your response that for SPIMODE1 the waveform is correct.

But we want to be very sure that if we purchase more ESP32C3 modules it should work in this configuration otherwise it will be a big issue for us in production because we are not confident with the ESP32C3 behavior in SPIMODE3 so we want to understand the root cause with your help and support.

[mantriyogesh]

I understand your situation.

As per my understanding and experience, all C3 modules should behave exactly the same. These kinds of timing errors are dependent on both, the SPI master (host) and slave (ESP32-C3). Once they are addressed like you have addressed already, There should not be any more surprises as I can see.

Timings of SPI are also heavily dependent upon how the host side Linux kernel driver and hardware handles the SPI. As you have already adapted to the working SPI timing for Linux driver, I see no problems/surprises at this point of time.

As I can recollect, you are using iMX7. Can you please complete model name/number?

[mantriyogesh]

Hello @anoop18pant

We have raised this concern with internal driver team. But it might take little time to respond to this. Respond time should be around 2 weeks, I apologize for this delay.

We have received the graphs as well from you. But is it possible to get the logic analyser dump? Sometimes, the CS fluctuations are clearly detected in logic analyser than oscilloscope. If that is not feasible, that is okay, unless driver team needs it.

In any way, if the SPI mode 1 is working fine with your set of host and ESP32-C3, I do not see any significant issues ahead for SPI communication.

[anoop18pant]

@mantriyogesh

thank you for your support we are waiting for reply from ESp driver team to understand the issue