ESP32-C3 SPI pins

[freetoair]

Checklist

• [X] Checked the issue tracker for similar issues to ensure this is not a duplicate
• [X] Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• [X] Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

Hi, I have one doubt that I would like to clarify. Namely, I have successfully compiled the esp-host driver for Rockchip RV 1103 SoC and esp32-C3 firmware, but when I try to load esp32_spi.ko module with insmod esp32_spi.ko the process gets stuck and does not respond any further. Since everything went fine with the software I thought it was a connection between Luckfox-pico and the ESP32-C3 Super mini board. The pins that connect according to the Git hub instructions are different from those on the Super-mini board. Which pins should be considered valid? Can I find from the ESP-IDF project how the pin-mux is done in the project for the SPI version of the connection?

Actual behavior (suspected bug)

install wlan0

Error logs or terminal output

get stucked

Steps to reproduce the behavior

insmod esp32_spi.ko

Project release version

latest

System architecture

other (details in Additional context)

Operating system

Linux

Operating system version

Ubuntu 22.04

Shell

Bash

Additional context

Rockchip RV1103 SoC, kernel 5.10, arm7

[mantriyogesh]

1. Is it FG or NG?

2. What is the Git commit used at both side?

3. Please send the detailed logs at both sides.

4. Also attach the sdkconfig used at esp32-c3

[freetoair]

Ng

[mantriyogesh]

Issue in similar lines is fixed on master recently.

Please use same latest master commit at both sides and check if issue is fixed.

If not fixed, please get us logs above mentioned.

[freetoair]

sdkconfig.zip I will try to find that answer. In the meantime here is the sdkconfig

[freetoair]

It might be important the ESP32-C3 is constantly resetting itself

[freetoair]

Something is definitely wrong with the pin layout, when I disconnected the wire connecting CS0 it stopped resetting!

[mantriyogesh]

Without logs, we cannot comment anything.

[freetoair]

[mantriyogesh]

Your spi bus is already being used and not claimable. Check the porting guide stepwise to correct.

[freetoair]

New message : Are these pins on the ESP-hosted board or on the Linux board?

[mantriyogesh]

Any code inside 'host' subdirectory is for Linux.

You need to port disable spidev, which is still accessing your spi hardware.

Check all the porting steps carefully from the porting guide to get everything working.

[freetoair]

[mantriyogesh]

It looks like you are disabling spi instead of spidev?

Cross check what you are doing is correct. We can help to our knowledge, but device tree config is not in the scope for us.

[freetoair]

I only get this log when I reset the ESP32 board manually, and that's where it stops. Is the problem in RESET_PIN? There is no wlan0, when I try wifi_init I get a message that no such command exists. This is log from Linux machine.

[mantriyogesh]

Is your handshake and data ready pin tested to receive interrupts, as mentioned in porting guide?

[freetoair]

OK, now I'm going to test the transport layer !

[freetoair]

On Linux side:

On ESP side:

[freetoair]

Command is: [root@luckfox ko]# insmod esp32_spi.ko resetpin=56 raw_tp_mode=1

[freetoair]

I can now confirm that ESP-hosted has been successfully ported to Luckfox-pico. It works very well !

[mantriyogesh]

https://github.com/espressif/esp-hosted/issues/500#issuecomment-2387207239

Also other way round raw throughput could be tested..

[mantriyogesh]

Once you can confirm everything working as expected, we can close this issue.

[mantriyogesh]

By the way, you can change your spi frequency using 'clockspeed' module parameter to use up to 40MHz.

If you use jumper cables, you can stepwise increase by 1 MHz till saturate.

[freetoair]

Currently I use this setup:

And the final version will be with these components and short wires and then I will experiment with speeds

In any case, thanks for the help. Your project is very interesting and useful. regards !

[fearpro13]

Trying to setup same stuff with luckfox-pico-mini-b + esp32-c2 @freetoair btw what kind of esp programming board do you use? i ordered one but it was intended for something else(esp32, not esp32-c2)

[mantriyogesh]

