How I built a custom firmware for frozen bytecode
Some rough notes to hopefully save others hassle. I think these were all the steps, but if you find something not working let me know and I'll check my command history.
My setup is I have a Linux Mint VM (Very similar to Ubuntu and Debian) and a Windows desktop with Cygwin installed that I used for flashing. Mint is apt-get dist-update up to date as of this posting.
- Follow these instructions with one exception: Here is the correct URL to the Readme.md file.
- The xtensa gcc compiler won't work with Pycom devices for some reason. Use this one instead. NOTE! I'm not sure where to check for the newest version of this!! It worked as of this writing. Found out about this here.
- I had to apt-get install build-essential in my VM, and I edited /root/.profile and added this line:
- Log out and back in.
So here's what I could piece together from my command history:
sudo su - # Yeah, I do everything as root. Sue me. apt-get install build-essential git cd /root vi .profile # Add the export above exit sudo su - git clone https://github.com/pycom/pycom-micropython-sigfox.git git clone https://github.com/pycom/pycom-esp-idf.git cd pycom-esp-idf git submodule update --init # Don't recall why I did this sorry cd /root wget https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-61-gab8375a-5.2.0.tar.gz tar zxf xtensa-esp32-elf-linux64-1.22.0-61-gab8375a-5.2.0.tar.gz
Then I copied my custom code into /root/pycom-micropython-sigfox/esp32/frozen/
Ran the build commands, and actually I rolled them into build.sh to make re-running simpler.
cd /root/pycom-micropython-sigfox/esp32 make clean # May not be desired if doing active development? rm -rf frozen/__pycache__ export IDF_PATH=~/pycom-esp-idf export BUILD_VERBOSE=true make BOARD=WIPY TARGET=boot make BOARD=WIPY TARGET=app cp build/WIPY/release/wipy.bin /home/betterauto/ cp build/WIPY/release/bootloader/bootloader.bin /home/betterauto/ cp build/WIPY/release/lib/partitions.bin /home/betterauto/ chown betterauto /home/betterauto/*.bin
- Copied the *bin files to my Windows desktop.
- I already had the Pycom firmware updater installed and I used its esptool.py. My serial UART is plugged into COM18 in Windows, which in Cygwin is /dev/ttyS17. (Like good geeks, they start counting at zero.)
- Grounded Pin 23
- Here are the commands I used to flash. Found them here. It's probably possible to consolidate these into one command but I haven't tried it yet. I saw in some examples that they combined firmware files on the command line like 0x1000 Desktop/bootloader.bin 0x8000 Desktop/partitions.bin 0x10000 Desktop/wipy.bin. I also saw that some flags such as --flash_mode or --flash_freq may not be needed. I haven't experimented.
/cygdrive/c/Program\ Files\ \(x86\)/Pycom/Pycom\ Firmware\ Update/Upgrader/bin/esptool.py --chip esp32 --port /dev/ttyS17 --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 Desktop/bootloader.bin /cygdrive/c/Program\ Files\ \(x86\)/Pycom/Pycom\ Firmware\ Update/Upgrader/bin/esptool.py --chip esp32 --port /dev/ttyS17 --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x8000 Desktop/partitions.bin /cygdrive/c/Program\ Files\ \(x86\)/Pycom/Pycom\ Firmware\ Update/Upgrader/bin/esptool.py --chip esp32 --port /dev/ttyS17 --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 Desktop/wipy.bin
- Pulled off the Pin 23 ground and reset the device, it came right up.
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff9010,len:12 ho 0 tail 12 room 4 load:0x3fff9020,len:388 load:0x40078000,len:11584 load:0x4009fb00,len:848 entry 0x4009fc9c MicroPython 3f93fc2 on 2017-10-09; WiPy with ESP32 Type "help()" for more information. >>>
robert-hh last edited by
@betterauto I found this redirection of USB to a VM often flaky. VMware works better than Virtualbox.
@robert-hh I could not, because my VM is on a different machine than the machine I use to flash. Though I could have plugged the UART into the machine with the VM and redirected the USB device to the VM, then it likely would have worked.
robert-hh last edited by
@betterauto You can simply type:
to upload the firmware via USB, if USB is usable, which is problematic in a VM.