No, the partitions layout is also being used, either in the original but probably in the .bin format, during loading data to spiffs, LittleFS or FAT. It is THE controlling file for memory layout.

partitions.csv is not only being looked at during compilation. It is also honored during uploading to LittleFS. Now what is being look at, at that time, is probably the loaded .bin image but I am not sure of that. I have not testing changing the partitions.csv between compilation and uploading files ...

This used to work. Using Custom or modifying the internal files is a loser because any upgrade loses those updates. The documentation says it works. It used to work. It now does NOT work and needs to be fixed. I tried this on 3.1.3 and 3.2.0 and it fails on both. I don't remember exactly when it ...

Although this file is shown as a Comma Separated Values file, it seems to be actually strictly setup depending on columns. I find no documentation on the column requirements but when I moved one column of numbers one row to the right, it totally confused the linker. So you have to be very careful ...

I have been loading up code and a huge LittleFS partition for a couple of weeks. I recently upgraded to 3.2.0 board definition and, now, the partitions.csv is being ignored. I have tried two formats, both of which worked yesterday, now both are ignored in v1 and v2.

Sketch uses 1317296 bytes (100 ...

I placed a partition.csv in my sketch folder as per the instructions on the Espressif site. It is being ignored. I tried partition.csv and partitions.csv. It makes no difference. Using the Arduino IDE version 1.8.19. Version 2.x has too many problems to be able to use it.

I am on board definitions ...

I am allocating exactly what I need. If you read what is allocated, it is 76816 bytes from the heap. Apparently, there is 16 bytes of housekeeping. Do you still say that is the wrong size? I can actually read and write about 64% of this area before it blows up. Please look, again, carefully, at what ...

The ESP32 is allocating memory in an unusable area. There are variations of this error. The first variation is the one I want to work. I am allocating 76800 integers in a single array from the heap. The heap, to start with, is almost 300K. So giving me 76800 is not a problem. It does that. Then I ...