@fearpro13 , it is little hard to understand how long the length of wires used from photo, but I assume they are very long. This could give issues. Try to keep<= 10cm for spi.

The slaves supported are ESP32, ESP32-C2/C3/C5/C5/S2/S3. But anyway I'll wait for @freetoair to answer.

If you have ESP32, you can use spi and sdio is also supported . for much higher throughout numbers, sdio performs better. But sdio needs PCB, also need external pull ups.

Check porting guide, for hardware expectations and porting guidelines.

[fearpro13]

@mantriyogesh Thanks for reply, but actually i don't need any help(at least now :D) , all stuff work as expected What would be the best option to point out that luckfox-pico is ported successfully?(btw it requires some tinkering with kernel/buildroot, i think it would be great to put some kind of guidance for porting it from @freetoair or @fearpro13)

[freetoair]

I apologize for the delay. The length of the wire is approximately 10cm. I didn't use the SDIO interface because I wanted to save it for the Ubuntu fileroot test. So far everything has been tried with buildroot. The test board is Luckfox-pico-mini B. If you think it would help someone I can send my kernel.config , buildroot.config and luckfox _init.sh . Honestly, the most difficult thing for me was the correct placement of the GPIO pins and the configuration of the SPI port in .dts and .dtsi files. I think everything will be much clearer in this picture:

[mantriyogesh]

Thank you for the setup picture.

Honestly, the most difficult thing for me was the correct placement of the GPIO pins and the configuration of the SPI port in .dts and .dtsi files.

Yes I understand the pain and know the cryptic nature of device tree.

Just like you need to turn on the light switch to see in a dark room, you need to configure the device tree for Linux to 'see' and communicate with your hardware. Without flipping that switch, the hardware remains invisible to the system.

Anyway, I would like to get feedback how we could improve upon. We also thought of adding example dts. But dts way cannot be generic enough. Plus, we also intentionally bias customer of any specific way of Linux configuration, as there are a lot other ways how you can use kernel module and integrate into or outside kernel. Any suggestions are truly welcome.

If you think it would help someone I can send my kernel.config , buildroot.config and luckfox _init.sh .

We would rather appreciate very much if you can just add up pull request with whatever changes you needed to do with specific kernel version and with exact hardware description (Linux). This pull request may not be directly pushed into master, and may stand closed, but the most essential part is there would be details logged in there, like device tree, script changes etc you did.

It would really help someone using the same board and educate them what exact steps you rather followed. As you are on the system right now, whatever info you have is all relevant and imp.

For example,

1. Esp used
   • hosted commit used
   • IDF commit used
2. Transport used
   • spi instance and chip select instance
3. Host used
   • host side commit used
4. Gpios needed
5. Device tree changes in short
6. Esp minicom or idf.py monitor logs
7. Host logs
   • uname -a output
   • dmesg log from start
8. Any changes you needed to code to make it work

It is really your choice, but it would help someone a lot time in future.

[freetoair]

Yes, of course, why not? I just need some time to finish the start shell script (S99network.sh) that should be added for automatic start at booting. I wrote it and it works but needs some tuning. @fearpro13 just one small note, on my ESP32 programming board the label on the IO14 board is wrong and in that place is IO12, maybe you got such a board.

[mantriyogesh]

Actually, I noted your chip used from picture and I was unsure why it is looking little different than the standard ones. But I let it go that thought, considering I might have not seen such.

But anyway if it ESP32 module, you can find the exact chip gpio placements from TRM and disregard, what is printed on the PCB on which ESP32 is mounted.

Another notable thing is, you have external antenna chip. So you might have to configure one for correct reception or transmit of signal. In general, there are two variants, one with in built antenna and other one you have. Both should be fine, but external antenna might need some extra hardware or tuning.

[mantriyogesh]

Can you take photo of ESP base pcb backside, if it describes something?

[freetoair]

Maybe we didn't understand each other well, the problem is not in the ESP32 module, but in the universal programming board. In the picture, I marked the pin that was printed incorrectly!

[fearpro13]

@freetoair

