Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opencores Emac Receive Buffer issue with QEMU (IDFGH-14620) #15372

Open
2 tasks done
halilbengu opened this issue Feb 11, 2025 · 0 comments
Open
2 tasks done

Opencores Emac Receive Buffer issue with QEMU (IDFGH-14620) #15372

halilbengu opened this issue Feb 11, 2025 · 0 comments
Labels
Status: Opened Issue is new

Comments

@halilbengu
Copy link

halilbengu commented Feb 11, 2025

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • [] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

My esp-idf is not the latest version because of some QEMU issues I had at the start of the project. Currently using ESP-IDF: v5.3

General issue report

Hi,

I'm experiencing an issue with ESP32 emulation in QEMU where I get the error "E (104160) opencores.emac: no mem for receive buffer".

I have a setup as explained here (https://github.com/espressif/esp-toolchain-docs/blob/main/qemu/esp32/tap-networking.md). I am starting a docker container and set the network configurations. ESP emulations are assigned IP addresses without a problem from the DHCP server. I am training the a model on the devices and then devices are exchanging neural network parameters, and after a few rounds of training and communication, the EMAC buffer error occurs.

xTaskCreatePinnedToCore(tcp_server_task, "tcp_server", STACK_SIZE, (void*)AF_INET, TASK_PRIORITY, NULL, 0);

I am starting my tcpserver with the line (I had a problem with PSRAM which I fixed it pinning the task to a core). I tried to increase the CONFIG_EXAMPLE_ETHERNET_EMAC_TASK_STACK_SIZE value but regardless, I get the receive buffer error around same time which makes me think it doesn't make any difference. Below is my ethernet register function, I am also setting up a random Mac address at the start, if I keep the Mac value as default all of the devices have the same value and they are assigned to the same ip address.

void register_ethernet(void)
{
    uint8_t random_mac[6];  // Example MAC address
    random_mac[0] = 0x02;  // Set the first byte as '02' (locally administered address)
    random_mac[1] = esp_random() & 0xFF;  // Random byte 1
    random_mac[2] = esp_random() & 0xFF;  // Random byte 2
    random_mac[3] = esp_random() & 0xFF;  // Random byte 3
    random_mac[4] = esp_random() & 0xFF;  // Random byte 4
    random_mac[5] = esp_random() & 0xFF;  // Random byte 5
    esp_err_t err = esp_base_mac_addr_set(random_mac);

    nvs_flash_init();

    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());
    esp_netif_config_t cfg = ESP_NETIF_DEFAULT_ETH();
    eth_netif = esp_netif_new(&cfg);

    eth_mac_config_t mac_config = ETH_MAC_DEFAULT_CONFIG();
    mac_config.rx_task_stack_size = CONFIG_EXAMPLE_ETHERNET_EMAC_TASK_STACK_SIZE;
    
    eth_phy_config_t phy_config = ETH_PHY_DEFAULT_CONFIG();
    esp_eth_mac_t *mac = esp_eth_mac_new_openeth(&mac_config);

    esp_eth_phy_t *phy = esp_eth_phy_new_dp83848(&phy_config);

    esp_eth_config_t config = ETH_DEFAULT_CONFIG(mac, phy);
    ESP_ERROR_CHECK(esp_eth_driver_install(&config, &eth_handle));
    ESP_ERROR_CHECK(esp_netif_attach(eth_netif, esp_eth_new_netif_glue(eth_handle)));
    ESP_ERROR_CHECK(esp_event_handler_register(ETH_EVENT, ESP_EVENT_ANY_ID, &event_handler, NULL));
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_ETH_GOT_IP, &event_handler, NULL));
    ESP_ERROR_CHECK(esp_eth_start(eth_handle));

}

I tried increasing the task stack size but it didn't change anything. I also checked the remaining stack size and never goes below around 4kbytes. I tried adding delay to my socket communication which also didn't fix the issue and regardless of the delay, it still crashes around the same time on each run which makes me think buffer is not cleared. Does anyone have an idea? thanks for the help in advance.

Also here is my boot log for people who can understand something from it.

