Tool uPyLoader for MP on esp32

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
profra
Posts: 39
Joined: Sat Jan 03, 2015 12:23 am

Re: Tool uPyLoader for MP on esp32

Post by profra » Wed Nov 08, 2017 9:33 pm

@Roberthh Thank you for good advice, in the closest free time I will try to build own Wipy.

profra
Posts: 39
Joined: Sat Jan 03, 2015 12:23 am

Re: Tool uPyLoader for MP on esp32

Post by profra » Fri Nov 10, 2017 11:04 am

@Roberthh Hi, I guess you have a lot of experience with PYCOM implementation of MP. It would be nice if you could help me with some good advice as last time. I am trying to build own image for Wipy 2 and I have to flash binaries on another machine.
I have found these binaries after build... see the picture.
Selection_023.png
Selection_023.png (18.41 KiB) Viewed 7765 times
BUT I can not find information where to burn it (on which addresses).
Will be there someone who will help me with the right info?

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Tool uPyLoader for MP on esp32

Post by Roberthh » Fri Nov 10, 2017 12:06 pm

Hello @profra, I responded already to your question in the pycom.io board. The answer can be found in the makefile applicatio.mk, which also controls flashing:

Code: Select all

BOOT_OFFSET = 0x1000
PART_OFFSET = 0x8000
APP_OFFSET = 0x10000
You do not need to flash wipy.bin. If you want to see, how the call fopr esptool.py should look like, simply rund on rou build machine the command:
make V=1 BOARD=WIPY flash
Even if that dos not succeed, you see the call for esptool.py and its parameters, which you then can take to the other machine.

profra
Posts: 39
Joined: Sat Jan 03, 2015 12:23 am

Re: Tool uPyLoader for MP on esp32

Post by profra » Fri Nov 10, 2017 12:23 pm

@Roberthh Also from this place... many thanks.

Beta_Ravener
Posts: 35
Joined: Tue Aug 09, 2016 6:56 pm

Re: Tool uPyLoader for MP on esp32

Post by Beta_Ravener » Mon Nov 13, 2017 1:41 pm

Hi @Roberthh, I have had success with rewriting the scripts to work with `sys` module instead of UART. However, this has broken the support for the other FW (WiPy 2), as it seems it has no buffer objects on stdin and stdout. I have tried using read and write directly on the stdin and stdout, but this has led to unexpected behavior (full log below). The MCU crashes and starts spitting zero bytes on the output even after reset, so it seems like FW gets corrupted and I may have bricked one ESP already (will try to resurrect it later). The only difference between working scenario and error one is using the buffer object.

Now, I was kind of intrigued in first place why you suggested using `sys.stdin.buffer.read` instead of plain `sys.stdin.read` and it seems like I might have found why. Could you explain a bit more in detail why you chose the former and maybe explain why is this problem happening?

Here's the log:

Code: Select all

ets_task(40100164, 3, 3fff8398, 4)
could not open file 'main.py' for reading

MicroPython v1.8.7-7-gb5a1a20a3 on 2017-01-09; ESP module with ESP8266
Type "help()" for more information.
>>> 
>>> 
>>> 
>>> 
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== #V2
=== import sys
=== import time
=== 
=== 
=== def _read_timeout(cnt, timeout_ms=2000):
===     s_time = time.ticks_ms()
===     data = sys.stdin.read(cnt)
===     if time.ticks_diff(time.ticks_ms(), s_time) > timeout_ms or len(data) != cnt:
===         return None
===     return data
=== 
=== 
=== def _upload():
===     suc = False
===     with open("__upload.py", "wb") as f:
===         while True:
===             d = _read_timeout(2)
===             if not d or d[0] != ord("#"):
===                 x = sys.stdout.write(b"#2")
===                 break
===             cnt = d[1] & 0x7F
===             if cnt == 0:
===                 suc = True
===                 break
===             d = _read_timeout(cnt)
===             if d:
===                 esc = False
===                 for c in d:
===                     if c == 0:
===                         esc = True
===                         continue
===                     x = f.write(bytes([c & 0x0F if esc else c]))
===                     esc = False
===                 x = sys.stdout.write(b"#1")
===             else:
===                 x = sys.stdout.write(b"#3")
===                 break
===     x = sys.stdout.write(b"#0" if suc else b"#4")
=== 
=== 
=== _upload()
=== 
=== 

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 32028, room 16 
tail 12
chksum 0x40
ho 0 tail 12 room 4
load 0x3ffe8000, len 1092, room 12 
tail 8
chksum 0x17
load 0x3ffe8450, len 3000, room 0 
tail 8
chksum 0x56
csum 0x56

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Tool uPyLoader for MP on esp32

Post by Roberthh » Mon Nov 13, 2017 2:02 pm

The ususal stdin/stdout is not transparent, in that it replaces characters (e.g. \r by \n) and tries to do a simple uft-8 conversion. The buffer versions are transparent. The difference in code the is minor. So I could try a PR for Pycom. Alternatively you could try to encode the data such it fits into the ASCI space, e.g. using a BASE64 or plain hex encoding.

Beta_Ravener
Posts: 35
Joined: Tue Aug 09, 2016 6:56 pm

Re: Tool uPyLoader for MP on esp32

Post by Beta_Ravener » Mon Nov 13, 2017 2:20 pm

I see. So the reason why it's crashing is probably when attempting to do that extra work. I will try to reproduce the behavior with simpler code so I can fill in bug, but making the PR for buffers in WiPy would be probably the best.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Tool uPyLoader for MP on esp32

Post by Roberthh » Mon Nov 13, 2017 2:24 pm

There is a config option called MICROPY_PY_SYS_STDIO_BUFFER. I'll try to set that to 1. Sometimes that's all that is needed, sometimes the option is still there, but the code is missing. Personally I would spend the time in a transparent encoding, which make the least possible assumption on transparency.

Beta_Ravener
Posts: 35
Joined: Tue Aug 09, 2016 6:56 pm

Re: Tool uPyLoader for MP on esp32

Post by Beta_Ravener » Mon Nov 13, 2017 4:51 pm

You're right, I just rewrote the protocol to use base64, so it's more standard. However, it was crashing anyway. Interestingly, once I switched from `bytes` to `str` in `sys.stdout.write`, it stopped crashing, so there might be some issue (which I couldn't reproduce with simpler setup).

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Tool uPyLoader for MP on esp32

Post by Roberthh » Mon Nov 13, 2017 5:00 pm

sys.stdout.write normally expects str. However mycropython is more tolerant.
Just for interest I enabled buffer in the pycom port, by adding the line:
#define MICROPY_PY_SYS_STDIO_BUFFER (1)
to mpconfigport.h and rebuilt the firmware. That's all what's needed, but for you this is hardly suitable, because for your software you have to make minimal assumptions. And the base64 support is available in both the pycom.io and micropython.org versions.

Post Reply