search

espressif / esp-hosted

Hosted Solution (Linux/MCU) with ESP32 (Wi-Fi + BT + BLE)
Other
706 stars 169 forks source link

esp_hosted_fg: After ESP32C3 scans the wifi, the host cannot be analysis #345

Open gavin-hy opened 8 months ago

gavin-hy commented 8 months ago

hosted: STM32F4 slave: esp32c3 IDE：MDK(AC6)

After successfully testing the WiFi connection issues post MDK porting, including WPA2 and WPA3, I encountered a problem during the WiFi scanning functionality test. After ESP32C3 scanned nearby WiFi networks and transmitted the data to STM32, the STM32 got stuck in the ctrl_rx_thread task while waiting for the readSemaphore signal, causing a blockage that prevented task switching to the control_path_task for parsing the received data. This issue was identified through debugging STM32 step by step. Interestingly, when I ported esp_hosted in STM32CubeIDE, the STM32 could parse the WiFi list correctly. Both sides use the same esp_hosted component code, and projects are generated through STM32CubeMX, differing only in the compiler.

Subsequently, I created two new test tasks, task1 and task2, in MDK and synchronized them using semaphores. Upon retesting, after receiving the WiFi list data and waiting for the readSemaphore, the system could successfully switch tasks to task1 and task2, indicating the inability to switch tasks to control_path_task. I also attempted to increase the stack size of the control_path_task, but it had no effect.

Slave Log: image

Host Log image

Project Links： git@github.com:gavin-hy/ESP_Hosted.git

gavin-hy commented 8 months ago

The following two GIFs demonstrate the operation of STM32 after receiving the data. STM32CubeIDE: stm32cubeide

MDK(AC6) MDK(AC6)

mantriyogesh commented 8 months ago

well, the readSemaphore needs to be 'counting semaphore than binary'. This is because the RPC event and RPC response can come together sometimes.

All such issues are resolved in feature/esp_as_mcu_host branch. See the read semaphore creation:

master (original, un-updated): https://github.com/espressif/esp-hosted/blob/3d4f2f7b5913e951a3af2083c117a88d3638e429/esp_hosted_fg/host/stm32/port/src/platform_wrapper.c#L53

feature/esp_as_mcu_host: https://github.com/espressif/esp-hosted/blob/504f4f203c27d5a9e5e3bb1b34f7101e43cd8f59/host/drivers/serial/serial_drv.c#L215-L216

gavin-hy commented 8 months ago

Hi, @mantriyogesh I just modify the platform_wrapper.c, changing the binary to count, I still can't switch tasks in the MDK ! But in the STM32CubeIDE is ok. Doesn't seem like the issue lies here.

mantriyogesh commented 8 months ago

There might be multiple issues in master for mcu, is it possible to use feature/esp_as_mcu_host?

gavin-hy commented 8 months ago

Currently, feature/esp_as_mcu_host has not been ported to STM32 yet. Since we are only conducting tests, are there any demos already ported to STM32 that we can refer to?

gavin-hy commented 8 months ago

Hi, @mantriyogesh ,I intend to port the host of the feature branch to STM32 and have encountered numerous issues with memory that need to be resolved. Additionally, many function names have been changed. Are there any STM32 demos available for reference regarding this aspect?

mantriyogesh commented 8 months ago

Actually people have done it , but do not have the open sourced, May be I myself might need to do. How urgent this is for you?

My stm would anyway differ, but as such should not matter

gavin-hy commented 8 months ago

Due to issues with the master branch, I want to test the stability of this feature branch. If you only need to use the SPI driver for porting to STM32, approximately how long do you think it will take to complete? Do you have time for porting recently?

mantriyogesh commented 8 months ago

It might take a couple of weeks effort (considering other work in pipeline).

I had some intermediate branch, if you wish to refer to, where I had got lwip and everything very stable. It was also tested with STM32, so you should not have much problems there.

The reason I did not mention it earlier, that I did not want to confuse you with multiple branches more. If you wish to evaluate, https://github.com/espressif/esp-hosted/issues/270#issuecomment-1787336047 has 2020.10.31__gh270_interim_branch_DoNOTUseInProduction.tgz.

Now I understand the naming the patch had wrong date, this work was done in 2023, but the name is starting with 2020! Anyway disregard the name, you can try this branch.

Also, this branch was tested specifically on SPI so you should expect better things than master.

