search

espressif / esp-hosted

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

Port ESP_hosted_fg to STM32H7 in SDIO transport problem #211

Open alireza3137 opened 1 year ago

alireza3137 commented 1 year ago

Hi I decide to port esp_hosted_fg to stm32h743Vi and use SDIO for transportation. In stm32h743Vi there is SDMMC instead of SDIO and its driver has some differences with SDIO driver for cortex M4.
So I am not sure about these two flags in sdio_ll.c file: 1- SDIO_FLAG_TXACT 2- SDIO_FLAG_RXDAVL

I have a guess for SDIO_FLAG_TXACT and it is SDMMC_FLAG_DPSMACT. But I have no idea about SDIO_FLAG_RXDAVL.

give any advices would be appreciated.

Thanks.

mantriyogesh commented 1 year ago

Hello @alireza3137

Thanks for asking this tricky question. While porting esp_hosted_fg to sdio transport with STM32F412ZGT6-Nucleo 144, luckily SDIO was available at HAL. I will have to check and get back to you.

But idea is that you might have to mould the lower HAL layer into sdio_ll.c and inherit code from h7 HAL

alireza3137 commented 1 year ago

Hi again @mantriyogesh Thanks for your reply. I try to use H7 driver to update your SDIO driver for ESP. I encounter another problem. I flash ESP32 as it is described in Wi-Fi connectivity Setup over SDIO. but in ESP uart terminal I get this messages repeatedly. Is it correct?

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:6940 ho 0 tail 12 room 4 load:0x40078000,len:15500 load:0x40080400,len:3844 entry 0x4008064c [0;31mE (68) boot.esp32: Chip CPU frequency rated for 160MHz, configured for 240MHz. Modify CPU frequency in menuconfig[0m ets Jun 8 2016 00:22:57

mantriyogesh commented 1 year ago

Can you please run 

$ python -m esptool -p <esp_port> flash_id

For example,

└(yogesh@) ~/code/h1/esp_hosted_fg/esp/esp_driver/network_adapter $ python -m esptool -p /dev/cu.usbserial-120 flash_id
esptool.py v4.5
Serial port /dev/cu.usbserial-120
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:80:28:d0
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

ESP32 supports 240MHz actually. I don't know why your ESP32 complains for 240MHz. Anyway, you can change the CPU freq from sdkconfig.defaults.esp32 file

$ cd esp_hosted_fg/esp/esp_driver/network_adapter
$ vim sdkconfig.defaults.esp32
$ #comment CONFIG_ESP32_DEFAULT_CPU_FREQ_240 and CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ line
$ rm -rf sdkconfig build
$ idf. py set-target <esp_chipset>
$ # I suppose you are using esp32, so <esp_chipset> will be esp32
$ idf.py build flash monitor
alireza3137 commented 1 year ago

I have checked in menuconfig and CPU freq is 240 MHz. the result of flash_id is:

esptool.py v4.5.1 Serial port com8 Connecting... Failed to get PID of a device on com8, using standard reset sequence. ....... Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting... Failed to get PID of a device on com8, using standard reset sequence. .. Detecting chip type... ESP32 Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 160MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 84:0d:8e:11:58:34 Uploading stub... Running stub... Stub running... Manufacturer: 20 Device: 4016 Detected flash size: 4MB Hard resetting via RTS pin...

mantriyogesh commented 1 year ago

Changed cpu freq works for you?

alireza3137 commented 1 year ago

No it does not work.

mantriyogesh commented 1 year ago

Can you please remove all cables and try flashing ESP-IDF hello world example, check if it works or not. Please attach failed log.

alireza3137 commented 1 year ago

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:6940 ho 0 tail 12 room 4 load:0x40078000,len:15500 load:0x40080400,len:3844 0x40080400: _init at ??:?

entry 0x4008064c I (29) boot: ESP-IDF v5.0.1 2nd stage bootloader I (29) boot: compile time 11:50:27 I (29) boot: chip revision: v1.0 I (32) boot.esp32: SPI Speed : 40MHz I (37) boot.esp32: SPI Mode : DIO I (41) boot.esp32: SPI Flash Size : 2MB I (46) boot: Enabling RNG early entropy source... I (51) boot: Partition Table: I (55) boot: ## Label Usage Type ST Offset Length I (62) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (69) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (77) boot: 2 factory factory app 00 00 00010000 00100000 I (84) boot: End of partition table I (89) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=082dch ( 33500) map I (109) esp_image: segment 1: paddr=00018304 vaddr=3ffb0000 size=01e7ch ( 7804) load I (112) esp_image: segment 2: paddr=0001a188 vaddr=40080000 size=05e90h ( 24208) load I (126) esp_image: segment 3: paddr=00020020 vaddr=400d0020 size=15b94h ( 88980) map I (159) esp_image: segment 4: paddr=00035bbc vaddr=40085e90 size=05984h ( 22916) load I (174) boot: Loaded app from partition at offset 0x10000 I (174) boot: Disabling RNG early entropy source... I (186) cpu_start: Pro cpu up. I (186) cpu_start: Starting app cpu, entry point is 0x4008104c 0x4008104c: call_start_cpu1 at C:/Espressif/frameworks/esp-idf-v5.0.1/components/esp_system/port/cpu_start.c:142

I (172) cpu_start: App cpu up. I (200) cpu_start: Pro cpu start user code I (200) cpu_start: cpu freq: 160000000 Hz I (200) cpu_start: Application information: I (205) cpu_start: Project name: hello_world I (210) cpu_start: App version: v5.0.1 I (215) cpu_start: Compile time: Mar 10 2023 11:50:05 I (221) cpu_start: ELF file SHA256: a6bc8aa74f2d6de9... I (227) cpu_start: ESP-IDF: v5.0.1 I (232) cpu_start: Min chip rev: v0.0 I (237) cpu_start: Max chip rev: v3.99 I (242) cpu_start: Chip rev: v1.0 I (247) heap_init: Initializing. RAM available for dynamic allocation: I (254) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (260) heap_init: At 3FFB2770 len 0002D890 (182 KiB): DRAM I (266) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (272) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (279) heap_init: At 4008B814 len 000147EC (81 KiB): IRAM I (286) spi_flash: detected chip: generic I (290) spi_flash: flash io: dio W (293) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (307) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU.

mantriyogesh commented 1 year ago

Is this hello world? Can you compare/send the sdkconfig for this flashed example and esp-hosted sdkconfig?

mantriyogesh commented 1 year ago

@alireza3137 Any update from your side?

alireza3137 commented 1 year ago

Hi I am in holiday. I will check it in next week and let you know about its result.

Thanks

alireza3137 commented 1 year ago

Hi I have changed the board and I think the ESP32 problem has been solved. But I port the SDIO transportation protocol and get this error:

SdioDriverInit:411 CMD5 timeout! SdioDriverInit:411 data timeout! SdioDriverInit:411 CMD5 timeout! SdioDriverInit:411 CMD5 timeout! SdioDriverInit:419 CMD5 timeout! SdioDriverInit:419 CMD5 timeout! SdioDriverInit:419 CMD5 timeout! SdioDriverInit:427 CMD3 timeout! SdioDriverInit:427 CMD3 timeout! SdioDriverInit:427 CMD3 timeout! Relative Card Address: 0x0000

and I have debugged the code and in SD_PowerON function in stm32h7xx_hal_sd.c errorstate when CMD55 is send is 4 that means HAL_SD_ERROR_UNSUPPORTED_FEATURE.

mantriyogesh commented 1 year ago

Actually, cmd5, 3 are important functions. Please check: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_sdio_slave_protocol.html#esp-sdio-slave-initialization

alireza3137 commented 1 year ago

Could you tell the pin diagram for sdio to host. Should some pull up resistor exist or not?

mantriyogesh commented 1 year ago

Hello @alireza3137 Sorry missed your ping. Yes the pull ups are required depending upon the ESP32 you use. Check: https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/api-reference/peripherals/sd_pullup_requirements.html#sd-pull-up-requirements

alireza3137 commented 1 year ago

hi @mantriyogesh I find it and I can connect to ESP32 through SDIO transportation protocol. but I get CRC error when data should be sent or received. I guess it is for not length matching for 4 data lines of SDIO and data corrupted during transceiver. I design a PCB and consider length matching for 4 data lines of SDIO and I am waiting for PCB will be ready.

Did you port lwIP in stm32 and port esp32 via SDIO transportation protocol and measured the throughput?

mantriyogesh commented 1 year ago

Hello @alireza3137

I have not ported lwip in official ESP-Hosted solution. However, I have ported the lwip into ESP32 as host & I think that could be be really used as reference. But that is not optimised (memcpy etc of buffers could be avoided to increase the throughput).

Please check: https://github.com/espressif/esp-hosted/issues/186#issuecomment-1490201090

the STM32 was ported with SDIO. Above solution was only tested with SPI (I will do SDIO as well on this) In any way, there is raw throughput measurement available, which allows you to measure the highest performance any stack can achieve (the SDIO max limit - anything beyond that need to optimise in SDIO in that case! ).

How raw throughput measurement helps? This has nothing to do with radio overhead etc. Many times the tcp/ip throughput limited by the Wi-Fi conditions etc. this helps in ruling out those conditions.

Regarding your main issue: CRC errors we also faced while doing solution. the reason might vary much, but the focus should be given to understand how software is not able to configure or miss to configure on correct time. For example,

  1. Transmission buffers are not yet ready but we write (or overwrite) data before tx is flagged to be complete
  2. Same case with RX, the Rx done when the data reading is not yet flagged to be complete (in middle of hardware buffers transfer)
  3. Unexpected tasks woken up and reading / writing data at same time without any locks

I think first thing is to get the data read or write (only one direction) then back to back and then simultaneously read - write. Raw throughput code may help in controlling this focused development.

alireza3137 commented 1 year ago

HI @mantriyogesh Thanks for your complete reply. Yes, you are right I have checked the RXFIFOHF and RXFIFOF registers while debugging and there is not any data in FIFO unfortunately. I am not sure about my pull up resistors. should all data line (DATA0, DATA1, DATA2, DATA3) and CMD line be pulled up by 10 Kohm resistors? I see this https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/api-reference/peripherals/sd_pullup_requirements.html#sd-pull-up-requirements but I am not sure yet.

mantriyogesh commented 1 year ago

yes actually you would need pull-ups. If you have any pull-ups host side, you can make them in effect and use them also. Intention is to have pull-up on the line (any one side is fine)

There is possibility that ST would be providing to configure these pull-ups on these lines. Before even going to the actual data, it is worth to check if you are able to get values at scratch registers first.

See Linux code writing https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/host/linux/host_driver/esp32/sdio/esp_sdio.c#L152-L153

Similar things should work first, for example, esp_hosted_fg/host/stm32/driver/transport/sdio/sdio_host.c -> STM32WriteReg(SDIO_FUNC_1, SDIO_REG(ESP_SLAVE_SCRATCH_REG_7), intr_mask);

alireza3137 commented 1 year ago

hi @mantriyogesh my PCB ready and I test sdio transport to stm32H7 and the debug is:

sdioclk=120000000Hz req_freq=10000000Hz out_freq=10000000Hz div=10 SdioDriverInit:411 data timeout! Relative Card Address: 0x0001 Card selected! RESP1_00001e00 Use 4bit bus width esp_slave_init_io 61 IOE: 0x02 esp_slave_init_io 66 IOR: 0x02 esp_slave_init_io 73 IOE: 0x06 esp_slave_init_io 79 IOE: 0x02 IE: 0x00 esp_slave_init_io: 92 IE: 0x07 esp_slave_init_io:97 Function 0 BSL: 0x00 esp_slave_init_io 103 Function 0 BSH: 0x02 esp_slave_init_io 108 Function 1 BSL: 0x00 esp_slave_init_io 114 Function 1 BSH: 0x02 esp_slave_init_io 119 Function 2 BSL: 0x00 Slave Initialization completed done

ESP-Hosted for ESP32 timed out while reading!!! sdio_driver_read_bytes 63 CMD53 error timed out while reading!!! sdio_driver_read_bytes 63 CMD53 error timed out while reading!!! sdio_driver_read_bytes 63 CMD53 error

any idea?

mantriyogesh commented 1 year ago

I think better to reduce frequency. There are two phases:

  1. init seq (to identify and communicate the sdio card params - happens at max 400KHz - with 1 bit SDIO
  2. normal message flow with higher freq like 40MHz (we never tried beyond this freq with ESP32)
mantriyogesh commented 1 year ago

You also would have to check on sdio logic analyzer.

Actually we are talking about creating STM32 SDIO driver from existing STM32 SD-MMC driver ! which is very tricky as STM32 have not created it for use. It should be do-able to avoiding MMC part and manually using only SDIO part.

Please have a look at https://github.com/espressif/esp-idf/blob/786851bfbd419530dbe2cf05d5cb3970fa1f15f9/components/driver/test_apps/components/esp_serial_slave_link/essl_sdio.c for a way to compare your sdio driver

alireza3137 commented 1 year ago

Hi again @mantriyogesh one more point: in FREERTOS when define any thread, queue, etc using Hal_Delay is not allowed. If Hal_delay used in this case code would be freeze. but in your code after define thread and queue in transport_init function the hard delay used in SdioDriverInit. could you send me the correct output of debug in SDIO transportation in MCU side?

mantriyogesh commented 1 year ago

intention of that delay is to not non-sleep-able delay or blocking time consumption in for loop. Intention is that task should not be unnecessarily switched at that point while polling.

I have it disconnected right now & in some other urgent work, I can get the logs as possible for you.

Crux is to get init_seq working. Only if init seq work, can go ahead, else everything will start printing as error.

alireza3137 commented 1 year ago

sorry I should type haL_delay instead of hard_delay in my previous comments. you use Hal_Delay in SdioDriverInit function in sdio_ll.c file and code will be freeze in this line.

mantriyogesh commented 1 year ago

oh okay. Noted. We did not get crash on the device we tested but anyway will try to remove it. Thanks for the input.

I think you can remove it from there & try (you might have already done now !)

I think essl_sdio_init() is little more readable to understand the init sequence.

alireza3137 commented 1 year ago

@mantriyogesh I cannot find essl_sdio_init(). where is it?

mantriyogesh commented 1 year ago

https://github.com/espressif/esp-hosted/issues/211#issuecomment-1517493764

alireza3137 commented 1 year ago

@mantriyogesh In Hal_SD_Init() function, there is a function whose name is HAL_SD_InitCard() which in this function there is a function whose name is SD_PowerON() return HAL_SD_ERROR_UNSUPPORTED_FEATURE. is it ok?

mantriyogesh commented 1 year ago

Can you please point me to web code? Else how to reach

mantriyogesh commented 1 year ago

For your current device

alireza3137 commented 1 year ago

@mantriyogesh https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/host/stm32/driver/transport/sdio/sdio_ll.c#:~:text=sd_init.ClockDiv%3B-,HAL_SD_Init,-(%26hsd)%3B

line 344

and

https://github.com/32blit/32blit-sdk/blob/master/32blit-stm32/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_sd.c#:~:text=errorstate%20%3D%20SD_PowerON(hsd)%3B line 514

alireza3137 commented 1 year ago

@mantriyogesh did you see?

mantriyogesh commented 1 year ago

Hello @alireza3137,

Sorry, It's off time here right now. Also, this is STM32 driver and it is been some time seen this driver. I will have to compare the supported driver driver and current st driver carefully.

Please spare me some time, will check and let you know in coming early weekday.

mantriyogesh commented 1 year ago

Hello @alireza3137 Give me some time, I will check and come back. Sorry It might take some time

alireza3137 commented 1 year ago

@mantriyogesh Hi Thanks for you time. I am waiting for your results.

alireza3137 commented 1 year ago

@mantriyogesh Hi Any updates?

mantriyogesh commented 1 year ago

sorry @alireza3137 I have not yet gone through.

I will check and get you back today/tomorrow.

alireza3137 commented 1 year ago

Hi @mantriyogesh Any updates ?

alireza3137 commented 1 year ago

@mantriyogesh Hi I am still waiting for your updates. Thanks

mantriyogesh commented 1 year ago

Extremely sorry @alireza3137 , I am into some other priority work. I will try to check this asap and reply back in couple of days.

mantriyogesh commented 1 year ago

sorry for this late. I can see many HAL code is changed for H7, but without checking on device, cannot actually confirm this.

Nevertheless, I checked and compared H7 Hal SD and F4 Hal SD

Can you please use logs and check is it failing because of which flag?

In general, the problem is we have to manually use only SDIO related code and filter out SDMMC related code. I still have hope but generally this kind of hardware driver debug and hack might good and worth time.

mantriyogesh commented 1 year ago

I don't think I have H7 board with me otherwise I would have even tried this. But anyway, as plain SDIO not supported by STM32 HAL, we have to hack and rewrite (just remove unwanted legs of mmc).

one api at the time to make it pass.