search

nspsck / STM32F411CEU6_BlackPill_Micropython

MIT License
5 stars 1 forks source link

micropython/lora won't init on 8MB variant #6

Closed davefes closed 9 months ago

davefes commented 9 months ago

micropython/lora runs OK on the "regular" version. But on the 8MB version I get:

MPY: sync filesystems
MPY: soft reboot
Traceback (most recent call last):
  File "main.py", line 216, in <module>
  File "main.py", line 54, in main
  File "main.py", line 47, in get_modem
  File "sx127x.py", line 267, in __init__
RuntimeError: Unexpected silicon version 0
MicroPython v1.22.0-preview.162.g6117aa686.dirty on 2023-11-19; WeAct Studio Blackpill v3.1 8MB with STM32F411CE
Type "help()" for more information.

On another distro this indicated to me that the LoRa chip was not reset properly. I looked at the reset pulse (on B10) and saw that it varied from the programmed value of 1ms, over the range of 1ms to 100us, on repeated CTRL-Ds. So, I lengthened the pulse to 10ms, which did not fix the problem.

Just before I raise an issue on 'micropython/lora` ... are there subtle differences running a program from internal flash and SPI flash on the WeACT BlackPill?

nspsck commented 9 months ago

ugh... you get?

davefes commented 9 months ago

Sorry, had to re-boot the computer to finish the issue

nspsck commented 9 months ago

Just before I raise an issue on 'micropython/lora` ... are there subtle differences running a program from internal flash and SPI flash on the WeACT BlackPill?

On thing that I can think of is the power consumption. Just a little brainstorming here.

The way micropython or python in general works, is according to my limited knowledge, irrelevant from the storage medium, where the code is stored, as long as they can be read by the interpreter correctly. The source code is compiled into bytecodes and these are stored in RAM, then it excute from RAM. So technically once the code is (correctly compiled and) loaded into the RAM, the programm should not be faulty, unless it has bugs.

Sorry, had to re-boot the computer to finish the issue

:D all good!

nspsck commented 9 months ago

Also, there is a weird issue with the spi peripheral, described here in the spi.c from the stm32 port. Maybe, just maybe, this has something to do with it (very unlikely).

nspsck commented 9 months ago

And I also noticed that you used B10 for reset? B10 is used by I2C2, just in case..

davefes commented 9 months ago

I am not using any I2C so thought it would be OK to use for my LoRa chip reset. I also tried B9.

davefes commented 9 months ago

OK, I'll post a micropythpon issue and hope that Angus has a suggestion. Thanks

nspsck commented 9 months ago

B9is also used by I2C2, but since you do not use any I2C, there should not be any issue.

davefes commented 9 months ago

I re-checked running the "regular" firmware version and I get the same error. Appears there could be a problem with the LoRa chips.