However, this branch is old and feature/esp_as_host_mcu is the latest branch. Alternative is wait for two weeks.

gavin-hy commented 8 months ago

That's fine, I can wait, as I also need to carry out Bluetooth-related testing here. Looking forward to seeing the latest STM32-related demos.

gavin-hy commented 8 months ago

Hi, @mantriyogesh, How's the progress on the new version of the host? I can't wait to try the latest version.

mantriyogesh commented 8 months ago

Hello @gavin-hy ,

I will update you today with current status.

mantriyogesh commented 8 months ago

Current status is that with STM32F469, I had the base spi working. Some things working, some failing.

Working: Transport layer testing is okay, I get 3.5 Mbps 'transport' layer throughput. (It is not iperf) Either direction.

Issues: The low data rate is because this is older stm32, where fifo is '1 data' and not optimised. The time wastage in spi clocks released is high. Spi master, host side issue. Dma could help (not planned right now)

But anyway, without lwip, things are just fine.

With lwip, I get memory full errors. I suspect it is above ESP-Hosted, but it is eating good time. I will need to find a better tool, to find a leak and root cause of leak.

I had tried H7 for spi. But I get very strange issue that spi master driver is releasing mosi line very late and that too after starting the clock at driver. But this was something very wrong, so I abandoned h7 for now.

H7 was pretty good, as there were '16 data' fifo available, which would not waste the spi clock (less gaps). Anyway this issue also I have to check later.

In summary, the port later is available, but it wouldn't much help in current state to you. I would need some time to get this perfect. Meantime, if you wish to look the directory structure and port later code, I can send you as a patch

gavin-hy commented 8 months ago

Is your latest port based on the feature branch? If so, Please send me a patch file first.

mantriyogesh commented 8 months ago

Yes. That's right. Let me send you in some time.

mantriyogesh commented 8 months ago

Sorry, got busy in some other activities.

Base commit: 504f4f203c27d5a9e5e3bb1b34f7101e43cd8f59 Patch: 0001-STM32-SPI-port-for-STM32F4.patch

Please note:

  1. It is big patch
  2. LWIP has some crashes due to memory issues
  3. 'raw' throughput i.e. transport throughput is working fine for Tx/Rx.
  4. The raw throughput is ~ 3.7Mbps either case, limited to the time spaces watsed by the host on SPI clock ( verified by the salae analyzer)
  5. readme.txt can be referred for your setup instructions
  6. The port is verified on STM32F469NIH6U, you can try on yours by changing the 'ioc' file
gavin-hy commented 8 months ago

@mantriyogesh ,Thank you! When I try to compile in STM32CubeIDE, I find that I cannot link the files under 'common' and 'hosted'. I noticed there is an issue with the paths shown in the screenshot below, but even after correcting the paths, I still couldn't compile successfully. It appears that there is a lock on the files！ image image

mantriyogesh commented 8 months ago

@gavin-hy

This code I had given is not perfect, as it is still in development. BTW, it is a warning symbol.

Option 1) You can also manually exit the stm32cubeide, copy the 'ioc' '.cproject' and '.project' file in correct workspace subfolder, change '.project' content so that 'CODE_BASE' variable is pointing to 'esp_hosted_fg' directory. and re-open the stm32cubeide.

The icons will go off once you clean the project and build again (if CODE_BASE variable is correct)

