Search results for:

Thanks for insight. Btw is it possible to build firmware hex file so that something already starts at boot time without calling save? I am currently putting my stuff to DSD6 module in libs/js for now but that of course does not start. so is there better way than loading hex, running it, calling save or create .boot(0,1,2,3) files and then making .hex from it? I did read https://www.espruino.com/Saving but still not sure what is possible. Can I e.g. prepare .boot1 file and put it to libs/js so it is build as part of firmware?

Also what is best way to store relatively big data like bitmaps, fonts so it is not copied to RAM but could be read directly from flash as constants? I guess e.g. the initCmds array in SSD1306 module get allocated in RAM as it is now? I am looking at the fonts e.g. Font4x4Numeric.js and see E.toString() and also atob() but still not sure what get stored where. the module source get stored in flash as (possibly minifed) source code and when it is being run it creates another copy of data in ram/flash?

Checked https://www.espruino.com/Reference#l_E_t­oString and https://www.espruino.com/Reference#l__gl­obal_atob but it does not tell.

Just to let you know that I have 128x32 display in DS-D6 fitness tracker that skips lines with current code

0xDA, (C.OLED_HEIGHT==64)?0x12:0x02,

Even if it is 128x32 it works better with 0xDA, 0x12. Looks like it has RAM like 128x64. Not sure if it is normal for other 128x32 but it can hold two 128x32 images and I can flip between them by changing start offset.

So I got the display working with the SSD1306 module :-)

I spoke too soon. I see the text but every other 32pixel line is empty so text takes up double width. This is with height set to 32. I found this thread http://forum.espruino.com/conversations/­269330/ which discusses the issue but it looks like current SSD1306 module I use is already fixed like that. But when I set height to 32 it is wrong. And when leaving the default 64 it works a bit better. When I draw to normal coordinates 0,0 with 64 height set and call flip() I see nothing. But when I connectSPI to it again now with 32 height I see previously written data correctly how it should be. But any new drawings written with 32 height set are wrong again. Also when in 64 height mode I can write text to y=32 and it shows with correct size as if y=0, however only few (8?) 128pixel lines are working so when I write to e.g. y=36 the bottom of text is cut off so I cannot access lower part of display. I guess the initCmds and flipCmds arrays are not correctly set for my type of display but I don't know how to fix it. Any tips?

EDIT: Oh, got it. For some reason with my display the initCmds[15] should be 0x12 like for 64 height and not 0x02. When I keep 0x12 it works perfectly. Well it is mirrored so I need also setRotation(0,true) but then it is fine.

So I got the display working with the SSD1306 module :-)

SPI1.setup({mosi:6,sck:5,baud:8000000})
g=require("SSD1306").connectSPI(SPI1,D28­,D4,function(){g.drawString("Hello",0,0)­;g.flip()},{cs:D29,height:32})

Looks like I have most of the hardware pinout covered. I have updated HW summary here DS-D6 Hardware I still guess on some analog input there could be real battery voltage (NRF.getBattery() returns 3.3 which s already regulated)

So now let's see how far can I go with Espruino to do some watch interface - showing time, setting alarms etc. So far it looks pretty usable.

BTW I noticed some strange issue, the HR sensor needs to be enabled by pin 26. When it is not done any i2c read on its bus hangs (forever?) and ctrl+c does not work, is there a way to break it? Or maybe some timeout?

How complicated is to add support for two NRF52 I2C buses? Looks like this watch uses one for accelerometer and second one for HR sensor.It uses TWI0, TWI1 and SPI2 (for OLED). TWI0 uses scl 7 sda 8.

I don't think I2C2 is supported on Espruino since you can't have two SPI and two I2C.

oh, I see, I was confused by the board file having

  'spi' : 3,
  'i2c' : 2,
  'adc' : 1,

and I2C2 being defined. But since there are 3 SPIs too and the i2c/spi resources are shared it clearly cannot work for all five at the same time even if those objects are all defined in the interpreter, however I did not use SPI yet so in theory both i2c interfaces should be free to use.

Thanks for pointing the inverting code (would not have guessed it is done later at runtime), also will try with 'make clean', thanks.
EDIT: oh, checked the file you linked and the answer to SPI/I2c is there too
https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/jshardware.c#L75
so currently just one SPI and one I2c. So perhaps the board file should reflect that if those numbers have any efffect on generating those SPIx and I2Cx objects at runtime.
EDIT2: and indeed they have, I have reduced i2c and spi to 1 and jswrapper.c no longer has those not supported ones generated.

Honestly, not sure why it's doing that

