Wemos Lolin C3 Mini Board

[askpatrickw]

This is board definition for the Lolin C3 Mini

TODO:
(Reworking all this based on a different baseline board defition (QtPyC3)

• Should this be "lolin" or "wemos"? -- Using Wemos for company and using lolin in board name.
• Question: I see IGNORE_PIN_ in the docs, but not in any Espressif board definitions. Should we ignore that for Espressif boards? --
• Question: Adafruit_CircuitPython_NeoPixel is frozen, should it be? -- No. This board does not have a Neopixel
• VID and PID are currently the same values as the the Lolin S2 Mini. Not sure if that is correct. NOPE, need a new PID, requested from Espressif.
• QUESTION is the C3 Bin only? I set the build to BIN only as other C3 boards appear to be and the CI Failed. Yes they are BIN only.

Wemos Lolin C3 Mini Testing

• SafeMode Boot by tapping Boot Mode on power on
• Pin 0: A0:
• Pin 1: A1:
• Pin 2: A2: Pin 2 is always pulled high according to the schematic
• Pin 3: A3:
• Pin 4: A4:
• Pin 5: A5: SDA: i2c.scan() worked
• Pin 6: SCL: i2c.scan() worked
• Pin 7: board.LED on\off works
• Pin 8: Pin 8 is always pulled high according to the schematic
• Pin 10:
• UART (PIN: 20,21/A6,A7)
• WIFI
  • Scan Networks
  • Connect: FAILING ConnectionError: Unknown failure 205 -- I don't think has to do with this board. Fixed by Add wifi.radio.tx_power for espressif port #6540
• BLE
• rshell/ampy access: FAILING, they do not connect

---

Snippet of the Schematic

Some helper docs:

• C3 Mini Homepage
• C3 Mini Schematic
• C3 Datasheet
• C3 Mini MicroPython Download Page
• C3 MicroPython Port

[kylefmohr]

Hi, looking forward to testing this out later this afternoon! Regarding your second question, I would think it would be 'Lolin', based on their ESP32-S2 board which is supported https://circuitpython.org/board/lolin_s2_mini/

[askpatrickw]

Yeah the Company appears to be called Wemos and the RTD url is Wemos.
https://www.wemos.cc/en/latest/c3/c3_mini.html

The Aliepxress store is Lolin.
https://lolin.aliexpress.com/store/1331105 and the descriptions mention Wemos.

But sometimes the boards have Lolin in the name on the Wemos RTD site, and in the silkscreen, sometimes they don't. https://www.wemos.cc/en/latest/index.html

🤷‍♂️ -- I'm going to leave it as Lolin unless someone corrects it.

[askpatrickw]

I'm going to park this PR as a draft unless someone has an idea on how to get a CPY file onto the board without BLE workflow.

If you'd rather I close it and re-open later, that's OK too.

[askpatrickw]

NVM about being blocked...
Neradoc pointed me at the QTPYC3 to compare to, and now I have REPL access so I'm not blocked.

[askpatrickw]

Pin 2 an 8 are always pulled high according to the schematic so I'm checking those off the test list since I see that this is true when testing.

[askpatrickw]

I'm flipping this to ready for review. It might not be perfect, but I think its working well. The one open item is the Creations ID and Repo, but I think when Scott is back that will be cleaned up and be implemented as I suggested and have it in the files.

[tannewt]

One request. Wemos creations repo should be ready for a PR too.

Thanks for adding this board!

[prplz]

Your pin naming isn't right. Circuitpython uses whatever the silkscreen says, in this case matching the IO# numbering. So IO0-IO10 should be D0-D10, etc.

[askpatrickw]

Thanks @tannewt and @prplz I will look at this next week.

[askpatrickw]

@prplz I'm back from my trip and hoping to finish this up ASAP. Now the I'm looking at the board, I don't see any "D" labels on the silscreen, so I'm confused. If you want to "@" me on Discord, we can do that too. Thanks for your help!

[prplz]

@prplz I'm back from my trip and hoping to finish this up ASAP. Now the I'm looking at the board, I don't see any "D" labels on the silscreen, so I'm confused. If you want to "@" me on Discord, we can do that too. Thanks for your help!

Right, on the silkscreen they are just numbers. The naming in pins.c should match the silk, for example you have { MP_ROM_QSTR(MP_QSTR_D8), MP_ROM_PTR(&pin_GPIO0) }, but on the silk it's named 0. I said D but the convention seems to be to use "IO" for esp32 boards.

     { MP_ROM_QSTR(MP_QSTR_A0), MP_ROM_PTR(&pin_GPIO0) },
-    { MP_ROM_QSTR(MP_QSTR_D8), MP_ROM_PTR(&pin_GPIO0) },
+    { MP_ROM_QSTR(MP_QSTR_IO0), MP_ROM_PTR(&pin_GPIO0) },

     { MP_ROM_QSTR(MP_QSTR_A1), MP_ROM_PTR(&pin_GPIO1) },
-    { MP_ROM_QSTR(MP_QSTR_D9), MP_ROM_PTR(&pin_GPIO1) },
+    { MP_ROM_QSTR(MP_QSTR_IO1), MP_ROM_PTR(&pin_GPIO1) },

and so on.

[evildave666]

@prplz I'm back from my trip and hoping to finish this up ASAP. Now the I'm looking at the board, I don't see any "D" labels on the silscreen, so I'm confused. If you want to "@" me on Discord, we can do that too. Thanks for your help!

Right, on the silkscreen they are just numbers. The naming in pins.c should match the silk, for example you have { MP_ROM_QSTR(MP_QSTR_D8), MP_ROM_PTR(&pin_GPIO0) }, but on the silk it's named 0. I said D but the convention seems to be to use "IO" for esp32 boards.

There might be an argument for retaining an alternate "D" pin notation to match that of the D1 mini board, as there's an existing ecosystem of shields with markings matching those on the D1 board.

[prplz]

There might be an argument for retaining an alternate "D" pin notation to match that of the D1 mini board, as there's an existing ecosystem of shields with markings matching those on the D1 board.

I see, maybe keep the D names and add IO as well?

[askpatrickw]

OK, I wasn't understanding this 100%, but I took a picture of the board, zoomed in, followed the traces and I get it now. In the passing of time, I have no idea why I used those D Mappings. Latest commit maps the silkscreen numbers to the correct pins (D to GPIO).

The IO:GPIO mappings are 1:1 aligned. There are always the same according to my reading of the schematic.

With two possible extraneous extra IOs. IO20, IO21 are not on the schematic for GPIO20, GPIO21, they are labeled RX and TX instead. Let me know if those IO mappings should be removed or if they are also valid.

thank so much!

[kylefmohr]

I think the build is failing because your fork is a ways behind the main branch. If you fetch the upstream, it may fix the build issues.

[kylefmohr]

I think the build is failing because your fork is a ways behind the main branch. If you fetch the upstream, it may fix the build issues.

I was able to confirm this by forking adafruit:main with the most recent commits and applying the changes made by askpatrickw:lolin-c3-mini. Everything built successfully here

[evildave666]

This board seems to have a hardware issue that it needs to have TX power explicitly adjusted away from default for wifi to function (I've verified this in Micropython - won't connect at default power but after adjusting it works fine and a similar caveat exists in Wemos' arduino documentation). I don't believe the circuitpython wifi library for ESP32 has a runtime setting for this (Micropython has sta_if.config(txpower=xxx) but an equivalent does not appear to exist in Circuitpython) so it might have to be set in board.c

[kylefmohr]

This board seems to have a hardware issue that it needs to have TX power explicitly adjusted away from default for wifi to function (I've verified this in Micropython - won't connect at default power but after adjusting it works fine and a similar caveat exists in Wemos' arduino documentation). I don't believe the circuitpython wifi library for ESP32 has a runtime setting for this (Micropython has sta_if.config(txpower=xxx) but an equivalent does not appear to exist in Circuitpython) so it might have to be set in board.c

Interesting, that explains why my build wouldn't connect to Wi-Fi. Here's a link to their documentation regarding this for MicroPython

[askpatrickw]

I think the build is failing because your fork is a ways behind the main branch. If you fetch the upstream, it may fix the build issues.

Thanks @kylefmohr this PR got old... I appreciate the reminder.

[askpatrickw]

Thank you @todbot! I'll try that later tonight or tomorrow night.

[todbot]

ooof I'm looking in: esp-idf/componenents/esp_phy/esp32s2/include/phy_init_data.h and similar files grepping for "TX_POWER" and am really wishing CircuitPython had access to esp_wifi_set_max_tx_power()

[tannewt]

ooof I'm looking in: esp-idf/componenents/esp_phy/esp32s2/include/phy_init_data.h and similar files grepping for "TX_POWER" and am really wishing CircuitPython had access to esp_wifi_set_max_tx_power()

Feel free to add it! It makes sense that Radio would have a tx_power attribute.

[askpatrickw]

I opened a Feature request for wifi.radio.tx_power() #6540

[askpatrickw]

OK, if this build works, and it should, I just tested wifi.radio.connect with the wifi.radio.tx_power, this is ready for final review.

[tannewt]

Looks good!