[SOLVED] ESP32 - mos put file is not working anymore

#1

Hi there,

It looks that I demolished my ESP32 a bit. I’m successfully working with a Mongoose OS for a while connecting LED’s, push buttons and POT meters. Normally I flash the firmware and during development I manually upload single .js files when they’re changed with the command: mos put fs/filename.js. So far so good.

Now I tried to connect a “10 segment bar graph LEDs” like is shown here: https://www.dfrobot.com/product-636.html
I made this setup, created some code, and uploaded the file. But after that I cannot upload files to that specific ESP32 anymore!
The “mos put” command now times out. After updating to the newest mos I even get the helpful message as follows:
E0205 21:56:02.054022 29380 serial.go:273] No response to handshake. Is /dev/cu.SLAB_USBtoUART the right port? Is rpc-uart enabled?

The funny thing is that flashing the firmware still works. So the device is not totally bricked. Workaround is to build new firmware for every code change.

I made sure that UART is enabled. Before proofing this, please note that this exact same firmware works OK on another ESP32. This one was never connected to the “10 segment bar graph LEDs”, and with this device the mos put command still works.

So I think something went wrong in the so called “hardware” setup, but I have no idea how to further analyse this problem. I googled anything that I can image, and I am out of options I can think of myself.

For the sake of completeness the template:
1. My goal is:
to upload single files to the ESP32 device.

2. My actions are:
mos put fs/filename.js

3. The result I see is:
E0205 21:56:12.492017 29380 serial.go:273] No response to handshake. Is /dev/cu.SLAB_USBtoUART the right port? Is rpc-uart enabled?
Error: write /dev/cu.SLAB_USBtoUART: file already closed

4. My expectation & question is:
It should just upload the file to the connected ESP32

All suggestions or pointers are highly appreciated!

#2

The mos.yml look like this:

config_schema:
  - ["wifi.sta.enable", true]
  - ["mos config-set mqtt.enable", true]

libs:
  - origin: https://github.com/mongoose-os-libs/boards
  - origin: https://github.com/mongoose-os-libs/ca-bundle
  - origin: https://github.com/mongoose-os-libs/rpc-service-config
  - origin: https://github.com/mongoose-os-libs/rpc-service-fs
  - origin: https://github.com/mongoose-os-libs/rpc-uart
  - origin: https://github.com/mongoose-os-libs/mjs
  - origin: https://github.com/mongoose-os-libs/aws
  - origin: https://github.com/mongoose-os-libs/adc
  - origin: https://github.com/mongoose-os-libs/dht
#3

I discovered what caused my problem. I just connected the LED bar to the pins on the “right”, ie the range of pins [15…3]. And I set output mode on each of them. The culprit was this line of code: GPIO.set_mode(3, GPIO.MODE_OUTPUT)
Setting the UART0 port to OUTPUT caused my issue. Flashing the firmware again was the only solution after running this line of code once. So now I skipped pin 1 and 3 and don’t explicitly set the pin to output anymore.

This may sound logical for some people, but I cannot find information with which I can draw such a conclusion myself. I want to prevent similar mistakes in the future.
Can anyone explain why setting the UART0 pins to output may cause such issues?

#4

UART0 is used by default for console logging and RPC. The RX (GPIO3) and TX (GPIO1) from UART0 are also connected to the USB to serial convertor chip on the development boards.

Setting GPIO3 as an output in the user code will disconnect it from the UART.

#5

Thanks for the explanation!