Open source Licence

  • administrators

    Dear All,

    I am pleased to confirm that the firmware of Pycom modules is now Open source and can be found here

    Essentially, we’re releasing the source code under GPLv3 which will ensure our developer community is able to support the development of the code unhindered. It also enables 3rd party ‘board manufacturers’ or people to distribute/license the code as long as they adhere to the license, attribution and disclaimer notices. This is also an obligation placed on Pycom by some of our technology partners.

    We have also placed on the repo a CLA (Contributor License Agreement) based on the Apache license with a few tweaks (which makes it more relevant for our hardware community).

    As I have previously offered, happy to address any questions you may have. Simply post on Forum or email me ( and I will collate all the information over a period of a week. We will then compile and submit back an FAQ document to address the main pertinent questions.

    Best wishes

  • I am pleased to confirm that the firmware of Pycom modules is now Open source and can be found here

    I remember to read in the past a topic in the "Announcements & News" about that PyCom and Micropython (Damien George) will work together on ESP32 port. Well, I would like to know some things:

    1. Where are there this topic? Anyone can past me the URL?
    2. Is this the official address to MicroPython to ESP32 where PyCom and Damien are working together?
    3. I remember (via that announcement) that PyCom will be to commit the source code ESP32 project directally to official port (address above), is that happen? Because I checked today that last commit was done more than a month ago and less than a month PyCom released a new firmware with modifications on the MicroPython.

    Thank you.

  • @livius good point, we'll start tagging it like this from now on. Thanks!

  • @daniel
    but i do not talk about this
    only when you commit to pycom-esp-idf
    add comment or some file as "version" and write there same string as is for pycom-micropython e.g. `1.3.0.b1'

    we then can back in commits and download esp-idf and pycom in the same version (older)

    but thank you for the update

  • @livius I was almost sure that we also pushed to Github the latest pycom-esp-idf, but it seems we didn't. That is corrected now and everything us up to date. Thanks for pointing it out.


  • We have correlation between

    will be good when you send update to new version
    e.g. 1.3.0.b1 do the same in pycom-esp-idf

    because i do not know now how to revert firmware to older version.
    I can simply download pycom-micropython at certain firmware version(commit)
    but do not know how do this in correlation with esp-idf (do not know which commit)

  • @daniel
    Thank you very much :)
    I still analyze repo (and learn C which is not my language) and need to understand internals until i change something on my side.

  • @livius that's needed in order to place functions inside the instruction RAM of the ESP32. Otherwise they will reside in flash, which means that they need to be fetched from the SPI flash everytime there's a cache miss. Time critical functions must be placed inside IRAM, as well as interrupt handlers.

  • @daniel
    Can i ask what is IRAM_ATTR in functions declaration?

  • @daniel
    thank you for the info - especially about time frame

  • @livius yes, machine.time_pulse_us() is very useful and we will implement it for the ESP32. A number of function in the time module are incomplete due to previous limitations of the IDF. The plan is to get back to that and implement them in early January.


  • Will be good to see port of this
    and also enable time_us() which is currently commented out in the code
    but i suppose it is limited by some esp32 IDF? and because of this is commented out?

  • Keep getting an error like this:

    developer@developer:~/esp32/pycom-micropython/esp32$ make BOARD=LOPY LORA_BAND=USE_BAND_868
    LINK build/LOPY/release/bootloader/bootloader.elf
    xtensa-esp32-elf-gcc -nostdlib -Wl,-Map=build/LOPY/release/bootloader/ -Wl,--no-check-sections -u call_user_start_cpu0 -Wl,-static -Wl,--undefined=uxTopUsedPriority -Wl,--gc-sections -T esp32.bootloader.ld -T esp32.rom.ld -T esp32.peripherals.ld -Wl,--start-group -Llib -L/home/developer/esp32/pycom-esp-idf/components/esp32/ld -Lbuild/LOPY/release/bootloader -L/home/developer/esp32/pycom-esp-idf/components/esp32/lib -Lbootloader -llog -lcore -lspi_flash build/LOPY/release/bootloader/bootloader.a -Wl,--end-group -Wl,-EL -o build/LOPY/release/bootloader/bootloader.elf
    /home/developer/esp32/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/4.8.5/../../../../xtensa-esp32-elf/bin/ld: cannot find -lcore
    collect2: error: ld returned 1 exit status recipe for target 'build/LOPY/release/bootloader/bootloader.elf' failed
    make: *** [build/LOPY/release/bootloader/bootloader.elf] Error 1

    I set the IDF_PATH and added gcc to PATH. Tried with the ln command, and without by editing the Makefile directly

    EDiT: fixed it thanks to daniel. I missed to import (inside pycom idf) the needed compontents:

    • git submodule update --init

  • @brotherdust Unlikely; the firmware partitions are 1M large, and your transfer stopped at 256k. OTA updating isn't quite 100% for me; not sure if that readonly flash bug is reoccurring or what, but doing a serial download tends to clear it. Also, on the firmware versions with the watchdog bug OTA almost always triggers that.

  • @brotherdust said in Open source Licence:

    @LoneTech Thanks for the instructions. I was able to successfully build on my Windows 10 box using Bash on Ubuntu on Windows. =) heh.

    So, yeah. It might have built successfully, but I can't get the LoPy to take it. Argh. Here's the CLI output:

    $ curl --disable-epsv --ftp-pasv -T "build/LOPY/release/appimg.bin" ftp://micro:python@
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
     31  819k    0     0   31  256k      0   530k  0:00:01 --:--:--  0:00:01  534k
    curl: (55) Send failure: Broken pipe

    I think it's because the firmware file is too big. The one I compiled is ~820KB, but the official releases are weighing in around ~631KB. Is it possible this is the cause?

  • @LoneTech Thanks for the instructions. I was able to successfully build on my Windows 10 box using Bash on Ubuntu on Windows. =) heh.

  • thank you for help
    i now have make WIPI bin file
    and i am ready to make some pull requests :)

  • this should be in documentation. Reading script file is bad way for starters ;-)
    but now it is clear

    curl with these specific options is used as a command line ftp client
    ah i see, he only copy image file throught ftp
    i did not read whole line carefully - but it was so simple
    when i saw curl i have stoped reading ;-)

  • administrators


    It's identical under all OS. Read Makefile and in the pycom-micropython/esp32 folder.

    curl with these specific options is used as a command line ftp client. You can just as well use FileZilla following the instructions at

  • It is incompleat
    i do not see something like this in documentation
    as was posted by @LoneTech

    and something like

    After curl --disable-epsv --ftp-pasv -T build/LOPY/release/appimg.bin ftp://micro:python@ESP_00C2C6//flash/sys/appimg.bin my LoPy said MicroPython e2cc46a-dirty on 2016-11-15; LoPy with ESP32 :)

Log in to reply

Pycom on Twitter