How do i get the full 16MB on the file system? ESP32

[misaalanshori]

I have a "TTGO ESP32 Pro OLED v2.0" board and i want to use it with micropython but it seems to be showing only 2mb instead of 16mb, i have checked with esptool.py the flash size and that it does have a 16mb flash.

After a little reading and searching it seems like the issue is in micropython itself, and that i would need to modify and compile the code myself to use the full flash, but those posts are pretty old (some are from 2015) and it seems like the code has changed and now i don't know where to add the modification.

I also don't fully understand how to compile the code myself

[Roberthh]

Yes, it has changed since 2015. Now you have to change the partition table partitions.csv in the esp32 port directory and rebuild the firmware.
The relevant entry is the last one. on a 16MB chip, the size should be changed to 0xE00000.

[misaalanshori]

Hey so i followed multiple tutorial to compile the source code but got stuck at running the make command which gave me this output: https://pastebin.com/FNTga0pm (pastebin link because its a little long)

[misaalanshori]

also, i havent modified the code at all because i want to make sure i know how to build/compile it before modifying it

[Roberthh]

So it looks like the build set-up is wrong.
common omiisions:
- forgot to run 'git sumodule sync;git submodule update --ini' in both the IDF directory after having checked out the specific commit, and in the ports/esp32 directory.
- Not setting the ESPIDF variable. That can be done in the call to Make, But I prefer a GNUmakefile, which for instance for me looks like:

Code: Select all

ESPIDF = $(HOME)/Downloads/esp-idf  # This is the path to the esp-idf
PART_SRC = partitions.csv  ## change that for your changes partitions file.
BOARD = GENERIC_SPIRAM
$(info BOARD = $(BOARD))
FROZEN_MANIFEST ?= boards/$(BOARD)/manifest.py
$(info FROZEN_MANIFEST ?= $(FROZEN_MANIFEST))
ESPTOOL=esptool.py
MPY_CROSS_FLAGS = -march=xtensa
include Makefile

[jimmo]

If Docker is an option for you, then it's a dramatically simpler way of building for ESP32 or ESP8266.

There are a few different options, but here's an ESP32 setup that I know is up to date and supports the latest IDF (so BLE works).

Code: Select all

docker build https://gitlab.com/alelec/docker-esp32-toolchain/raw/master/Dockerfile

This will print out something like "Successfully built dc412d2435e5", copy that image ID.

Then:

Code: Select all

cd mpy-cross
docker run --rm -v $HOME:$HOME -u $UID -w $PWD dc412d2435e5 make -j
cd ../ports/esp32
docker run --rm -v $HOME:$HOME -u $UID -w $PWD dc412d2435e5 make -j

(Replacing the image ID with the one generated earlier)

[misaalanshori]

I folowed the docker method since it was much more simple and now It shows ~13mb available (much bigger than the 2mb before)


Thanks for the help!!

[Roberthh]

@jimmo: The docker approach seems interesting. In trying it, I get an error:

Code: Select all

make: esptool.py: Command not found
make: *** [Makefile:915: build-GENERIC_SPIRAM/bootloader.bin] Error 127
make: *** Waiting for unfinished jobs....

The question I have: How are the containers maintained and updated, e.g. when esp-idf changes and the commit has to be changed.

[jimmo]

@roberthh I think this might be caused by having ESP_IDF set in your GNUmakefile - the container does this for you. Or perhaps some other path on the host is being used.

Worth mentioning as well, depending on your environment, it might not be possible to use the "deploy" target (i.e. you'll have to set up access to the serial device).

Try using make V=1 and see what path it's using for esptool.

I know the owner of this image keeps it up to date because they use it for CI. You'll periodically have to run the build step again when it changes. It's a better experience when using images from dockerhub because you just reference the name.

[Roberthh]

@jimmo Yes, there was an environment variable set for ESPTOOL. After clearing that, it worked. And yes, deploy does not work. The container does not have a /dev/ttyUSB0 in view. So this approach is of limited use for me.