nRF5 action!

[Toyman]

@neverdie what are potential advantages of micropython?

[NeverDie]

@toyman OTA updates.

[Toyman]

@neverdie I am afraid it still relies on Softdevice

[monte]

@toyman no, if your code is in python. So the deal is "just" to port mysensors to python.

[NeverDie]

@toyman Micropython on the BBC micro:bit (which uses the nRF51822) has a Radio library that uses Nordic's proprietary radio modes and doesn't involve Bluetooth. I suppose the question is: what would be involved in getting it to run on the nRF52832 or the nRF52840. Seems like it would be substantially the same.

Faiing that, if I can directly manipulate the radio registers from miropython as I can from C, then it shouldn't be too hard to get at least minimal radio capability up and running from within micropython.

If I can get rudimentary radio communications working in micropython, then from there it should be easy to do OTA updates via REPL. I did some proof of concept to that effect on the micro:bit, but quickly ran out of memory--the micro:bit has only a total of 16K of RAM, so there's very little headroom to begin with. On the nRF52840, lack of RAM shouldn't be an issue.

[NeverDie]

@scalz hinted at it previously, but it looks like MyNewt OS might offer yet another way to do OTA updates. According to their posted information, it offers:

A open-source Bluetooth 5.0 stack (both Host & Controller), NimBLE, that completely replaces the proprietary SoftDevice on Nordic chipsets. (https://github.com/apache/mynewt-core/blob/master/README.md)

Apparentlly it runs on both the nRF52832 and the nRF52840.

[speechsupply]

@neverdie
1737 posts and counting
Spend hours reading this. Amazing journey so far.

[Uhrheber]

@neverdie There are three ways to manipulate registers directly from Micropython:

1. Use machine.mem16

2. Use the decorator @micropython_viper
   The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

3. Use the decorator @micropython.asm_thumb
   Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

[Toyman]

@speechsupply this thread is golden. I was so empowered that was able to easily switch to nRF SDK and to start producing (semi) commercial BLE-ANT device

[speechsupply]

@toyman
Yea, On monday I'll order a couple of nRF52840 EVAL boards. Any suggestion regarding what to get?
Looked at both the BMD-340-EVAL and ofcourse the NRF52840-DK

[NeverDie]

@uhrheber said in nRF5 action!:

@neverdie There are three ways to manipulate registers directly from Micropython:

1. Use machine.mem16

2. Use the decorator @micropython_viper
   The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

3. Use the decorator @micropython.asm_thumb
   Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

Thanks! We finally nailed it all the way down on this thread here: https://forum.micropython.org/viewtopic.php?f=12&t=5377

:smiley:

[Omemanti]

I see somewhat strange behaviour when using millis() for intervals.

I'm not sure it's my mistake, but one thing is that it seems that the millis rollover is around; 131.068.570 (36 hours)

When the rollover happens, it looks like it interrupts my sleep. Does that make sense?

sleep(digitalPinToInterrupt(PIR_Pin), CHANGE, LongSleep); 

Debug lines => (Temp / RH - Millis)

21.44 / 61.15 - 130977952
21.43 / 61.16 - 131008158
21.42 / 61.15 - 131038364
21.44 / 61.14 - 131068570
I woke up because I saw movement at: 26576
Sleep Duration : -131042000  Im going back to sleep for 150000       
21.43 / 61.16 - 176822

20-10-2018 => its been ±36 hours laters, and he woke up again at the same moment.

18.57 / 56.88 - 131007553
18.56 / 56.86 - 131037759
18.58 / 56.85 - 131067965
I woke up because I saw movement at: 25971
Sleep duration : -131042000 => Rollover??
18.55 / 56.89 - 206423
18.53 / 56.89 - 236628
18.54 / 56.90 - 266834
18.55 / 56.89 - 297040
18.54 / 56.90 - 327246

[Omemanti]

@maciekczwa said in nRF5 action!:

Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241270
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 478
in procedure 'ocd_bouncer'

**embedded:startup.tcl:454: Error: ** Unable to reset target ****
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 479
at file "embedded:startup.tcl", line 454
wybrany port szeregowy at file "embedded:startup.tcl", line 454

maybe someone else already found the solution, but it took me a while to figure it out for myself.

So for documentation sake:

Just had the exact same things with new Ebyte NRF52832 modules, ST-Link v2 couldn't erase it. (the old once did erase without a single problem )

After some digging, I found the following:
(I'm using my NRF52832-DK for it, maybe other devices work as well, just tested this one)

DK => Ebyte module
GND(detect) => GND
SWDIO => SWDIO
SWDCLK => SWCLK
VTG => 3,3V
3,3V => 3,3V
GND =>GND

you can erase the protection using nRFgo Studio

1. On the left, you can find a header named Segger, click on that.
2. then it shows that it is locked, and you can click recover.
3. after that you can erase it
4. upload a new sketch using an ST-link V2 or the DK while you are still at it.

[alowhum]

@alowhum said in nRF5 action!:

This looks like an Arduino-nano/pro-mini style device with an NRF51:

https://www.aliexpress.com/item/Nrf51822-LIS3DH-Bluetooth-Module-CJMCU-8223-Bluetooth-acceleration-module/32821873481.html

I tried uploading a simple blink sketch today. I found some code on github which suggested pin 23 and 24 are LED pins.

I got an error uploading via STM32 though.

debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.233552
Warn : UNEXPECTED idcode: 0x0bb11477
Error: expected 1 of 1: 0x2ba01477
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

[Toyman]

@omemanti actually, all you need is to issue the following command:
nrfjprog.exe --recover

[Omemanti]

@toyman yup, I tried that one, but all it kept saying was something like; can't find programmer.. and this method, which has a GUI, worked without incident :)

[Toyman]

@omemanti that's strange, I use the methos regularly and it worls fine.
Oh! Actually, sandeep's installation messes up Jlink drivers so they require reinstall for the method to work.
That's why I am using arduino nrf5 with BMP to completely separate Arduino from Jlink

[NeverDie]

FYI, I'm switching from uPython over to uLisp. It already worked on the BBC:microbit, and I just now got uLisp working on the nRF52832. Because uLisp relies on Sandeep's library, it doesn't yet support the nRF52840. However, if/when Sandeep's library does support the nRF52840, the uLisp upgrade will be fairly easy.

http://www.ulisp.com/

[Nca78]

@neverdie said in nRF5 action!:

FYI, I'm switching from uPython over to uLisp.

What is the reason for this switch ?

[NeverDie]

@nca78

1. uPython seemed to require an intimate understanding of a rather complicated build process. I kept running into build-related snags. Maybe in the future they will simplify it.
2. Its garbage collector can't handle heap fragmentation, and it appears that it never will.
3. Adding c-extensions is a rather arcane process.

In contrast, the uLisp build process is far simpler, and uLisp appears to have a proper garbage collector. Adding c-extensions is relatively easy.