NG: Unable to communicate over SPI

[sergey-suloev]

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

I expected to have SPI communication work as before.

Actual behavior (suspected bug)

I started experiencing SPI communication issues since I have updated my codebase from the current master branch. The problem is that the NG host driver can't get bootup event anymore. I investigated the issue with logic analyzer and what seems strange to me is that ESP does not rise DATA-READY event before sending bootup packet. This is most likely the reason why IRS isn't called and the packet doesn't arrive. I verified all physical connections again and they all look fine. Could you get an advice what I should try further, please.

Error logs or terminal output

root@nanopi-a64-bookworm:~# dmesg | grep esp
[    6.655317] esp32_spi: esp_spi_probe: Probing ESP32 SPI-driver...
[    6.669734] esp32_spi: esp_spi_probe: raw-tp-mode was not specified
[    6.683096] esp32_spi: esp_spi_probe: ESP32 peripheral is registered to SPI bus [0], chip select [0], SPI Clock [1], SPI mode [0x02]

Steps to reproduce the behavior

NG host driver with ESP32

Project release version

latest

System architecture

other (details in Additional context)

Operating system

Linux

Operating system version

Debian Bookworm

Shell

Bash

Additional context

Allwinner A64 (sun50i) / NanoPi A64

Session1.sal.zip

[sergey-suloev]

[mantriyogesh]

1. First transaction is host driven always. It is not dependent upon data ready. Data ready comes in picture for second onwards transaction.
2. Is is code commented yet: https://github.com/espressif/esp-hosted/pull/425/files#diff-376c997542ed8caae30ab0a0d30cbff66a894804f1e92e8dcee9b1cc6aa3fcfdL963 ?

[sergey-suloev]

@mantriyogesh Do you mean hardware reset ?

https://github.com/sergey-suloev/esp-hosted/blob/8331c2ee5ae5fa3436beff39bb2bc7bfff957859/esp_hosted_ng/host/spi/esp_spi.c#L526

The hardware reset happens as usual in my hardware , I can see it from the led blinking. Again, I haven't changed my spi driver code , I only took your updates made in other host files + firmware.

I am not sure what you mean by "host driven". According to the code logic, the incoming data are only processed when queue_work is called and it is only called from ISRs. Another thing is that 2 attempts are made by ESP to send bootup message(you can see this from capture). And the second attempt is ignored too while data ready interrupt is triggered this time .

[mantriyogesh]

I think it would be better to try this with out modifying latest master code.

The sequence of the steps matter a lot

[mantriyogesh]

Did you get a chance to try the vanilla latest master?

[sergey-suloev]

Did you get a chance to try the vanilla latest master?

It is hard to integrate your driver in my system , because it is written old-style without device tree support. Do you see something wrong in my adaptation ?

In theory , I can try your driver but I need to find out GPIO numbers . I don't know how to do that at the moment.

root@nanopi-a64-bookworm:~# gpioinfo gpiochip0 - 256 lines: .... line 234: unnamed "handshake" input active-high [used] line 235: unnamed "dataready" input active-high [used]

Are the numbers 234 and 235 those you need for your driver ?

[mantriyogesh]

As you correctly pointed, we need to move to newer way to support device tree. however, we also need to ensure that we also support these using module params or hardcoding, which is currently supported in FG driver.

Worth to check what raspberry pi os you use : https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/docs/Linux_based_host/Troubleshoot.md#42-reset-pin-and-spi-gpio-numbering

For newer Raspberry Pi OS : https://github.com/espressif/esp-hosted/blob/ce00ca53189ffd52455dd5426d54f9be6fae1871/esp_hosted_fg/host/linux/host_control/rpi_init.sh#L13-L28

For older Raspberry Pi OS: https://github.com/espressif/esp-hosted/blob/ce00ca53189ffd52455dd5426d54f9be6fae1871/esp_hosted_fg/host/linux/host_control/rpi_init.sh#L33-L36

Are the numbers 234 and 235 those you need for your driver?

No. But then I am not sure which GPIOs do you use to connect. ideally, same GPIO numbers you can use. As you are already aware, the Slave Reset, Data Ready and Handshake GPIOs could be freely chosen by user. just make sure they are not already used.

[sergey-suloev]

I am not using rpi but allwinner platform . There is another napping scheme from platform specific numbers to universal gpio numbers . The numbers I sent you are probably not correct because they look like indexes within a specific gpio controller

[mantriyogesh]

understood.. The numbers are linear. abstraction to the actual controller.

[sergey-suloev]

There's probably a way to get the correct numbers using API and log them , I'll see if I can do it

[mantriyogesh]

I also don't wish to alarm you unnecessarily, but in past, in some specific allwinner board (t507) , we had to introduce some extra logic transition.

We observed that the spi driver was not processing every alternate message due to issue in spi linux driver.

465.patch.txt

[ ! IMPORTANT ]

This is based on some old commit. You cannot directly apply this change on your repo.

