nRF5 action!

NeverDie

@alowhum said in nRF5 Bluetooth action!:

STLink V2

I can't comment on the STLink V2, but if using a JTAG, you want to power the module independently from the programmer, because the programmer is meant to sense the voltage there more than to supply it. Maybe worth a try? Looking back, I've often thought it may be the reason why my early attempts with the STlink V2 failed. At least it's something you can look into while you wait for the cavalry to come rescue you.

Also, not sure as to whether running on a Mac is a good idea.

alowhum

W00t! Hurray! Nevermind. I just tried my other module, and that one worked fine!

Open On-Chip Debugger 0.10.0-dev-gdc53227 (2016-04-09-13:45)
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 v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.239128
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : nRF51822-QFN48(build code: B00) 512kB Flash
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 4096 bytes from file /var/folders/pg/bjymtmv12dv77vh__zxyvs600000gn/T/arduino_build_362545/MyBoardNRF5.ino.hex in 0.215516s (18.560 KiB/s)
** Programming Finished **
** Verify Started **
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
verified 2768 bytes in 0.065170s (41.478 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

I had to do "burn bootloader" once to remove the security. And then it worked!

Hmm "reset enable" is still turned on. What does that do exactly?

NeverDie

Glad you found the breakout board useful. I hesitated to post it, thinking it might be too "easy," and it never did get many likes.

alowhum

@neverdie: yes very useful! I was thinking I should buy some, and wanted to explore which ones could be bought without a credit card (Europe..).

Perhaps you can entice some Chinese manuafacturer to put create a lot of them and then sell them on Aliexpress ;-)

mfalkvidd

@neverdie I think these are your design? Bought some when I was ordering some other stuff from Pcbway but haven't gotten around to using them yet.

NeverDie

Yup. Those little boards are really quite handy.

Thanks for the photo! :)

Mars Warrior

Nice indeed. I was just about to order some of those breakouts after receiving 4 Ebyte modules (€8 total).

But just to make sure (I didn't read the complete thread...), the capacitors for DEC1, DEC3 and DEC4 are already present on the Ebyte module, so no need to add these on your breakout, @NeverDie ?

NeverDie

No need to add anything not already on the board.

Omemanti

You could add some inductors for dcdc mode

Mars Warrior

@omemanti Yes I will. This is a long thread to catch up ;-), but I did find that the latest revision of the breakout added room for the inductors to use the DCDC mode.

I guess it takes some more reading & doing to get the firmware loaded on those Ebyte modules, but as others did that already I'm confident that that will be ok!

It will be my first nRF52 application.

nagelc

I'm working on a gesture sensor connected to a Fanstell BT832 via I2C. It is a Sparkfun APDS9960 breakout I have had lying around for a while. Unfortunately I can't get my sketch to compile. It gives 'Wire' was not declared in this scope.
Wire.h is included in the library and in the sketch. I'm using MyBoardNRF5 for an NRF52832. Using Arduino 1.8.3 on Windows 10.
There is a wire library in:
\AppData\Local\Arduino15\packages\sandeepmistry\hardware\nRF5\0.5.1\libraries\Wire
Which I think is the one that this sketch should be using.
Usually I can sort out the compile errors, but this one has me stumped.
Anyone have any suggestions?

mfalkvidd

@nagelc if you turn on "show verbose output during compilation+upload" in File->preferences you should get output telling which library the Arduino IDE has chosen.
The following sketch:

#define MY_RADIO_NRF5_ESB
#include <Wire.h>
#include <MySensors.h>
void setup() {
}

void loop() {
}

Gives this result for me:

Using library Wire at version 1.0 in folder: C:\Users\Micke\AppData\Local\Arduino15\packages\sandeepmistry\hardware\nRF5\0.5.1\libraries\Wire 
Using library MySensors at version 2.3.0-alpha in folder: R:\Documents\Arduino\libraries\MySensors

nagelc

@mfalkvidd Thanks. The verbose settings show it using the sandeepmistry library.
Wire.h works fine when I include it in my sketch. There is something about the way it is called in the Sparkfun library that fails to compile. I'll keep poking at it.

Duh . . . Found the problem!
I had left WIRE_INTERFACES_COUNT defined as 0 in MyBoardNRF5.h
It has to be #defined to 1 or more, or the sandeepmistry library doesn't extern Wire.
I looked at the SDA and SCL pin definitions in MyBoardNRF5.h, but missed setting the define for how many I2C interfaces were to be used.
Change #define WIRE_INTERFACES_COUNT 1. Now it compiles as expected.

alowhum

This might be a silly question, but: there there a number of NRF5 smart watches available on Aliexpress, like this one. Would it theoretically be possible to turn that into a MySensors smart watch? If you had access to the programming pins, for example?

NeverDie

@alowhum Usurping control of it by uploading code wouldn't be difficult, assuming access to the programming pins. However, taking control of the screen and making good use of it might be difficult

scalz

yes it's doable, maybe not for those who are not smd friendly. And once opened it should be less waterproof :sweat_smile:

Toyman

@alowhum there is a whole "movement" of people who are trying to reprogram them. Key issue is openability (how hard is to open it)
The last easily openable watches are based on nrf51822, but the good thing is that programming pins are easily accesable and even marked SWD/SCLCK.
Search Ali for ID107HR and google for "roger clark smartwatch"
I am yet to find a watch that would be both nrf52 based AND easily openable

Toyman

https://github.com/micooke/arduino-nRF5-smartwatches

Mark is a fantastic guy

NeverDie

@toyman said in nRF5 Bluetooth action!:

"roger clark smartwatch"

Seems like there is hope then of accessing the screen after all. On http://www.rogerclark.net/arduino-on-the-id100hr-fitness-tracker/ it says: "Display: 0.49 inch OLED display (64×32 pixels) which uses the SSD1306 display controller"

NeverDie

Maybe someone here can figure out how to 3D print their own nRF52832 smart watch? i.e. one that's meant to be taken apart and put back together so that it's as good as new.

nRF5 action!

18

11.7k

11.2k

113.0k