ESP32 Forum

Hello

In my project, esp32 is operated by freertos.
At core 0, wifi, Bluetooth, and ble mesh are working, but sometimes mesh dies. One of the logs that appear at this time is "scan_evt timeout". Can I know what happened?

Power sources are supplied at 5v, 700ma at smps.
And is the smps in use running out of power to withstand 700ma?

I'm also curious about the maximum power consumption in the above situation.

You didn't state what ESP32 module you were using.
5v @ 700ma is pretty high. How hot is your 3.3v onboard regulator getting, can you keep your finger on it ?

username wrote: ↑

Fri Nov 05, 2021 4:57 am

You didn't state what ESP32 module you were using.
5v @ 700ma is pretty high. How hot is your 3.3v onboard regulator getting, can you keep your finger on it ?

I'm using esp32 WROOM 32D.

The chip temperature was not high. It didn't matter if I touched it with my hands.
Is there any possibility that the esp32 chip might have happened when the SMPS didn't provide power for a moment when a large amount of the esp32 chip?
We are analyzing the cause in many ways...

Are you using a WROOM32D module? Just checking: do you have a LDO or something that generates 3.3V in the power supply path, or are you feeding 5V directly into that module?

ESP_Sprite wrote: ↑

Sat Nov 06, 2021 3:52 am

Are you using a WROOM32D module? Just checking: do you have a LDO or something that generates 3.3V in the power supply path, or are you feeding 5V directly into that module?

Yes, I'm using the WROOM32D module. Power directly applies 5v. Only status LEDs are connected to the power line and there are no other devices.

And if wifi, Bluetooth, and ble mesh are being used in core 0, is there a possibility of a problem in this case?
In the above case, I wonder if only the ble mesh task can stop the operation.
One of the cases that occurred was a problem in that Wi-Fi was connected but Ble mesh communication was not possible.

Jay_EEE wrote: ↑

Mon Nov 08, 2021 4:07 am

Yes, I'm using the WROOM32D module. Power directly applies 5v.

Well, there's your problem. While our devboards have an on-board LDO and can accept 5V on the designated input pin, the modules only work on a voltage range around 3.3V, and you run the risk of damaging it if you run it at 5V. Chances are your chip is (partially) fried.

ESP_Sprite wrote: ↑

Mon Nov 08, 2021 4:53 am

Jay_EEE wrote: ↑

Mon Nov 08, 2021 4:07 am

Yes, I'm using the WROOM32D module. Power directly applies 5v.

Well, there's your problem. While our devboards have an on-board LDO and can accept 5V on the designated input pin, the modules only work on a voltage range around 3.3V, and you run the risk of damaging it if you run it at 5V. Chances are your chip is (partially) fried.

Sorry. I checked with the hardware manager and found that the power is being applied to ams1117-3.3

Additionally, an error occurred when transmitting data to the mesh. It's 0xFFFFFF0. It is divided into chips that occur and chips that do not.


The location of the above error...

esp_ble_mesh_register_custom_model_callback(ble_mesh_charger_property_server_cb);

It is the callback function of the above code and the lower one is the circle of the function.

static void ble_mesh_charger_property_server_cb(esp_ble_mesh_model_cb_event_t event, esp_ble_mesh_model_cb_param_t *param)
{
static charger_property_set_params_t cp_received_message = {0,};

charger_property_set_msg_pkt_t * p_cp_set_msg_pkt;

BaseType_t higher_task_woken = pdFALSE;

switch (event)
{
case ESP_BLE_MESH_MODEL_OPERATION_EVT:
{
p_cp_set_msg_pkt = (charger_property_set_msg_pkt_t *) param->model_operation.msg;

ESP_LOGI(TAG, "Charger Property Sever message is received. ID: %s.", id_name_by_id_num(p_cp_set_msg_pkt->property_id));

if((tid_validate.addr != param->model_operation.ctx->addr) || (tid_validate.opcode != param->model_operation.opcode) || (tid_validate.recv_dst != param->model_operation.ctx->recv_dst) || (tid_validate.tid != p_cp_set_msg_pkt->tid))
{
tid_validate.addr = param->model_operation.ctx->addr;

tid_validate.opcode = param->model_operation.opcode;

tid_validate.recv_dst = param->model_operation.ctx->recv_dst;

tid_validate.tid = p_cp_set_msg_pkt->tid;

if(param->model_operation.opcode == CHARGER_PROPERTY_SERVER_OP_SET)
{
memcpy(&(p_gateway_status->node_info.ctx), param->model_operation.ctx, sizeof(esp_ble_mesh_msg_ctx_t));

cp_received_message.property_id = p_cp_set_msg_pkt->property_id;

memcpy(&(cp_received_message.property_data), &(p_cp_set_msg_pkt->property_data), sizeof(property_data_t));

if(xQueueSendToBackFromISR(p_gateway_status->task_vars.queue[QUEUE_INDEX_CHARGER_PROPERTY_SERVER_RECEIVE], &cp_received_message, &higher_task_woken) != pdTRUE)
{
ESP_LOGE(TAG, "<<< Sendging to the charger property server message queue is failed. >>>");

esp_restart();
}
else
{
portYIELD_FROM_ISR();
}
}
}
else
{
ESP_LOGE(TAG, "tid is not validate.");

break;
}

break;
}
case ESP_BLE_MESH_MODEL_SEND_COMP_EVT:
{
if (param->model_send_comp.err_code)
{
ESP_LOGE(TAG,"%04X",param->model_send_comp.err_code); // here
ESP_LOGE(TAG, "Failed to send charger property message. Address: 0x%04X", param->model_send_comp.ctx->addr);
break;
}

ESP_LOGI(TAG, "Sending charger propery message is completed. Address: 0x%04X.", param->model_send_comp.ctx->addr);

if(xSemaphoreGiveFromISR(p_gateway_status->task_vars.semaphore[SEMAPHORE_INDEX_CHARGER_PROPERTY_SEND_DONE], &higher_task_woken) == pdTRUE)
{
portYIELD_FROM_ISR();
}
else
{
ESP_LOGE(TAG, "Giving semaphore from ");
}

break;
}

default:
break;
}
}