This is internal MR that we had, it has huge unnecessary changes for you. You can only focus on one file, network_adapter/main/spi_slave_api.c

check symbols, //reset_handshake_gpio();, wait_cs_deassert_sem and gpio_set_intr_type(gpio_num, GPIO_INTR_ANYEDGE); ignore pkt_num change. if you add pkt_num, please ensure you use at both sides, esp and host. as it is changing header.

Please disregard this, if you do not face any packet drop as such.

[sergey-suloev]

Some changes made recently causes my issue . It was working well for a long time before merging with latest master

[mantriyogesh]

can you please only point me to the latest commit that caused this issue? it might be worth to see the specific change, instead of complete driver.

[sergey-suloev]

@mantriyogesh could you provide some help on how to compile your driver, please ?

[mantriyogesh]

Actually, your code much resembles to FG, you have many FG code inherited.

https://github.com/sergey-suloev/esp-hosted/blob/8331c2ee5ae5fa3436beff39bb2bc7bfff957859/esp_hosted_fg/host/linux/host_control/rpi_init.sh#L431

Just change the rpi_init.sh for correct GPIOs and run it without args, it would print usage.

[sergey-suloev]

I was able to build and run the driver, here is my log

modprobe esp32_spi resetpin=101 clockspeed=10

dmesg

[ 243.462435] esp32_spi: loading out-of-tree module taints kernel. [ 243.677432] esp32_spi: spi_dev_init: Failed to obtain SPI master handle [ 244.096684] WARNING: Flushing system-wide workqueues will be prohibited in near future. [ 244.104784] CPU: 1 PID: 267 Comm: modprobe Tainted: G O 6.10.10-sunxi #stable [ 244.113330] Hardware name: FriendlyARM NanoPi A64 (DT) [ 244.118484] Call trace: [ 244.120941] dump_backtrace+0x94/0x114 [ 244.124715] show_stack+0x18/0x24 [ 244.128046] dump_stack_lvl+0x74/0x8c [ 244.131727] dump_stack+0x18/0x24 [ 244.135056] __warn_flushing_systemwide_wq+0x1c/0x28 [ 244.140041] spi_exit+0x80/0x250 [esp32_spi] [ 244.144370] esp_init_interface_layer+0x398/0x648 [esp32_spi] [ 244.150163] esp_init+0x14c/0x1000 [esp32_spi] [ 244.154655] do_one_initcall+0x44/0x28c [ 244.158508] do_init_module+0x60/0x21c [ 244.162279] load_module+0x1e98/0x2088 [ 244.166048] init_module_from_file+0x88/0xcc [ 244.170338] __arm64_sys_finit_module+0x244/0x33c [ 244.175064] invoke_syscall+0x48/0x114 [ 244.178835] el0_svc_common.constprop.0+0x40/0xe0 [ 244.183561] do_el0_svc+0x1c/0x28 [ 244.186895] el0_svc+0x34/0xd8 [ 244.189968] el0t_64_sync_handler+0x120/0x12c [ 244.194342] el0t_64_sync+0x190/0x194 [ 244.199802] esp32_spi: spi_init: Failed Init SPI device

I think this happens because SPI driver (spi-sun6i) isn't loaded . In my system SPI driver is loaded by device tree.

[sergey-suloev]

Ok, I loaded SPI driver and now your driver works. But still nothing happens. I can't receive bootup event. Hardware reset works well, I can see led blinking.

root@nanopi-a64-bookworm:~# dmesg | grep esp [ 45.923024] esp32_spi: loading out-of-tree module taints kernel. [ 46.139543] esp32_spi: spi_dev_init: ESP32 peripheral is registered to SPI bus [0],chip select [0], SPI Clock [10]

Here is how I found out the gpio numbers using my driver : esp_info("Acquired GPIO RESET: %d\n", desc_to_gpio(spi_ctx->reset)); esp_info("Acquired GPIO Handshake: %d\n", desc_to_gpio(spi_ctx->handshake)); esp_info("Acquired GPIO Data-Ready: %d\n", desc_to_gpio(spi_ctx->data_ready));

[ 6.829650] esp32_spi: esp_spi_probe: Acquired GPIO RESET: 101 [ 6.844312] esp32_spi: esp_spi_probe: Acquired GPIO Handshake: 234 [ 6.860157] esp32_spi: esp_spi_probe: Acquired GPIO Data-Ready: 235

And modified your driver :

define HANDSHAKE_PIN 234 //22

define SPI_IRQ gpio_to_irq(HANDSHAKE_PIN)

define SPI_DATA_READY_PIN 235 //27

define SPI_DATA_READY_IRQ gpio_to_irq(SPI_DATA_READY_PIN)

define SPI_BUF_SIZE 1600

And loaded the driver:

modprobe esp32_spi resetpin=101 clockspeed=10

[mantriyogesh]

Firmware loaded with same variant? On same commit?

[sergey-suloev]

Firmware loaded with same variant? On same commit?

Yes, sure

[mantriyogesh]

Let me know if you face issue on FG also.