Option 2) create a fresh workspace (don't use this one now)

in fresh workspace, import project using ioc, close stm32cubeide,

I had not changed the windows prepare_project.bat script as such, you may want to change in similar lines to prepare_project.sh. Ignore these warnings, just follow readme.txt, to close, run script prepare_project.sh as shown in readme.txt, CODE_BASE should be populated. Now re-open the stm32cubeide same workspace.

Note:

  1. Ignore all above configs line STATION etc, as now the main config file is host/port/stm32/freertos/esp_hosted_config.h
  2. path warnings despite correct CODE_PATH may be seen, go away only if if you clean and build the project (if CODE_BASE is correct)
gavin-hy commented 8 months ago

Hi, @mantriyogesh Can you upload a complete project code or compressed file to GitHub? I've tried both methods, but neither has been successful. The first method requires too many modifications because the paths are completely different from the new version and the main branch! I tried the second method for a long time, but still couldn't succeed!

mantriyogesh commented 8 months ago

Understood. Let me send you the tar. But with tar also, the path(s) will point to my machine, which you might want to change.

mantriyogesh commented 8 months ago

Without .git files (as otherwise file size restrictions)

esp_hosted_feature_branch_stm_port.tgz

Full workspace: workspace_19mar24.tgz

mantriyogesh commented 8 months ago

Will wait for your building success. As I greped my name (as part of home user path), it returned me a lot of files:

 I  ~/S/workspace_19jul_master_1  grep -iIrs 'yogesh' -l                                                                   284ms  Tue Mar 19 14:17:34 2024
./stm_spi_host/.project
./stm_spi_host/.cproject
./stm_spi_host/Debug/Drivers/STM32F4xx_HAL_Driver/Src/subdir.mk
./stm_spi_host/Debug/Core/Startup/subdir.mk
./stm_spi_host/Debug/Core/Src/subdir.mk
./stm_spi_host/Debug/host/virtual_serial_if/src/serial_if.d
./stm_spi_host/Debug/host/virtual_serial_if/src/serial_if.su
./stm_spi_host/Debug/host/virtual_serial_if/src/subdir.mk
./stm_spi_host/Debug/host/control_lib/src/ctrl_api.su
./stm_spi_host/Debug/host/control_lib/src/ctrl_core.su
./stm_spi_host/Debug/host/control_lib/src/ctrl_core.d
./stm_spi_host/Debug/host/control_lib/src/ctrl_api.d
./stm_spi_host/Debug/host/control_lib/src/subdir.mk
./stm_spi_host/Debug/host/components/src/esp_queue.d
./stm_spi_host/Debug/host/components/src/subdir.mk
./stm_spi_host/Debug/host/components/src/esp_queue.su
./stm_spi_host/Debug/host/stm32/app/app_main.su
./stm_spi_host/Debug/host/stm32/app/app_main_api.d
./stm_spi_host/Debug/host/stm32/app/app_main.d
./stm_spi_host/Debug/host/stm32/app/subdir.mk
./stm_spi_host/Debug/host/stm32/app/data/arp_server_stub.su
./stm_spi_host/Debug/host/stm32/app/data/subdir.mk
./stm_spi_host/Debug/host/stm32/app/data/arp_server_stub.d
./stm_spi_host/Debug/host/stm32/app/app_main_api.su
./stm_spi_host/Debug/host/stm32/app/control/control.d
./stm_spi_host/Debug/host/stm32/app/control/control_utils.su
./stm_spi_host/Debug/host/stm32/app/control/control_utils.d
./stm_spi_host/Debug/host/stm32/app/control/subdir.mk
./stm_spi_host/Debug/host/stm32/app/control/control.su
./stm_spi_host/Debug/host/stm32/driver/transport/transport_drv.d
./stm_spi_host/Debug/host/stm32/driver/transport/spi/spi_drv.su
./stm_spi_host/Debug/host/stm32/driver/transport/spi/spi_drv.d
./stm_spi_host/Debug/host/stm32/driver/transport/spi/subdir.mk
./stm_spi_host/Debug/host/stm32/driver/transport/transport_drv.su
./stm_spi_host/Debug/host/stm32/driver/transport/subdir.mk
./stm_spi_host/Debug/host/stm32/driver/network/netdev_stub.su
./stm_spi_host/Debug/host/stm32/driver/network/netdev_api.d
./stm_spi_host/Debug/host/stm32/driver/network/netdev_stub.d
./stm_spi_host/Debug/host/stm32/driver/network/netdev_api.su
./stm_spi_host/Debug/host/stm32/driver/network/subdir.mk
./stm_spi_host/Debug/host/stm32/driver/serial/serial_ll_if.su
./stm_spi_host/Debug/host/stm32/driver/serial/serial_ll_if.d
./stm_spi_host/Debug/host/stm32/driver/serial/subdir.mk
./stm_spi_host/Debug/host/stm32/common/common.d
./stm_spi_host/Debug/host/stm32/common/common.su
./stm_spi_host/Debug/host/stm32/common/util.d
./stm_spi_host/Debug/host/stm32/common/stats.d
./stm_spi_host/Debug/host/stm32/common/util.su
./stm_spi_host/Debug/host/stm32/common/subdir.mk
./stm_spi_host/Debug/host/stm32/port/src/subdir.mk
./stm_spi_host/Debug/host/stm32/port/src/platform_wrapper.d
./stm_spi_host/Debug/host/stm32/port/src/platform_wrapper.su
./stm_spi_host/Debug/makefile
./stm_spi_host/Debug/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/subdir.mk
./stm_spi_host/Debug/Middlewares/Third_Party/FreeRTOS/Source/portable/MemMang/subdir.mk
./stm_spi_host/Debug/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS/subdir.mk
./stm_spi_host/Debug/Middlewares/Third_Party/FreeRTOS/Source/subdir.mk
./stm_spi_host/Debug/common/esp_hosted_config.pb-c.d
./stm_spi_host/Debug/common/protobuf-c/protobuf-c/protobuf-c.su
./stm_spi_host/Debug/common/protobuf-c/protobuf-c/subdir.mk
./stm_spi_host/Debug/common/protobuf-c/protobuf-c/protobuf-c.d
./stm_spi_host/Debug/common/esp_hosted_config.pb-c.su
./stm_spi_host/Debug/common/subdir.mk
./.metadata/.log4j.xml
./.metadata/.ide.log
./.metadata/.plugins/org.eclipse.cdt.ui/stm_spi_host.build.log
./.metadata/.plugins/org.eclipse.cdt.ui/global-build.log
./.metadata/.log

I am not sure if this change to your path can be handled through ecllipse (stm32cubeide) or not.

gavin-hy commented 8 months ago

@mantriyogesh , A big Thanks! I have successfully compiled it! Thank you very much!

mantriyogesh commented 8 months ago

IOC needs port for your STM32 MCU. port layer would have os_wrapper.[c|h] files. These files would still need port as per your:

  1. used SPI instance for your SoC
  2. used USART instance
  3. GPIOs for Reset pin, SPI pins, Handshake, Data ready pins, clock etc (most changes would be in IOC porting, some associated in os_wrapper, to let code know, what to be used)
mantriyogesh commented 7 months ago

Did you able to recreate the transport 'raw' throughput test?

gavin-hy commented 7 months ago

@mantriyogesh , After successfully compiling, I didn't test the code. There are too many files in this version, and according to your throughput tests, it doesn't seem ideal! I want to handle this in the simplest way possible, without using protobuf and serialif as intermediate layers, directly exchanging data through LWIP memory buffer and ESP32C3, because we only use STA mode. Modifying MAC and other features, I find esp-hosted too cumbersome!

mantriyogesh commented 7 months ago

Thank you for the feedback and I respect your decision, but some things I think should clarify :

your throughput tests, it doesn't seem ideal

As mentioned in an earlier post, 

 4. The raw throughput is ~ 3.7Mbps either case, limited to the time spaces watsed by the host on SPI clock ( verified by the salae analyzer)

SPI clock is controlled completely by host and slave doesn't have any say in it. Also they depend upon STM32 version. Latest STM32 may have fixed it, but IOC and STM32 are too dependent upon specific flavour. If you realize, that was the intention we used ESP32 as host with a port layer.

without using protobuf and serialif

Protobufs and json are standard ways to serialise data. this means, irrespective of the application or architecture, the data will be shared from one node to other, with correct interpretation. serial if is thin layer, to facilitate unique 'if_type' to separate control packet interface and data packet interface.

directly exchanging data through LWIP memory buffer and ESP32C3

I think you have confused with ESP_SERIAL_IF and ESP_STA_IF. ESP_SERIAL_IF is control interface, which is used through protobuf. These are RPC mechnisms, so they need serialised data. ESP_STA_IF is not serialised. This is data path. We do not need any serialization and directly sent to slave and sent out to Wi-Fi, without serialization.

Modifying MAC and other features All the ready to use APIs are available for station, just similar to esp_wifi: https://github.com/espressif/esp-hosted/blob/8fa03648aa60b6fa100e9e996a1eaaad84cbd06b/host/drivers/rpc/wrap/rpc_wrap.h#L38-L77 you can spot rpc_wifi_set_mac() in these.

Practically, it would run out of the box to setup station mode and use data path using lwip at host, without caring much about slave and underlying rpc implementation.

mantriyogesh commented 7 months ago

Please refer to https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/docs/Linux_based_host/linux_hosted_design.svg for understanding for separation of control and data path.

This is Linux image, but the technically it is similar to mcu, except kernel-user space separation (as everything works together in MCU)

gavin-hy commented 7 months ago

Hi, @mantriyogesh , you can reference this https://github.com/FreeRTOS/iot-reference-stm32u5/tree/main/Common/net/mxchip , the WiFi chip function is similar with the ESP, But the way in this code is much easier to use.That's why I wanted to use this.