STM32 boards
Moderators: Voyager, BertB, grovkillen, Stuntteam, LisaM
Re: STM32 boards
Bug is stated here: https://github.com/micropython/micropython/pull/3379
Re: STM32 boards
Hi Lisa,LisaM wrote: ↑27 Mar 2018, 19:47 @andrewj: The colors are good, the wiring is good...
@karl222: Since the ESP32 is now, i'm currently looking at the STM32
STM32's are great, because the interrupts are hardware bound while the ESP32's have a software bound interrupt. Meaning that the STM32 latency is WAY lower then that of the ESP's, that also makes the ethernet way faster then wifi.
Pffffff, after update i ran into bugs. Filed them @micropython for help...
Any news about the bugs on STM32?
Also, I think I notice some small changes in the source code in recent version which may affect the CS pin etc. Would these changes allow the latest code to be built and to run on STM32, do you think? Is it worth me giving it a try?
Regards
Andrew
Re: STM32 boards
No update, this weekend i'll give it a try to work-around the bug so that we can build the STM32 version again...AndrewJ wrote: ↑04 Apr 2018, 22:40Hi Lisa,LisaM wrote: ↑27 Mar 2018, 19:47 @andrewj: The colors are good, the wiring is good...
@karl222: Since the ESP32 is now, i'm currently looking at the STM32
STM32's are great, because the interrupts are hardware bound while the ESP32's have a software bound interrupt. Meaning that the STM32 latency is WAY lower then that of the ESP's, that also makes the ethernet way faster then wifi.
Pffffff, after update i ran into bugs. Filed them @micropython for help...
Any news about the bugs on STM32?
Also, I think I notice some small changes in the source code in recent version which may affect the CS pin etc. Would these changes allow the latest code to be built and to run on STM32, do you think? Is it worth me giving it a try?
Regards
Andrew
Cheers,
Lisa
Re: STM32 boards
OK, thanks for the update. Good luck!
I'm ready to help with testing or any other way I can.
Andrew
I'm ready to help with testing or any other way I can.
Andrew
Re: STM32 boards
Hi Lisa,LisaM wrote: ↑05 Apr 2018, 01:08No update, this weekend i'll give it a try to work-around the bug so that we can build the STM32 version again...AndrewJ wrote: ↑04 Apr 2018, 22:40Hi Lisa,LisaM wrote: ↑27 Mar 2018, 19:47 @andrewj: The colors are good, the wiring is good...
@karl222: Since the ESP32 is now, i'm currently looking at the STM32
STM32's are great, because the interrupts are hardware bound while the ESP32's have a software bound interrupt. Meaning that the STM32 latency is WAY lower then that of the ESP's, that also makes the ethernet way faster then wifi.
Pffffff, after update i ran into bugs. Filed them @micropython for help...
Any news about the bugs on STM32?
Also, I think I notice some small changes in the source code in recent version which may affect the CS pin etc. Would these changes allow the latest code to be built and to run on STM32, do you think? Is it worth me giving it a try?
Regards
Andrew
Cheers,
Lisa
I noticed your post on MicroPython forum about a workaround for the bug...
https://forum.micropython.org/viewtopic ... 929#p26929
Does this mean that uPyEasy can be used now on STM32 simply by applying those patch commands (and I guess rebuilding Micropython?), or does something more need to happen first?
Cheers
Andrew
Re: STM32 boards
I've tried to fix the bugs, but they have change so much on the stm32 port that i lost track.
So, the work-around now is to roll back before they started to change the stm32 port on 31/1:
This builds the firmware.dfu again, without the errors.
However... i now run into the problem:
Pfffff.
So, the work-around now is to roll back before they started to change the stm32 port on 31/1:
Code: Select all
git clone https://github.com/micropython/micropython.git micropython-stm32
cd micropython-stm32/
git submodule update --init
git checkout a275cb0f487cd6517760271dc01d369c32600c63
git pull origin pull/3379/head
However... i now run into the problem:
Code: Select all
>>> import upyeasy
>>> upyeasy.main()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'main'
Re: STM32 boards
Hmm, that's frustrating!LisaM wrote: ↑13 Apr 2018, 18:14 I've tried to fix the bugs, but they have change so much on the stm32 port that i lost track.
So, the work-around now is to roll back before they started to change the stm32 port on 31/1:This builds the firmware.dfu again, without the errors.Code: Select all
git clone https://github.com/micropython/micropython.git micropython-stm32 cd micropython-stm32/ git submodule update --init git checkout a275cb0f487cd6517760271dc01d369c32600c63 git pull origin pull/3379/head
However... i now run into the problem:Pfffff.Code: Select all
>>> import upyeasy >>> upyeasy.main() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'main'
In the meantime I've been having a go. Here's what I did.
I used the commands you gave above, and it built without errors as you found.
Next, I re-built everything using the "new" micopython-stm32,
- I copied the upyeasy src contents into micropython-stm32/ports/stm32/modules/upyeasy
- copied modules contents into ....stm32/modules (had one or two duplicates where I chose the 'upyeasy' version)
- from repo root, did make -C mpy-cross
- in ...ports/stm32 I did
- make MICROPY_PY_WIZNET5K=5500 BOARD=PYBV3 (as I'm using the AliExpress clone board)
- then I connected 3v3 to BOOT0 and did
- sudo make MICROPY_PY_WIZNET5K=5500 BOARD=PYBV3 USE_PYDFU=0 deploy
(all of the above from your excellent document "uPyEasy Building Environment" with a few variations).
Reset and reconnected to USB and was able to connect to REPL
import upyeasy
upyeasy.main()
This worked ok for me, I didn't get the error you have, but it did stop with an error further on, which I'm sure is because I wanted to try it and hadn't connected the W5500
Good luck!
Andrew
Re: STM32 boards
The problem was that script.py imports re.py which is actually an unix library, script.py should import ure library which is a default micropython library. I fixed this, so it's working again. Apparently is main.py not findable if one the imports fails...
Cheers,
Lisa
Cheers,
Lisa
Re: STM32 boards
Ah, glad you've found that!LisaM wrote: ↑14 Apr 2018, 00:11 The problem was that script.py imports re.py which is actually an unix library, script.py should import ure library which is a default micropython library. I fixed this, so it's working again. Apparently is main.py not findable if one the imports fails...
Cheers,
Lisa
Which version of uPyEasy are you using? I realised belatedly that I was still using a previous version, not the latest with OpenHABmqtt. And did you find you needed to go through the whole building process like I was doing?
EDIT: forgot to ask, is W5500 now working for you?
Cheers
Andrew
Re: STM32 boards
uPyEasy does compile but doesn't work, it doesn't repond to web requests. I'm trying to figure out why, i suspect that the asyncio changes in uPyEasy have something to do with it.AndrewJ wrote: ↑14 Apr 2018, 08:39Ah, glad you've found that!LisaM wrote: ↑14 Apr 2018, 00:11 The problem was that script.py imports re.py which is actually an unix library, script.py should import ure library which is a default micropython library. I fixed this, so it's working again. Apparently is main.py not findable if one the imports fails...
Cheers,
Lisa
Which version of uPyEasy are you using? I realised belatedly that I was still using a previous version, not the latest with OpenHABmqtt. And did you find you needed to go through the whole building process like I was doing?
EDIT: forgot to ask, is W5500 now working for you?
Cheers
Andrew
However this code works, so the W5500 is also working:
Code: Select all
import picoweb, uasyncio as asyncio
CONTENT = """\
<html>
<head>
</head>
<body>
<p>Hello #%d from uPyEasy!</p>
</body>
</html>
"""
app = picoweb.WebApp(__name__)
@app.route("/")
def index(req, resp):
yield from picoweb.start_response(resp)
yield from resp.awrite(CONTENT)
class plugins(object):
def __init__(self) :
print("init")
async def asyncdevices(self):
print("async")
import network,pyb
nic = network.WIZNET5K(pyb.SPI(1), pyb.Pin.board.A3, pyb.Pin.board.A4)
while not nic.isconnected():
pass
nic.active(1)
nic.ifconfig(('192.168.178.100', '255.255.255.0', '192.168.178.1', '192.168.178.1'))
loop = asyncio.get_event_loop()
_plugins = plugins()
loop.create_task(_plugins.asyncdevices())
app.run(host="0.0.0.0", port=80,debug=False)
Re: STM32 boards
Solved the mystery, it was a single line of code! Changing this in the hal.py file from:
to
Solved the problem. In hindsight it makes sense, the nic was there, even with an ip-address, but not active so it couldn't receive data...
Uploaded new version.
Cheers,
Lisa
Code: Select all
#core._nic.active(1)
Code: Select all
core._nic.active(1)
Uploaded new version.
Cheers,
Lisa
Re: STM32 boards
Fantastic! Good spot!!LisaM wrote: ↑14 Apr 2018, 14:40 Solved the mystery, it was a single line of code! Changing this in the hal.py file from:toCode: Select all
#core._nic.active(1)
Solved the problem. In hindsight it makes sense, the nic was there, even with an ip-address, but not active so it couldn't receive data...Code: Select all
core._nic.active(1)
Uploaded new version.
Cheers,
Lisa
Re: STM32 boards. How to determine which boards will work
Difficult to see in this forum topic which board specs will and won’t work. Ie. memory required for code, etc.
Will this board work?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
And the pycom lopy?
https://www.robotics.org.za/AF3339
Will this board work?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
And the pycom lopy?
https://www.robotics.org.za/AF3339
-----------
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
Re: STM32 boards. How to determine which boards will work
I totally forgot the Lopy was ESP32. Since I have a couple of those, I will have to plug one in and see if it works.....JR01 wrote: ↑19 May 2018, 14:54 Difficult to see in this forum topic which board specs will and won’t work. Ie. memory required for code, etc.
Will this board work?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
And the pycom lopy?
https://www.robotics.org.za/AF3339
Re: STM32 boards
I gave the LoPy a try, the 2048 version loads and runs. I need to play with it more, but it appears to have issue keeping the AP information but that could be me not doing something correctly.. There were some other errors, something about MAC address not set, but that could be the LoPy comm module. Hard to say.
I was able to access several of the menus as well..
I was able to access several of the menus as well..
Re: STM32 boards
Thank you drum, I will wait until someone get there t working.
And the other STM32 I showed? Does it have enough memory?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
And the other STM32 I showed? Does it have enough memory?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
-----------
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
Re: STM32 boards
No Idea. I only have 1 and I have not been able to get it to work yet. It may work in mine, I just have not spent a lot of time on it.
You have to remember uPyEasy is still in beta and is not perfect on anything yet. Los of potential but it's not there yet.
You have to remember uPyEasy is still in beta and is not perfect on anything yet. Los of potential but it's not there yet.
Re: STM32 boards
Thank you!
-----------
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.
Re: STM32 boards. How to determine which boards will work
The mini doesn work, you'll need at least 1MB of flash memory! Also at least 196K of ram.JR01 wrote: ↑19 May 2018, 14:54 Difficult to see in this forum topic which board specs will and won’t work. Ie. memory required for code, etc.
Will this board work?
STM32 ARM Mini System - 72Mhz
https://www.robotics.org.za/6970622930693
And the pycom lopy?
https://www.robotics.org.za/AF3339
The pycom is using an ESP32 and hsould work, although untested since i don't have it.
Re: STM32 boards
Can you post the errors? i'm interested in the error.Drum wrote: ↑21 May 2018, 17:55 I gave the LoPy a try, the 2048 version loads and runs. I need to play with it more, but it appears to have issue keeping the AP information but that could be me not doing something correctly.. There were some other errors, something about MAC address not set, but that could be the LoPy comm module. Hard to say.
I was able to access several of the menus as well..
I'm going to order the pycom GPy since it supports nb-iot.
Re: STM32 boards
I (2715) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (2725) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
This is all I get consistently today.
I (2725) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
This is all I get consistently today.
Re: STM32 boards
Is this an ESP32 or a STM32F4?
It looks like this is a brown-out, meaning your power supply isn't strong enough.
Can i have the entire log?
Cheers,
Lisa
Re: STM32 boards
Well it is a ESP32 based LoPy. Power is coming from the computer, but that could be part of the problem. I will see if I can figure out how fix that and get a copy of the log file.
I just got a couple of ESP32 Nano boards I will try it on too..
I just got a couple of ESP32 Nano boards I will try it on too..
Re: STM32 boards
Here is the log after updating to the latest version
The LoPy works much better with an antenna attached
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4464
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:11816
entry 0x4007a9fc
I (290) cpu_start: Pro cpu up.
I (290) cpu_start: Single core mode
I (290) heap_init: Initializing. RAM available for dynamic allocation:
I (294) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (300) heap_init: At 3FFC5120 len 0001AEE0 (107 KiB): DRAM
I (306) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (312) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (319) heap_init: At 4008E0E8 len 00011F18 (71 KiB): IRAM
I (325) cpu_start: Pro cpu start user code
I (44) cpu_start: Starting scheduler on PRO CPU.
I (113) modsocket: Initializing
I (3053) wifi: wifi firmware version: c202b34
I (3053) wifi: config NVS flash: enabled
I (3053) wifi: config nano formating: disabled
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3093) wifi: Init dynamic tx buffer num: 32
I (3093) wifi: Init data frame dynamic rx buffer num: 64
I (3093) wifi: Init management frame dynamic rx buffer num: 64
I (3103) wifi: wifi driver task: 3ffd1194, prio:23, stack:4096
I (3103) wifi: Init static rx buffer num: 10
I (3113) wifi: Init dynamic rx buffer num: 0
I (3113) wifi: wifi power manager task: 0x3ffd5de4 prio: 21 stack: 2560
I (3183) phy: phy_version: 383.0, 79a622c, Jan 30 2018, 15:38:06, 0, 0
I (3183) wifi: mode : null
I (3193) wifi: mode : sta (24:0a:c4:00:90:72)
I (3193) wifi: STA_START
I (3313) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (3873) wifi: state: init -> auth (b0)
I (3873) wifi: state: auth -> assoc (0)
I (3883) wifi: state: assoc -> run (10)
I (3893) wifi: connected with devolo, channel 1
I (3893) network: event 4
I (5063) event: sta ip: 192.168.1.114, mask: 255.255.255.0, gw: 192.168.1.1
I (5063) network: GOT_IP
I (6883) wifi: pm start, type:0
2018-07-11 16:03:54 [info] uPyEasy-uPyEasy: Main: Async loop, log level: 2
2018-07-11 16:03:54 [info] uPyEasy-uPyEasy: Main: uPyEasy running in Station mode
The LoPy works much better with an antenna attached
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4464
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:11816
entry 0x4007a9fc
I (290) cpu_start: Pro cpu up.
I (290) cpu_start: Single core mode
I (290) heap_init: Initializing. RAM available for dynamic allocation:
I (294) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (300) heap_init: At 3FFC5120 len 0001AEE0 (107 KiB): DRAM
I (306) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (312) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (319) heap_init: At 4008E0E8 len 00011F18 (71 KiB): IRAM
I (325) cpu_start: Pro cpu start user code
I (44) cpu_start: Starting scheduler on PRO CPU.
I (113) modsocket: Initializing
I (3053) wifi: wifi firmware version: c202b34
I (3053) wifi: config NVS flash: enabled
I (3053) wifi: config nano formating: disabled
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3093) wifi: Init dynamic tx buffer num: 32
I (3093) wifi: Init data frame dynamic rx buffer num: 64
I (3093) wifi: Init management frame dynamic rx buffer num: 64
I (3103) wifi: wifi driver task: 3ffd1194, prio:23, stack:4096
I (3103) wifi: Init static rx buffer num: 10
I (3113) wifi: Init dynamic rx buffer num: 0
I (3113) wifi: wifi power manager task: 0x3ffd5de4 prio: 21 stack: 2560
I (3183) phy: phy_version: 383.0, 79a622c, Jan 30 2018, 15:38:06, 0, 0
I (3183) wifi: mode : null
I (3193) wifi: mode : sta (24:0a:c4:00:90:72)
I (3193) wifi: STA_START
I (3313) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (3873) wifi: state: init -> auth (b0)
I (3873) wifi: state: auth -> assoc (0)
I (3883) wifi: state: assoc -> run (10)
I (3893) wifi: connected with devolo, channel 1
I (3893) network: event 4
I (5063) event: sta ip: 192.168.1.114, mask: 255.255.255.0, gw: 192.168.1.1
I (5063) network: GOT_IP
I (6883) wifi: pm start, type:0
2018-07-11 16:03:54 [info] uPyEasy-uPyEasy: Main: Async loop, log level: 2
2018-07-11 16:03:54 [info] uPyEasy-uPyEasy: Main: uPyEasy running in Station mode
Re: STM32 boards
I am still getting
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUS
How can I get the log without being connected to the computer?
Thanks
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUS
How can I get the log without being connected to the computer?
Thanks
Re: STM32 boards
But, you do get an ip-address:Drum wrote: ↑11 Jul 2018, 17:11 I am still getting
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUS
How can I get the log without being connected to the computer?
Thanks
You should be able to connect to it...I (5063) event: sta ip: 192.168.1.114, mask: 255.255.255.0, gw: 192.168.1.1
I
Re: STM32 boards
Yes, and I have it running with syslog set to debug, but it is not what I see on "Screen".
Is it possible the
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
is related to the LoRa radio and not the esp32? Or perhaps LoRa and Bluetooth?
New version is much faster on this.
Is it possible the
I (3063) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (3073) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
is related to the LoRa radio and not the esp32? Or perhaps LoRa and Bluetooth?
New version is much faster on this.
Who is online
Users browsing this forum: No registered users and 2 guests