no python prompt after downgrading firmware

[rolfhut]

@jmarcelino I didn't get any reading from an iBeacon (actually a Radbeacon sending both ibeacon, altbeacon and eddy signals) using the standard code, while the phone next to it did get readings. The wipy did get readings from my macbook or phone when I turned their bluetooth on, just no BLE from the beacon. Since a lot of people on the forum said that going back to firmware < 15.0.1 solved for them, I did.

but now I'm stuck with a wipy that doesn't start python anymore for some reason.

[jmarcelino]

@rolfhut
Thanks, I thought you meant normal BLE operations: connecting to devices or advertising services/characteristics.

Yes beacon scanning is not good - if going back or forward in firmware helps is probably a matter of mysticism, maybe to do with getting a lucky break around the timings.

To be honest I consider beacon scanning so unreliable - more with beacons advertising multiple services as this means they're cycling through advertising very quickly - I haven't even tried it in months

So maybe try other versions, if 1.5.0 doesn't work try another e.g. 1.5.1... 1.5.2.. 1.6.0 . You might catch a lucky break, but I don't think there will be one which will offer reliable, repeatable results for what you're trying to.

[rolfhut]

@jmarcelino This is unfortunate because the sole reason for buying the wipy was for a student of mine who is familiar with python (part of our curriculum) but not other embedded platforms to build a scanner for beacons.

If this does not work with the wipy we may have a problem.

This does however not change the first question: why do I not get a python prompt anymore after downgrading firmware?

Rolf

[jmarcelino]

@rolfhut
There may be several reasons - incomplete/invalid firmware flash, problems in your boot/main, serial port issues... - are you able to post the messages you see? That could help pinpoint where the problem.

Also post your configuration, especially if you are using the Pycom expansion board or not.

But as a first course of action I'd recommend re-flashing it with another 1.5.1+ firmware as I already suggested.

[rolfhut]

@jmarcelino I put the latest firmware back on and it works fine (as in, I got a python prompt again), but no solution to the beacon problem.

related question: where can I find the libraries that are called when importing "from network import bluetooth"? They do not seem to be standard Python, but can also not find it on the pycom github.

[jmarcelino]

@rolfhut
They are C libraries imported into Python:

Network: modnetwork.c

Bluetooth: modbt.c

[rolfhut]

@jmarcelino found them, thanks! now increasing size of stack and compiling custom version of firmware to see if I can get beacons to register...

but this level of hacking / compiling is not what I intend my (environmental sciences, not electrical of software engineer) students to be able to do, so at this moment / stage will not be using wiPy for my classes.

[jmarcelino]

@rolfhut
You may want to try the modifications I suggested here earlier:

https://forum.pycom.io/post/3402

However Beacon scanning is intensive with transmissions 10 times a second on 3 frequencies (double that in your case since your are sending two beacon standards simultaneously) so on embedded systems the firmware has to be tuned to the task, I don't know any general purpose embedded platform that does it well out of the box.

I have had good results using Raspberry Pi 3 (or the Zero W) for scanning and prototyped solutions using them where 100+ of beacons in a single room were scanned with no major issues.

[rolfhut]

@jmarcelino I'm getting tons of compile errors when trying to compile even the un-altered firmware on my macbook. stuff like this:

In file included from mods/modwlan.c:28:0:
mods/modwlan.c: In function 'wlan_setup':
/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/esp32/include/esp_wifi.h:129:26: error: 'CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM' undeclared (first use in this function)
.static_rx_buf_num = CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM,\

which makes me feel like the instructions to compile on the github page of micropython were not tested on a machine that is not a dev machine...

[jmarcelino]

@rolfhut
Have you followed all the steps in?
https://github.com/pycom/pycom-micropython-sigfox#the-esp32-version

before doing the final step (make ... flash) also do this:

https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/README.md

CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM is defined in pycom-micropython-sigfox/esp32/sdkconfig.h so it sounds like your build environment isn't setup properly.

If you still can't get it work can you post exactly what commands you're trying?

[rolfhut]

@jmarcelino those are the ones I am now trying. I can go back to a single beacon type as soon as I get at least a single signal in. The beacons I use are programmable to be whatever standard we want to use.