Could you please provide some details about your successful setup? 1)Host device tree config for SPI (the one that is 'deepest' in tree, ex: rv1103g-luckfox-pico-mini-b.dts) 2)Esp clock, host clock in MHZ 3)Pins used on host: CS, CLK, MISO, MOSI, Handshake, Dataready, Reset 4)SPI_MODE on esp, SPI_MODE on host 5)Tool used for wifi connectivity

Mine: 1) most parent one - rv1106.dtsi

    spi0: spi@ff500000 {
        compatible = "rockchip,rv1106-spi", "rockchip,rk3066-spi";
        reg = <0xff500000 0x1000>;
        interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
        #address-cells = <1>;
        #size-cells = <0>;
        clocks = <&cru CLK_SPI0>, <&cru PCLK_SPI0>, <&cru SCLK_IN_SPI0>;
        clock-names = "spiclk", "apb_pclk", "sclk_in";
        dmas = <&dmac 1>, <&dmac 0>;
        dma-names = "tx", "rx";
        pinctrl-names = "default";
        pinctrl-0 = <&spi0m0_cs0 &spi0m0_cs1 &spi0m0_pins>;
        status = "disabled";
    };

most child one - rv1103g-luckfox-pico-mini-b.dts

/* *********SPI********* */
/* SPI0_M0 */
&spi0 {
    status = "okay";
    esp32_spi: esp32_spi@0{
        status = "okay";
        spi-max-frequency = <50000000>;
        reg = <0>;
        spi-cpha;
        spi-cpol;
        //MODE(CPOL, CPHA): 0(0, 0); 1(0, 1); 2(1, 0); 3(1, 1)
        spi-lsb-first;
    };

//  spidev@0 {
//      status = "disabled";
//      spi-max-frequency = <50000000>;
//  };
};

2)Tried all clocks(from 1 to 16mhz) 3)48,49,51,50,52,53,56(CS, CLK, MISO, MOSI, Handshake, Dataready, Reset) 4) Tried all modes except SPI_MODE_0 5) wpa_supplicant & wpa_cli for wifi connectivity

All jumper wires are replaced with ~10CM soldered 24AWG, SPI wires are shortened to 4CM Sometimes it could let me go until scan stage but after that esp starts to reboot infinitely ESP is powered from 3v3(out) luckfox-pico port, could it be a power problem?

[mantriyogesh]

It could be possible that your Linux is enabled with power saving. Is the voltage & current is dropping while rebooting?

Can you please attach the both side logs while it rebooting?

[freetoair]

Ok, I'll send it when I'm done with daily work , after 5pm local time (GMT + 2 hours). regards !

[fearpro13]

@mantriyogesh

I will check voltage drop later

host.log esp.log

[mantriyogesh]

@fearpro13 ,

Is it possible to power ESP directly and check if you still face issues?

Also ensure grounds are connected in those two boards.

Lowering peak power can also be possible to even lower the scope of issue. Might be related : https://github.com/espressif/esp-hosted/issues/482#issuecomment-2364523346

[fearpro13]

@mantriyogesh

Issue is present only with host connected and scan command sent, once i do manual reset - issue disappears until next scan attempt Esp standalone doesn't have such issue

[mantriyogesh]

This issue is originally created by @freetoair .

If it is feasible, @fearpro13 , Can you please raise separate issue with detailed logs added there?

We can mark these two as related, for the reference..

[mantriyogesh]

In any case, it would be worth to check the voltage drop. In general, the ESP would have good power unless high power consumption is expected for operation like scan. It would be important to measure with some good meter or joulescope.

Alternatively, try to use separate and dedicated power supply and check if issue reproduces. Also, if you connect using some cable to dedicated power adaptor, please ensure it doesn't limit the power lower than ESP expected power range.

[imshadow]

Hi, I'm so excited! I'm also trying to use ESP32-C3 Super Mini as a network card for LuckFox Pico Mini B. I'm so happy to see someone here doing the same thing as me! Did you succeed? If you did, can you share your firmware? Thank you very much!