[SOLVED] ESPNOW Packets Send Only AFTER De-Initilasation of Wireless Protocols

[hristesp]

SOLVED It works now! Turns out updating my toolchain, the wireless coexistence was set to being controlled by software which I was able to change from menuconfig

Hi everyone,

Since migrating my toolchain from IDF 4.3.1 to 5.1.2, I've had several fun changes I've had to make. None have been quite as interesting as this though - where instead of packets of data being sent every second via ESPNOW from a primary to secondary device, no information seems to send (from the primary), and just before the device goes to sleep, when any or all of esp_now, esp_wifi or NimBLE become de-initialized, those datapackets send, and the secondary device picks up the data in the fraction a second before the primary device goes to deep (or light sleep).

Code Highlights

When my primary device is connected to a phone, the following 1-second timer starts:

Code: Select all

// Create timers to send heartbeats periodically
void heart_beat_timer_start(){
	esp_timer_create_args_t heartbeat_timer_args;
	heartbeat_timer_args.callback = send_heartbeat_callback;
	heartbeat_timer_args.arg = NULL;
	esp_timer_create(&heartbeat_timer_args, &heartbeat_timer);
	esp_timer_start_periodic(heartbeat_timer, 1000000); // 1 second (in microseconds)
}

Which calls the following call-back (including logs):

Code: Select all

void send_heartbeat_callback(void* arg) {

	esp_err_t result = esp_now_send(tx_mac, heartbeat_packet, sizeof(heartbeat_packet));
	if (result == ESP_OK) 
	{
		ESP_LOGI("ESPNOW", "Packet sent");
	} else {
		ESP_LOGE("ESPNOW", "Error sending packet: %s", esp_err_to_name(result));
	}
}

The spooky thing is that on the serial monitor I see "ESPNOW Packet sent" every second, 32 times, then followed by "ESPNOW Error sending packet: ESP_ERR_ESPNOW_NO_MEM" every second.

The secondary device does not pick up on any of these packets being sent, but as soon as the primary device de-initiliases ESPNOW, ESP_WIFI and NimBLE the secondary device recieves several of these packets.

What I've Done

I have read through the migration guides, API guides and examples. I've also contacted Espressif who have been helpful, but have regularly told me to refer to the examples which I have an extremely similar/identical initialisation and deinitalisation process to.

My Question

I'm sharing this here to see if anyone else has come across an issue like this before, and also because this seems so bizarre as a symptom, I thought it would be interesting to the community to hear about to. Any help would be appreciated but hope people are vaguely entertained by the very least.

Many thanks in Advance

System Info

Devices: ESP32-C3-Mini-1

Computer OS: Ubuntu 22.04

IDE: VS Code

Tool-chain: IDF 5.1.2

[boarchuz]

https://docs.espressif.com/projects/esp ... structures

Also esp_now_send return value only indicates that the packet was internally queued successfully. You need to use the send callback to determine the outcome of sending it.

[hristesp]

https://docs.espressif.com/projects/esp ... structures

Also esp_now_send return value only indicates that the packet was internally queued successfully. You need to use the send callback to determine the outcome of sending it.

It works now as it turns out updating my toolchain, the wireless coexistence was set to being controlled by software which I was able to change from menuconfig - thanks for your help on this!