As for i2c for some reason it did not work with I2C2. It did work however with I2C1. So I2C2.setup({scl:13, sda:14, bitrate:400000}) did nothing, I did also break into debugger after that and HW registers were still at default values for both TWI ports. I2C1.setup({scl:13, sda:14, bitrate:400000}) however did work and when using I2C1 for scannig the bus I got exceptions except 0x1F address which was expected. There should be KX022 accelometer. BTW is there some Espruino module for this one? I see it was mentioned in this thread but I don't see it here https://github.com/espruino/EspruinoDocs­/tree/master/devices

but why not just look at the PCB (or even the manufacturer's docs) to try and find out what the I2C parts are then try and look at those addresses?

Because I wanted to test i2c functionality - scanning the bus looks like good test.

As for the negated button - it doesn't work. It is still as before - returning false when pressed and true otherwise and BTN1 gives

>BTN1.getInfo()
={ 
  port: "D", 
  num: 30, channel: 6, 
  functions: {  }
 }
>BTN1.getMode()
="input_pulldown"

so the line

  pinutils.findpin(pins, "PD30", True)["functions"]["NEGATED"]=0;

seems to have no effect. I did find it used in boards/NRF52832DK.py in same way.

gen/platform_config.h has

[#define](https://forum.espruino.com/sea­rch/?q=%23define) BTN1_PININDEX 30/* D30 */
[#define](https://forum.espruino.com/sea­rch/?q=%23define) BTN1_ONSTATE 1
[#define](https://forum.espruino.com/sea­rch/?q=%23define) BTN1_PINSTATE JSHPINSTATE_GPIO_IN_PULLDOWN

EDIT:
oh, there is scripts/build_pininfo.py which is using NEGATED and then there is build_platform_config.py which tests for "inverted". And no code to automagicaly negate pulldown to pullup.

EDIT2:
however gen/jspininfo.c contains

/* PD30 */ { JSH_PORTD|JSH_PIN_NEGATED, JSH_PIN0+30, JSH_ANALOG_NONE, { 0 } },

so the 'NEGATED" works after all? but it still returned true when not pressed

Did you try it?

Not yet, I better asked.

It's pull down because it's also inverted. Check some of the other .py files in the boards directory.

Yes, I've seen it some board files, just was not sure. I was thinking inverted means the bit is just flipped in software before returning it back to js code while the pinstate should set pull up/down right in the HW registers. OK thanks for explanation, will try.

It's not that useful on nRF52 as I2C/SPI/Serial can be on any bit

Yes it can be on any pin but in this watch it is on specific pins so if it would set some predefined values out of box so one could just use it without setup in code it would make some sense.

'BTN1' : { 'pin' : 'D30', 'pinstate' : 'IN_PULLDOWN' },

Is it pull up or down? Since when the button is not touched the value is high and goes low when touched shouldn't this be pull up? or is there just 'INPUT' with no pull as it is always connected and not left floating

looks like scl:13 or/and sda:14 is not used for I2C on this device.

could be some mistake on my part, will double check but this is what I got from register dump when running the firmware and stopping it in gdb over swd https://github.com/fanoush/ds-d6/wiki/Ha­rdware

0x40004500: 0x00000005
0x40004508: 0x0000000d
0x4000450c: 0x0000000e
0x40004524: 0x06680000

which I guessed is TWI1 with scl 13 sda 14 speed 400kbps
as per https://infocenter.nordicsemi.com/index.­jsp?topic=%2Fcom.nordic.infocenter.nrf52­832.ps.v1.1%2Ftwi.html&cp=2_1_0_48_7_5&a­nchor=register.PSELSCL

Check i2cdetect for a simple scanner

Thanks a lot, this is what I was looking for :-)

Thanks guys.

I figured out the touch button - pin30 reversed (low when pressed) and charging/power status. Those were the easy ones. I put my current board diff here https://github.com/fanoush/ds-d6/wiki/Es­pruino I an confused about the pinutils.findpin section, what it is need for? What are correct names for pins and interfaces there? Pins are not Dxx but PDxx and names like UART or USART look random across different boards.

Also how do I tell that the DFU bootloader should use negated touch button on pin 30?

I also tried to scan I2C but basically any address returns some data. I used I2C2.setup({scl:13, sda:14, bitrate:400000}) and when using I2C2.readFrom(address, 1) with random adresses it always returns something - mostly array with [232] value. What am I doing wrong? How to scan i2c for devices in espruino?

Yes, I never used SWD debugging before. Just recently I discovered that blackmagic probe firmware is available for bluepill - $1.67 STM32 board I had in drawer, so this was first time I used it. It is cool to stop existing firmware in any point and see HW registers. I did it both in DFU bootloader (serial enabled, i2c not) and app (serial not enabled but i2c yes) and with display on and off, charging/not charging - one can find a lot of basic stuff with that :-) I saw in datasheet section about the MWU — Memory watch unit. I wonder if it could be used to trace writes to peripherials at runtime with stock firmware still running?

Also I wonder how long the battery will last with espruino flashed and bt enabled (and console on serial). It did last over night but I don't see how much battery is left.

Just to let you know that I rebuilt Espruino from source, started from MDBT42Q board but removed LEDs etc and changed usart pins, flashed the result from gdb and now I have Espruino with serial console on usb data pins for further exploring :-) Also bluetooth works of course, console was default on bluetooth so I had to do Serial1.setConsole(false) over BLE connection first.

I figured out the pins first by dumping hw registers for USART,TWI,SPI in gdb, currently I know there is TWI2 scl 13 sda 14 ,SPI2 master sck 5 mosi 6 miso -1 (display?) and UART rx 22, tx 23. Time to go to sleep.

Anyway, I like that the USB data pins are connected, so one has two gpios or console without taking it apart. Not bad for $8 watch :-)

