MicroPython on ESP32 with SPIRAM support

[OutoftheBOTS_]

I had my Lolin32 pro die on me. It did have the intermittent problem of the usb lead causing the CP210x chip to heat up like crazy and eventually the Wrover module died (started to heat up on power up). The board has now been pulled from sale on wemos shop and others have reported their board die too.

I personnel believe there is a problem with the cp210x chip they used and it is what caused the wrover module to fail.

I am now using a wrover module soldered to a analog lamb BOB just to break it out, I don't use their circuits except the c3 decoupling cap on the back as I found it caused the wrover module to fail too (the pull-up on pin 12 to 3v I believe is the problem). I just break out the wrover module and have just crimped put a dupont connector on a old school through hole 10k resister and connect it to EN and 3V to pull up the enable. I build my own power supply with a LDO and 2 decoupling caps on some perf board to a power it and it is working great. When I want to flash firmware I just place a jumper wire across pin 0 and gnd then press the rest button.

[OutoftheBOTS_]

Also for the pin 34 - 39 only being input pins thanks. I am currently using pin 36 as my MISO SPI pin and it works fine

[loboris]

I'm using Lolin32 Pro for a month now without any problems (no overheating at all).
It looks like there is a hardware problem with some boards, that is probably the reason why they are no longer available.

There is another, almost identical board, which could be a good replacement TTGO T8 V1.1
It also has 4MB psRAM, battery charger and SDCard slot, but differen LDO (linear).
It does not use WROVER module, the flash chip is accessible and (for those with soldering skils) can be easily replaced with the 16MB one.
Available also on eBay

[Roberthh]

I'm using two LOLIN32 pro devices. None of them overheats, but one works well at 80MHz, the other works realible only at 40MHz. The only difference I can see is, that on the worse one the wrover module does not flush well to the soldering pads. I have also a LOLIN32 with the WROOM modules, which made more trouble. I hade to resolder the CP210x chip, because it did not align well with its pads, to make it working. and the reset switch simply fell off.

[pythoncoder]

the reset switch simply fell off

Good grief.

Looking at the schematic they use a switchmode converter to produce the 3.3V rail from +5V. The circuit looks OK, but there is still scope for problems - capacitors with too high an ESR, inductor saturation, PCB layout, not to mention lousy soldering... My guess is that the bad boards are over-volting the ESP32. That would explain the high temperatures and failures.

[mattyt]

Just on the GPL issue, @loboris has kindly agreed to ensure that the remaining GPL files can be excluded from the build system.

However this means that some GPL files will be present in the repository, even if they're unused.

I was under the impression that this may still be a problem for some more permissive licensing. @loboris, very reasonably, argues that it is fine since built files wouldn't (necessarily) contain GPL code. IANAL so I thought it would be prudent to ask the wider group; does even the presence of GPL code in a repository raise concerns?

Would especially like to hear from @tuupola and @on4aa since they originally raised the issue. Also, probably directed at @Damien, could this make merging upstream difficult? Obviously those files would be excluded from the merge...

Hopefully we can put this licensing issue to bed quickly and get on to developing software!

[tuupola]

GPL is viral. If a permissive licensed (MIT) project includes restrictive licensed (GPL) code the GPL license says if the derivative work (in this case Loboris fork) is distributed (for example via GitHub) the whole derivative work must be relicensed as GPL. You cannot have parts of the code under MIT and other parts under GPL. This is why many avoid GPL licensed code like plague.

Giving a config option to leave out GPL code on compile time does not help.

Note that GPL is a license, not a contract. If the derivative work does not change the license to GPL the derivate works violates the license. When project violates the GPL license it loses the permission to use the GPL code in question. Everything is ok after the GPL code is removed.

For a hobby project it is extremely rare for GPL violation to go to court. For commercial entities situation might be different. For example M5Stack firmware is based on this fork but the source code is not released. The firmware contains GPL code from Pycom which means M5Stack is currently in GPL violation of Pycom's code.

Regarding merging upstream, AFAIK MicroPython code avoids GPL code.

[loboris]

The situation with licensing is at the moment as this:

I2C module, which was based on Pycom code (GPL licensed), is now rewritten from scratch (by the way, it now includes i2c slave and some improvements) and is MIT licensed. The update will be commited later today.

That leaves only the sendmail method in curl module which is built on GPL licensed quickmail library.
It can be excluded from build using the menuconfig option. It will be rewritten at some later time.

If someone wants to build completely GPL free firmware, the repository can be forked/cloned, components/quickmail directory deleted (leaving no GPL licensed source in the project) and menuconfig used to exclude the method.
After building, the resulting firmware will not contain any GPL licensed code.

[pythoncoder]

@loboris I finally found time to try your build on this board.

I guess I must be missing something but the SPIRAM is apparently detected but isn't being incorporated into the heap.

Code: Select all

ESP32: soft reboot

Internal FS (SPIFFS): Mounted on partition 'internalfs' [size: 2752512; Flash address: 0x160000]
----------------
Filesystem size: 2522624 B
           Used: 52992 B
           Free: 2469632 B
----------------

FreeRTOS running on BOTH CORES, MicroPython task running on both cores.
Running from Factory partition starting at 0x10000, [MicroPython].

 Reset reason: RTC WDT reset
    uPY stack: 19456 bytes
     uPY heap: 512256/5856/506400 bytes (in SPIRAM using heap_caps_malloc)

MicroPython ESP32_LoBo_v3.1.18 - 2017-02-07 on ESP32 board with ESP32
Type "help()" for more information.
>>>

RAM tests

Code: Select all

>>> import micropython, machine
>>> micropython.mem_info()
stack: 752 out of 19456
GC: total: 512256, used: 6096, free: 506160
 No. of 1-blocks: 19, 2-blocks: 7, max blk sz: 337, max free sz: 31625
>>>

Code: Select all

>>> machine.heap_info()
Heap outside of MicroPython heap:
---------------------------------
              Free: 235316
         Allocated: 25388
      Minimum free: 234964
      Total blocks: 98
Largest free block: 113804
  Allocated blocks: 92
       Free blocks: 6

SPIRAM info:
------------
              Free: 3669972
         Allocated: 524288
      Minimum free: 3669972
      Total blocks: 2
Largest free block: 3669972
  Allocated blocks: 1
       Free blocks: 1
>>> 

I'd be grateful for any pointers as to what's going on here.

One suggestion: why not put the pre-requisites into the otherwise excellent build instructions in the root message?

Code: Select all

sudo apt-get install git wget make libncurses-dev flex bison gperf python python-serial

[Roberthh]

Nice little board!
What does gc.mem_free() tell you?