root@e7d2a75f72f9:/project# qemu-system-xtensa -nographic -machine esp32 -m 4 -drive file=/project/flash.bin,if=mtd,format=raw -nic tap,model=open_eth,ifname=tap1,downscript=no,script=no
Adding SPI flash device
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x12 (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:7176
load:0x40078000,len:15564
ho 0 tail 12 room 4
load:0x40080400,len:4
load:0x40080404,len:3904
entry 0x40080640
I (801) boot: ESP-IDF v5.3 2nd stage bootloader
I (804) boot: compile time Feb 10 2025 14:47:25
I (805) boot: Multicore bootloader
I (844) boot: chip revision: v0.0
I (850) boot.esp32: SPI Speed      : 40MHz
I (851) boot.esp32: SPI Mode       : DIO
I (852) boot.esp32: SPI Flash Size : 4MB
I (872) boot: Enabling RNG early entropy source...
I (896) boot: Partition Table:
I (897) boot: ## Label            Usage          Type ST Offset   Length
I (898) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (901) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (902) boot:  2 factory          factory app      00 00 00010000 00300000
I (915) boot: End of partition table
I (928) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=2351f8h (2314744) map
I (1550) esp_image: segment 1: paddr=00245220 vaddr=3ffb0000 size=028ech ( 10476) load
I (1601) esp_image: segment 2: paddr=00247b14 vaddr=40080000 size=08504h ( 34052) load
I (1685) esp_image: segment 3: paddr=00250020 vaddr=400d0020 size=3f988h (260488) map
I (1824) esp_image: segment 4: paddr=0028f9b0 vaddr=40088504 size=097e4h ( 38884) load
I (1898) boot: Loaded app from partition at offset 0x10000
I (1899) boot: Disabling RNG early entropy source...
I (1943) quad_psram: This chip is ESP32-D0WD
I (1975) esp_psram: Found 4MB PSRAM device
I (1975) esp_psram: Speed: 40MHz
I (1976) esp_psram: PSRAM initialized, cache is in low/high (2-core) mode.
I (2001) cpu_start: Multicore app
I (3709) cpu_start: Pro cpu start user code
I (3713) cpu_start: cpu freq: 160000000 Hz
I (3716) app_init: Application information:
I (3716) app_init: Project name:     esp-adfo
I (3717) app_init: App version:      1
I (3718) app_init: Compile time:     Feb 11 2025 15:10:07
I (3720) app_init: ELF file SHA256:  7a520e36ec59edcc...
I (3721) app_init: ESP-IDF:          v5.3
I (3722) efuse_init: Min chip rev:     v0.0
I (3723) efuse_init: Max chip rev:     v3.99
I (3723) efuse_init: Chip rev:         v0.0
I (3727) heap_init: Initializing. RAM available for dynamic allocation:
I (3736) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (3739) heap_init: At 3FFBE1B8 len 00021E48 (135 KiB): DRAM
I (3740) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (3741) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (3742) heap_init: At 40091CE8 len 0000E318 (56 KiB): IRAM
I (3751) esp_psram: Adding pool of 4096K of PSRAM memory to heap allocator
I (3853) spi_flash: detected chip: gd
I (3871) spi_flash: flash io: dio
I (3907) main_task: Started on CPU0
I (3917) esp_psram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (3927) main_task: Calling app_main()
This Device's ID: 742!
I (4257) esp_eth.netif.netif_glue: 02:59:a8:1e:bb:ac
I (4267) esp_eth.netif.netif_glue: ethernet attached to netif
I (6387) esp_netif_handlers: eth ip: 172.17.0.11, mask: 255.255.0.0, gw: 172.17.0.1
TCP Server Created!
@espressif-bot espressif-bot added the Status: Opened Issue is new label Feb 11, 2025
@github-actions github-actions bot changed the title Opencores Emac Receive Buffer issue with QEMU Opencores Emac Receive Buffer issue with QEMU (IDFGH-14620) Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Opened Issue is new
Projects
None yet
Development

No branches or pull requests

2 participants