Yes, you're right. I already tried and mostly failed. Updating soft device to 2.0.1 worked fine and original app works with such minor upgrade. However my app flashed to 0x1c000 linked to soft device 2.0.1 does not start, it reboots to DFU/bootloder. Later I found this https://infocenter.nordicsemi.com/index.­jsp?topic=%2Fcom.nordic.infocenter.sdk51­.v10.0.0%2Fexamples_ble_dfu.html "Note that if you program a DFU bootloader on the device, you must use this bootloader to install the application. Programming the application with other tools will not update the bootloader settings, which means that the application might not start. Erase the device if you do not want to use the DFU bootloader anymore." so it looks indeed tricky.

However I already tried to restore from backup and it works (except maybe UICR area, will try that one too) so I am now confident enough to clear everything. So I'll try newer easier stuff first.

Still, to allow updating current watch firmware over bluetooth, I should figure out how the update with existing bootloader and soft device works. I don't want to open second watch. Hopefully with such old soft device the DFU update procedure is not signed.

And btw it is currently $8 watch at gearbest :-)

I'd just try writing an existing Expruino MDBT42Q hex file to it and see if you have any luck.

This will probably overwrite soft device and bootloader?
At first I wanted to only rewrite user app space as I don't understand yet how the boot loader + soft device + app works regarding reset vectors and startup and link dependencies. Curent bootloader does OTA update over BLE so I guess it is dependent on 2.0 soft device? so I should either overwrite just the app or everything including bootloader? And then I also need to modify UICR vectors so it boots properly after power up if the bootloader start at different address? Can I link espruino to SD 132 2.0 (id 0x81) or is is just too old? According to table here it means I need to link SDK 11. Can I update just soft device from 2.0.0 to latest 2.x which is 2.0.1 (id 0x88) and will existing bootloader still work? You see it is just too many questions so I'd better start just with reflashing the user app :-) I think I do have backup of whole flash so most probably nothing can go wrong and I can revert everything back but I'd still try in smaller steps if possible.

Just to let you know that I managed to attach gdb over SWD and backed up the firmware and created github repository https://github.com/fanoush/ds-d6 with the files and some basic info. I'll try to build micropython or espruino whichever will be easier to build for bare nrf52832_512k_64k I guess it may be easier/faster to scan and test various buses and hw attached to it interactively than writing/building/flashing C code.

It uses S132 v2.0 Softdevice so I hope when linking and flashing to 0x1c000 it will start up and I won't break anything. DFU bootloader is probably starting at 0x78000

Just a heads up - if anyone wants Nordic bracelet with BW oled screen there is N52832 based one currently on sale here https://www.gearbest.com/smart-watches/p­p_1232618.html?wid=1433363

My photo with front glass removed https://pasteboard.co/HMcXmdl.jpg is matching the board
photo on FCC site https://fccid.io/png.php?id=3414019&page­=2 so the other side most probably looks like this https://fccid.io/png.php?id=3414019&page­=3 :-)

For more details see my findings here https://gitter.im/nRF51822-Arduino-Mbed-­smart-watch/Lobby?at=5be3fbf36b9822140df­92510

I've yet to try SWD test points with blackmagic probe tonight but if it works it is sure thing :-)

And BTW if you don't like heart rate sensor and the wristband/usb charging type, there is almost identical one - Lenovo HX06 which is a bit different, however it is more expensive even when on sale and it is not on sale so often https://www.gearbest.com/smart-watches/p­p_1830584.html?wid=1433363 This HX06 one has FCC ID https://fccid.io/2AEMN-D16 according to photos in user reviews.

