support NRF sensor tag board

[askvictor]

A cheap NRF51 based sensor tag board can be found on ebay or aliexpress for $10-$15, and is loaded with sensors and a CR2032 battery holder. I can't find a definitive name for it, but have found docs, schematics etc at http://linksprite.com/wiki/index.php5?title=Bluetooth_4.0_BLE_Sensor_Tag/iBeacon_Station_NRF51822. Not sure if there is a better place to put this, but it seems better than the upstream PR where I initially posed the feasibility of this.

[aykevl]

Patches are welcome :) We don't have the board itself so can't create a port ourselves. If it doesn't really have a name, why not just sensortag? By the way, did you see this one? It looks suspiciously similar.

Not sure if there is a better place to put this, but it seems better than the upstream PR where I initially posed the feasibility of this.

Yeah it should go into this port - the nrf port hasn't been merged yet so upstream MicroPython can't really support this board.

[askvictor]

Yeah, that's the same one; I found the docs link from that forum. sensortag is good; I'll document any progress I make here (which might be slow and intermittent); I'll probably need to be asking a heap of questions about the dev environment/toolchain as they're new to me (and not documented-in-an-ELI5-way)

[askvictor]

@aykevl I've managed to compile successfully, but haven't managed to flash using openocd successfully yet. Or rather, I can flash, but not along with the softdevice. When I flash the micropython firmware, it appears to overwrite the softdevice image. I've tried both the program and flash write_image commands, but when trying to verify the image (or read it back and check manually), only the micropython image is there. Any ideas?

EDIT: I've tried merging the hex files with nordic's mergehex utility, and it tells me it can't as there are conflicts; I figure this means the firmware.hex being generated isn't factoring the offset required for the softdevice? Also, is it necessary to flash a bootloader (a bunch of other projects flash a bootloader as part of the process)?

EDIT2: looks like I wasn't compiling with the SD=s110 option. Now it flashes correctly along with the softdevice. However, I'm not finding any bluetooth devices from my scanner :(

The board is too tiny to practically solder real serial pins to it, so I'd rather the softdevice approach

[aykevl]

Ah, I see you figured out what was wrong :)

Did you enable NUS? See MICROPY_PY_BLE_NUS in bluetooth_conf.h.

A trick I sometimes use to see in what state the chip is, is calling reset and then halt in the OpenOCD console. A halt will show the current CPU state (Thread, SVCall, HardFault) when it was running before the halt. It also gives the PC (program counter, or address of the currently executing instruction) at the moment of halt, which can be used to inspect which function was executing in Thread mode. A HardFault can also be debugged but that's a bit more difficult (actually requires a connected debugger).

In some cases, an incorrect flash/reset order can cause problems. To fix that, do a halt, complete erase (nrf51 mass_erase), program the SoftDevice and application, and only then reset. I think it happens when doing a reset when no application has been flashed.

Another hint: I've noticed the SD (SoftDevice) can mess with the ability to properly halt, causing all sorts of problems. Doing reset; halt in the OpenOCD shell fixes that.

An application that I often use to debug BLE problems is nRF Connect (Android). It doesn't do much on it's own but can be used for scanning and basic reading/writing of attributes.

[aykevl]

Here is something that might be interesting: https://github.com/micropython/micropython/pull/3703 The idea is to have a REPL over the debug wires instead of UART, for boards like these.

[askvictor]

Indeed; I had forgotten to enable NUS since I had set up the debian build env. Now fixed, and it now advertises a NUS, but connecting to it (from the nrf UART android app) only echoes back the characters I type; doesn't show any signs of python. I can't really get the nus_console or webbluetooth to work as I don't have a linux machine handy.

[aykevl]

I've tried the UART app before but it doesn't seem to work, probably because it doesn't send newlines (or doesn't send them in the way MicroPython expects).

I have written a WebBluetooth console for NUS in the browser, you can try it over here on an Android device: https://aykevl.nl/apps/nus/ It's not perfect, but it sort of works (for me).

[askvictor]

And it works! Next step I'll get the pin defs worked out. Thanks for your help!

[aykevl]

Awesome! Yeah that may be the hardest part, getting the sensors to work.

[askvictor]

What's the 'micropythonic' way to include/freeze (python) modules in the firmware? I've found a couple of different approaches (e.g. https://learn.adafruit.com/micropython-basics-loading-modules/frozen-modules) but they seem to be specific to certain architectures/boards, and I can't find any straight python modules in the nrf port.

Given that upip isn't really feasible due to lack of network connectivity, I'm figuring the best approach is to include the base functionality, but it would also be a little nicer to reference the modules direct from their source rather than just dropping the files onto the device.

[aykevl]

There are two ways of including Python scripts directly on the device:

• Drop them in a directory and compile with FROZEN_MPY_DIR=yourdirectory. This is documented in the README. Modules added this way will be built in the firmware itself.

• Add filesystem support by enabling the filesystem option (e.g. in your mpconfigboard.h). When enabled, you can upload files directly with a tool like ampy. For BLE, I have written something but it is still very unreliable.

  #define MICROPY_HW_HAS_BUILTIN_FLASH (1)

  This option should probably be included in the README.

[glennrub]

In order to clean up a bit i'm closing this issue in this repo as the continuation of the nrf-port development should happen in mainline micropython repository after the merge. If the issue is still applicable it could be raised towards mainline repo.