tinyusb_msc: heap_caps_aligned_calloc() allocates 4x needed memory (DMA OOM) (IEC-486)

[pztrick]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

device/esp_tinyusb

ESP-IDF version.

v6.1-dev-1323-gf6aaf22278

Development Kit.

custom esp32-s3

Used Component version.

2.0.1

More Information.

Summary

msc_storage_new() calls heap_caps_aligned_calloc() with incorrect arguments, resulting in allocation of:

sizeof(msc_storage_obj_t) * sizeof(uint32_t)

instead of the intended:

sizeof(msc_storage_obj_t)

This causes ~4x overallocation in MALLOC_CAP_DMA memory and can lead to ESP_ERR_NO_MEM on systems with constrained or fragmented DMA heap.

---

Current Code

heap_caps_aligned_calloc(MSC_STORAGE_MEM_ALIGN,
                         sizeof(msc_storage_obj_t),
                         sizeof(uint32_t),
                         MALLOC_CAP_DMA);

Per the API:

heap_caps_aligned_calloc(alignment, n, size, caps)

The above allocates:

sizeof(msc_storage_obj_t) * sizeof(uint32_t)

// evaluates to roughly: CONFIG_TINYUSB_MSC_BUFSIZE * 4

---

Correct Usage

heap_caps_aligned_calloc(MSC_STORAGE_MEM_ALIGN,
                         1,
                         sizeof(msc_storage_obj_t),
                         MALLOC_CAP_DMA);

---

Impact

• Causes unnecessary 4× DMA allocation
• Fails when available DMA memory exceeded
• Appears intermittent depending on heap fragmentation
• CONFIG_TINYUSB_MSC_BUFSIZE=8192 would result in ~32K being sought for allocation

[github-actions]

Hi @pztrick! Please be aware that the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

You’re correct about how heap_caps_aligned_calloc() is supposed to be used, and your analysis of the parameter order matches the documented API pattern for aligned_calloc(alignment, n, size, caps) (alignment, number of elements, element size, capabilities).

From the information available in the provided knowledge sources:

• ESP-IDF’s heap capabilities allocator is explicitly capability-based and is used to control scarce resources like DMA-capable internal RAM. Over-allocation in MALLOC_CAP_DMA can easily lead to ESP_ERR_NO_MEM or fragmentation issues, especially on ESP32-S3 where internal DMA RAM is limited.[ESP32 memory model]
• DMA-capable memory is specifically internal RAM and is treated as a constrained resource; APIs like heap_caps_malloc() / heap_caps_aligned_alloc() are meant to allocate just enough memory with the right capabilities.[ESP32 DMA mem]

However, the exact implementation of msc_storage_new() and its current call to heap_caps_aligned_calloc() is not shown in the knowledge sources, so I cannot directly confirm from these documents that the arguments are swapped in the current esp_tinyusb 2.0.1 code. The knowledge sources only mention higher-level MSC changes (integer overflow fixes, multitask protection, etc.), not this specific bug.[esp_tinyusb 1.4.0][esp_tinyusb 2.0.1]

Given that:

• The documented prototype is heap_caps_aligned_calloc(alignment, n, size, caps).
• Passing sizeof(msc_storage_obj_t) as n and sizeof(uint32_t) as size will indeed allocate sizeof(msc_storage_obj_t) * sizeof(uint32_t) bytes.
• For CONFIG_TINYUSB_MSC_BUFSIZE = 8192, this would request roughly 32 KB of DMA-capable memory instead of ~8 KB, which is consistent with the behavior you describe.

The correct and intention‑matching usage should be:

heap_caps_aligned_calloc(MSC_STORAGE_MEM_ALIGN,
                         1,
                         sizeof(msc_storage_obj_t),
                         MALLOC_CAP_DMA);

This allocates exactly one msc_storage_obj_t in DMA-capable memory with the requested alignment, avoiding the 4× over-allocation and the resulting ESP_ERR_NO_MEM on fragmented or tight DMA heaps.

Suggested action for the GitHub issue:

• Confirm the function prototype of heap_caps_aligned_calloc() in your ESP-IDF version to show the parameter order.
• Point out that the current call in msc_storage_new() uses sizeof(msc_storage_obj_t) as the element count and sizeof(uint32_t) as the element size, which multiplies the intended size by 4.
• Propose the patch you included:

// Before (current)
heap_caps_aligned_calloc(MSC_STORAGE_MEM_ALIGN,
                         sizeof(msc_storage_obj_t),
                         sizeof(uint32_t),
                         MALLOC_CAP_DMA);

// After (proposed)
heap_caps_aligned_calloc(MSC_STORAGE_MEM_ALIGN,
                         1,
                         sizeof(msc_storage_obj_t),
                         MALLOC_CAP_DMA);

Since this specific bug is not mentioned in the esp_tinyusb changelog or ESP-IDF release notes in the provided sources, it would be appropriate to submit it as a new bug report with the above rationale and patch suggestion.

[igi540]

Thank you for the detailed report — and for providing a PR with the fix.

The current heap_caps_aligned_calloc() calls do multiply n * size, so passing sizeof(struct) and sizeof(uint32_t) results in an unintended ~4× allocation. Your proposed change to n = 1 and size = sizeof(...) looks correct (and applies to both msc_storage_new() and msc_driver_install()).
We’ll review your PR here: #398