So I got third bracelet. This one is ID115HR clone with BW OLED screen. It was cheap and quality was pretty bad - it had some dirt under screen, OLED was misaligned so few rows of pixel were not seen at all. And also the heart rate sensor produced similar random values between 60-90 no matter if I wear it or just point it to empty space. Also when moved it turned screen randomly on and quickly off. So I got full refund, then opened it to clean the dirt and try to align the display. I also checked the chip markings of course and it is Realtek 8762AG. So yet another one. I found some datasheet with register descriptions and memory map and even some development board with SDK download. However my board have strange set of points I wonder which ones are for debugger?

What may explain why firmware update of i9 does not work is that it is most probably not Nordic based after all. While trying to put it to DFU mode and searching for services and guids I noticed it is quite different from what it should look like. I found one service F000FFC0-0451-4000-B000-00000000000 with two characterictics Img Identify, Img Block and google found this https://e2e.ti.com/support/wireless_conn­ectivity/bluetooth_low_energy/f/538/t/61­8391?CC2541-OTA-which-advertisement-char­acteristic-to-send-OTA-message-to-
So most probably the device is CC2541 based. This is bit of a letdown since I don't like 8051 very much and from specs it looks like there is only 8KB SRAM. OTOH the device is still hackable and TI provides tools and documentation. But it does not look like good espruino target after all.

So this is similar to what @ColinP already described previously in this thread "This device uses the Nordic Bluetooth service UUID and shares an app even though it doesn't have a Nordic chip in."

EDIT: As for TI and tools - it is much worse, the compiler is $2000 IAR Workbench, looks like there is no other option https://e2e.ti.com/support/wireless_conn­ectivity/bluetooth_low_energy/f/538/p/18­2785/715834#715834
however this is promising https://sourceforge.net/p/sdcc/mailman/m­essage/33226999/

I got earlier V2 Droihealth apk, it is not so obfuscated so most code is present and it looks like is support (mostly?) Nordic based devices since the firmware update code uses DFUService classes from Nordic. Howewer that older version does not suport I9 device. Also I found the device is sold with Lynwo I9 name so this gives some interesting google hits.

As for firmware my device shows version V3.11, it can be seen on different youtube videos that versions V3.06 and V3.12 are available https://youtu.be/Sm2Nqy8hT_0?t=31


https://youtu.be/3pZ1ieWn6Nk?t=55

yet the app does not offer me update from 3.11 to 3.12 :-( I will check the traffic but guess it will be https.

As for the ID brand, that's why I got the ID115 one but sadly the one I got is not Nordic based.

No I don't have the firmware. And sadly the DroiHealth android app is obfuscated so cannot be decompiled easily to see how the firmware is downloaded. But I'll try more.

BTW as for the firmware I had better success with another similar bracelet I got randomly from aliexpress at the same time. It looks exactly like this one http://www.globalsources.com/gsol/I/Smar­t-bracelet/p/sm/1161181278.htm#116118127­8 and the android app is called YOHO sports The app can be easily decompiled so it can be seen how it communicates with the bracelet all the service guids and structures are there. Also when I first connected it and tried firmware update, it downloaded something and updated the device successfully via bluetooth. I now see the code and it connects to alibaba oss cloud storage with all the firmware files supported by the app. The storage has structure of different folders for different device models/displays/chips like HSD_0.96 BOE_0.96 DY_0.42 MC3631 MC3413W HRS3300 each having separate firmware. Unfortunately the MCU is not made by Nordic but possibly by mCube I got the device for $9.79 but for some reason that aliexpress seller raised the price to $17.48 now! https://www.aliexpress.com/item/ID115-PL­US-HR-Smart-Bracelet-2-Replace-Straps-Sp­orts-Wristband-Fitness-Tracker-Heart-Rat­e-Monitor-Pedometer/32878474822.html however other sellers still sell it in ~$10 price range. The battery life is worse. I used it far less and already had to charge it again after few days. The features are very similar and I can't decide which one I like more.

FWIW this bracelet I got https://www.gearbest.com/smart-watches/p­p_009557274002.html is reported by nRF Connect as made by Nordic Semiconductor so it may be good hacking target? Looks like it is this one http://www.globalsources.com/gsol/I/Smar­t-bracelet/p/sm/1160255861.htm

Otherwise it is usable bracelet with average/poor fitness app DroiHealth but everything works and battery life is good. I charged it when I got it last week on Wednesday and it still reports %62 of battery today after wearing it almost every day/night. The app has firmware update option over bluetooth but sadly it is up to date so currently there is no firmware update available.