We observe the same issue using MQTT.
E (311640) transport_base: poll_read select error 113, errno = Software caused connection abort, fd = 51
E (311641) mqtt_client: Poll read error: 119, aborting connection
Search found 37 matches
- Wed Oct 23, 2024 7:37 am
- Forum: ESP-IDF
- Topic: TRANSPORT_BASE: poll_read select error 113, errno = Software caused connection abort, fd = 54: cannot recover from this
- Replies: 2
- Views: 1795
- Tue Aug 06, 2024 3:05 pm
- Forum: ESP-IDF
- Topic: How to set a specific OTA slot to invalid?
- Replies: 0
- Views: 599
How to set a specific OTA slot to invalid?
Hey all, I want to make sure a specific ota slot will not be booted. Of course I can (and will) erase the not to be booted ota slot. However, I think OTA data will still see this slot as bootable? As far as I see esp_ota_set_boot_partition() will only use esp_rewrite_ota_data() to mark the new image...
- Fri Jul 05, 2024 10:05 am
- Forum: ESP-IDF
- Topic: InstrFetchProhibited at cpu_start: Pro cpu start user code
- Replies: 1
- Views: 666
InstrFetchProhibited at cpu_start: Pro cpu start user code
Hello, we have a bigger project where a lot of code was added in a separate branch. This branch works fine until its merged into the main branch. The code does not have any obvious flaws, which could explain the error below. I am a bit confused what needs to happen, that a crash triggers directly wh...
- Thu Jun 27, 2024 3:12 pm
- Forum: ESP-IDF
- Topic: Errors in esp_log while Compiling
- Replies: 14
- Views: 2667
Re: Errors in esp_log while Compiling
uint32 (long int) must be printed with %ld. Instead of using compiler flags its better to adjust the failing %d formats.
I am using IDF 5.0.1 where there are no errors. So you shouldnt get any errors with newer versions.
I am using IDF 5.0.1 where there are no errors. So you shouldnt get any errors with newer versions.
- Fri Apr 05, 2024 11:31 am
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
Re: Avoid blocking code execution (erase flash)
I'm not sure I entirely understand your code, but: Here's a way to serve TWAI efficiently: 1. CONFIG_TWAI_ISR_IN_IRAM=y 2. When calling twai_driver_install(), the intr_flags member of twai_general_config_t should set the ESP_INTR_FLAG_IRAM set. 3. Create a mid-high priority TWAI receiver task that ...
- Thu Apr 04, 2024 7:43 am
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
Re: Check if internal flash is busy
Unfortunately, I am still facing issues. I created a simple FIFO to read the twai messages. Own task, functions marked as IRAM, runs every 2 ms, highest priority. // Check if the FIFO buffer is full int IRAM_ATTR twai_fifo_full() { return twai_fifo.count == FIFO_SIZE; } // Add a message to the FIFO ...
- Wed Apr 03, 2024 10:26 am
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
Re: Check if internal flash is busy
I reckon you already have set the TWAI routine to IRAM and did register the GPIO service routine with a sufficiently high priority? (I have struggled a long time with the internal CAN controller to get reliable timings and then gave up and added an external one.) The code is not currently set to be...
- Tue Apr 02, 2024 2:45 pm
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
Re: Check if internal flash is busy
Due to the tiny internal buffer, you have to serve twai efficiently – however why don‘t you write to a memory buffer first? Do you have PSRAM? Yes we do have PSRAM and do actually cache the messages in a buffer, before we process them. Maybe I have to check why the task that polls the twai buffer s...
- Tue Apr 02, 2024 12:58 pm
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
Re: Check if internal flash is busy
We use the TWAI lib to update the ESP32 OTA partition, if in the meantime another task (also on other core) accesses the flash memory, it results in a TWAI_ALERT_RX_FIFO_OVERRUN. We could increase the FrameSeperationTime to ease up the bus load, but would increase update time by a lot. I found this ...
- Thu Mar 28, 2024 10:13 am
- Forum: ESP-IDF
- Topic: [SOLVED] Avoid blocking code execution (erase flash) for TWAI
- Replies: 10
- Views: 6171
[SOLVED] Avoid blocking code execution (erase flash) for TWAI
Hey, we have some time critical code that requires to perform writes to flash memory in chunks. However, this fails as soon as another component operates on the flash as well (e.g. if esp_partition_erase_range() or esp_partition_write() is performed). So my question is, if it is somehow possible to ...