I may pull out a Pi for this project, but the specs for the wipy were too good to not use if I could...

[jmarcelino]

@rolfhut said in no python prompt after downgrading firmware:

CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM

Ok I think I know the problem, you're using the old pycom/pycom-micropython repository instead of new https://github.com/pycom/pycom-micropython-sigfox

Please use pycom-micropython-sigfox (same for all boards WiPy, SiPy or LoPy)

[rolfhut]

@jmarcelino
done that just now, but still:

LINK build/WIPY/release/application.elf
text data bss dec hex filename
935673 167396 70320 1173389 11e78d build/WIPY/release/application.elf
Building partitions from lib/partitions.csv...
Traceback (most recent call last):
File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 356, in <module>
main()
File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 345, in main
table.verify()
File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 83, in verify
for p in sorted(self):
TypeError: unorderable types: PartitionDefinition() < PartitionDefinition()
make: *** [build/WIPY/release/lib/partitions.bin] Error 1

I'm about to give up and get a RPi.

[jmarcelino]

@rolfhut said in no python prompt after downgrading firmware:

gen_esp32part.py

I think this build script expects system Python to be 2.7 (macOS default, that's what I'm using here and it works) and you're probably setup as Python 3

[rolfhut]

@jmarcelino
switched to Python 2.7, now get this.

LINK build/WIPY/release/application.elf
text data bss dec hex filename
935673 167396 70320 1173389 11e78d build/WIPY/release/application.elf
Building partitions from lib/partitions.csv...
IMAGE build/WIPY/release/wipy.bin
esptool.py v2.0-beta2
Signing OTA image
make: *** No rule to make target build/WIPY/release/bootloader/bootloader.bin', needed by flash'. Stop.

I give up.

[jmarcelino]

@rolfhut
Well you built the application (MicroPython) already so giving up just at the last step? :)

Again I'd appreciate if you posted your commands, not just the results.

Have you done all the steps in the instructions i.e.

$ cd ../esp32
$ make BOARD=WIPY -j5 TARGET=boot
$ make BOARD=WIPY -j5 TARGET=app

Then connect P2 to GND and press reset button before :

$ make BOARD=WIPY -j5 flash

[rolfhut]

@jmarcelino I have followed all the steps here:
https://github.com/pycom/pycom-micropython-sigfox#the-esp32-version
which states to do
make BOARD=WIPY flash
and never mentions the two other build command you specify.
when I run all three commands you gave, it compiles, but now gives final error when trying to connect to the board (which, yes, is booted with G23 pulled to GND).
Is there a way to force use of a particular serial? I can see that my board is connected by
ls /dev/tty.usb*

anyway: the full error is:

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Flashing project
esptool.py v2.0-beta2
Traceback (most recent call last):
  File "/Users/rwhut/anaconda/lib/python3.5/site-packages/serial/serialposix.py", line 265, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/ttyUSB0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/esptool_py/esptool/esptool.py", line 2294, in <module>
    main()
  File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/esptool_py/esptool/esptool.py", line 2057, in main
    esp = chip_class(args.port, initial_baud)
  File "/Users/rwhut/Documents/sideProjects/BluetoothSoilMoisture/code/pycomTest/firmware/micropython/pycom-esp-idf/components/esptool_py/esptool/esptool.py", line 166, in __init__
    self._port = serial.serial_for_url(port)
  File "/Users/rwhut/anaconda/lib/python3.5/site-packages/serial/__init__.py", line 88, in serial_for_url
    instance.open()
  File "/Users/rwhut/anaconda/lib/python3.5/site-packages/serial/serialposix.py", line 268, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
make: *** [flash] Error 1

[jmarcelino]

@rolfhut
Great, glad you got it working. Yes, once the environment is setup you need to take a little detour to the up-to-date build instructions in the esp32 folder README - I linked that in my earlier reply here.

Now as you say it's a simple matter of setting the correct environment variable for your serial port before issuing the flash step:

export ESPPORT=/dev/tty.usb....

[rolfhut]

@jmarcelino
that fixed it.

I can now upload my own firmware. Your fix of increasing the stack and putting listining mode in PASSIVE doesn't help though :-(.

I'll see if I can go deeper into the scanning part.

thanks for all the help

Rolf