-
-
the
espruino_2v09.134_nrf52840.hex
is most probably full hex file with softdevice included. to build--application
dfu zip you should take the intermediate file called espruino_2v09.134_nrf52840.app_hex which is only the application.Also the softdevice version must match what adafruit bootloader currently uses. Or if it doesn't use any softdevice (the newest one can be build like that?) you probably need to flash matching softdevice too - make another zip package with
--softdevice
softdevice.hex , not--application
and flash both zips separately. see the end of espruino build output for file names, you should see mergehex running.or alternatively it may be easier to convert full hex file you have to uf2 instead of dfu zip and flash that over usb as per https://github.com/adafruit/Adafruit_nRF52_Bootloader#making-your-own-uf2
-
I modified my board definition file with 'BTN1' : { 'pin' : 'D3', 'pinstate' : 'IN_PULLDOWN' } and invoked make with argument BOOTLOADER=1. Is this enough?
The line
'bootloader' : 1,
here enables bootloader and it is built as part of running make. If you use SWD you can even disable bootloader by setting value 0 there to make it more simple. Anyway when checking MDBT42Q.py board definition now, there is also LED1 on pin D1 so that one needs to be moved too. LED1 is optional so you can remove it completely. Button is also optional if you disable bootloader. Also you can set thedefault_console
toEV_BLUETOOTH
if you want to remove serial pin definitions too. -
That post you linked is excellent summary, thank you. Of course the calibration takes power, nice someone took care to compute that part too.
BTW if schematics in the Holyot YJ-17095 page is correct the DCDC should be supported there. It saves most power when current is high = bluetooth transmit. Now found source for information in that article I linked previously here https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf52-designs
For enabling DCDC define
ESPR_DCDC_ENABLE
as checked here https://github.com/espruino/Espruino/blob/99541c982aeef8114374cc673919fc42f1f874c7/targets/nrf5x/bluetooth.c#L2458 -
Oh, so you want to add crystal to existing MDBT42Q board? And now I also noticed
I would like to use the external low-frequency 32678 kHz crystal to improve the board power consumption when used as a beacon.
How much of power you expect to save? It may not be that much and it is likely other components on board may draw more. See e.g. this https://devzone.nordicsemi.com/f/nordic-q-a/25540/is-external-crystal-neccessary-at-all-on-52832/100707#100707 so it is really not much. Was thinking you already have board with the crystal and just want to enable it so it is not sitting there wasted.
And BTW there is also the builtin DCDC converter, it could save more if used , that is however more complicated to enable as it needs more components. see https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=4_2_0_17_0#topic and https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/ref_circuitry.html?cp=4_2_0_52_1#schematic_qfn48_dcdc
just googled and here https://www.programmersought.com/article/18503111047/ someone claims enabling DC/DC can save 40% and crystal 1-2%
Anyway, yes those board file changes will help freeing D0 pin, however you need to build and update also the bootloader as that is where the button is actually checked.
-
there is also some info in the other thread
http://forum.espruino.com/conversations/365203/#16063775 -
the software config is here https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L2365
If you would use Nordic SDK directly, LF source it is typically chosen in the SDK config file https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/nrf52_config/sdk_config.h#L262 (in newer SDKs there are actually two settings there to change, one generic and one for the softdevice)
-
-
Going to have to find the data sheet for the AT6558.
Got some stuff mostly in chinese, one link to english datasheet here https://github.com/fanoush/ds-d6/tree/master/espruino/DFU/B5#hardware however the commands were in different one, google for "CASIC Multimode Satellite Navigation ReceiverProtocol specification" , see also this https://gist.github.com/fanoush/505a6f44532e4fdaadef4da5777d7777#file-b5-demo-js-L280 it can enable all three GPS providers (GPS,BDS,GLONAS)
there is also some AGPS sdk stuff on manufacturer's site that seems to work and produce AGPS binary data suitable for this chip
-
I'm using precisely this as it is what most smart watches do to enter bootloder, so something like this could work
+++ b/targets/nrf5x_dfu/main.c @@ -100,13 +100,39 @@ bool dfu_enter_check(void) { [#else](http://forum.espruino.com/search/?q=%23else) dfu_start = dfuIsColdBoot; // if no button, enter bootloader if it's a cold boot, then exit after a few seconds [#endif](http://forum.espruino.com/search/?q=%23endif) + if (NRF_POWER->GPREGRET == 1) { NRF_POWER->GPREGRET=0; return true; } [#ifdef](http://forum.espruino.com/search/?q=%23ifdef) BUTTONPRESS_TO_REBOOT_BOOTLOADER^M // if DFU looks invalid, go straight to bootloader if (s_dfu_settings.bank_0.bank_code == NRF_DFU_BANK_INVALID) { lcd_println("BANK0 INVALID");
so just one line to put here https://github.com/espruino/Espruino/blob/master/targets/nrf5x_dfu/main.c#L103
and then just
poke32(0x4000051c,1)
triggers DFU. However as Gordon mentions it is a bit dangerous, anyone can trigger DFU update remotely if you don't set up console password or other protection (like whitelisting/refusing unknown connections) -
anything you like to share?
as for sizing variables - not much right now, there is old conversation about this starting here http://forum.espruino.com/conversations/338789/?offset=25#14922414
and it is true that it brings some additional complexity so basically I was just testing the idea with no expectation this could get merged. Currently I don't have the persistence of the change across reboot working, just sizing at startup according to what soft device needs - so with static MTU there is currently no variability => it always autosizes to same size as it is now. The only difference is that you don't need to tune where data segment starts in linker file according to MTU like it is done now here https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/nrf5x_linkers/linker_nrf52_ble_espruino_bootloader.ld#L7 You size variables to maximum value in board file like if it would start at 0x20000000 with no softdevice at all and it then scales down. So in a way it is more simple than it is now. On the other hand the number of variables in board file is then just theoretical maximum to keep enough space for static variables and stack, not the real value, which may be confusing.Currently bluetooth on nrf52 is initialized before variables (= calling jsvInit() in main.c) so the available size for variables is already known when needed. This initialization order even now causes another issue here https://github.com/espruino/Espruino/issues/1696 as BT code tries to read MAC address from uninitialized variables. Which also suggests that maybe another storage for such persistent data like mac address could be handy to not to need variables at that stage. I think ESP32 even have flash partition for that - mac address, last AP+password, assigned DNS,...?
Anyway I can clean it up and make pull request or publish patch/branch to see it. It is quite small but as explained it currently makes no difference in reality as the rest of stuff is static - no dynamic MTU implemented yet.
As for multiple connections it can either be added to current code or the NRF build could include (currently excluded) standard GATT module which handles that (and MTU too) see https://github.com/espruino/Espruino/tree/master/targetlibs/nrf5x_12/components/ble/nrf_ble_gatt . Currently the BT is mostly handled via custom code which makes it smaller and more flexible so adding those additional nordic layers (= somehow hooking into this https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/ble/nrf_ble_gatt/nrf_ble_gatt.c#L255 ) may not be be a good idea(?).
-
I do have several attempts of resizing JS variables after reboot to allow softdevice requirements to grow and shrink so both larger MTU and this would be possible only when one needs it, the setting could stick across reboots like current time does now. Latest attempt was via moving JsVars array to the beginning of data segment so its real beginning and size can be computed dynamically after initializing softdevice and using only the rest that remains free. That was the least invasive way with minimum changes.
Previous attempt was a bit more invasive and flexible - moving static data after stack so stack could grow down, softdevice grow up and js variables array stay between them. trouble with this one was determining size of static data so that data segment is placed right below end of ram and cpu stack below it. This is not possible to do in gcc linker file so two linking stages and dynamic generation of linker file would be needed.
However for multiple connections other changes are needed since single connection is hardcoded in couple of places (e.g. there are two variables named
m_peripheral_conn_handle
andm_central_conn_handle
, that would need to be changed to array but there is more to it) -
whole 64KB of RAM is allocated to nordic softdevice for bluetooth then static variables including big static array of js variables (as per value in board file) and then cpu stack. Can you print addresses that malloc gives you? maybe it grows from the bottom of cpu stack so few bytes will not corrupt it
-
you cannot use malloc, there is no dynamic memory in nrf52 build. just allocate static buffers
see also https://github.com/espruino/Espruino/blob/5503e6bc06562fdffa4e0c13f5bf11228656d2ec/README_BuildProcess.md#odditieshowever there is jsvMalloc https://github.com/espruino/Espruino/blob/ffe45409c90f22b42a9369489cbbc1f85d9b02ce/src/jsvar.c#L4210
-
micropython does not support 3.0 version of softdevice that matches SDK12 that espruino uses. nRF52832 DK is not needed, any SWD debugger device would work including raspberry pi or pico or $2 blue pill board or stlink usb dongle from aliexpress. And BTW there is already micropython based firmware for nrf52832 watches called waspos https://github.com/daniel-thompson/wasp-os that might be good starting point.
-
-
-
actually the st7789 has read functionality, at least with SPI it worked for me some time ago on P8 watch, when checking datasheet (e.g. https://www.crystalfontz.com/controllers/Sitronix/ST7789V/ ) there are timing diagrams of both write and read operations also for the 8bit mode - page 52. Can be tricky and may not be worth it for getPixel due to speed (or maybe yes) but for making screenshot it could be used. Or is there some unidirectional level shifter/buffer between nrf52 gpio and lcd so that those 8 data pins cannot be switched from output to input temporarily?
EDIT: oh maybe the RDX pin is not available. The diagram shows while writing you toggle WRX pin (which may be the the pin_sck in BANGLEJS.py)but there is also separate RDX pin to allow reading and that one may not be connected :-(
-
-
I was trying to get a DK08 but they keep canceling as I guess stock is gone.
If anyone wants DK08 I have some unused spare ones and can part with one or two for cheap price. However if you go for Q3 that is of course better choice for many reasons, it has similar always on 176x176 display so there is no point having both (unless you want another cheap simpler watch with always on display).
GPS in B5 is exactly the same model as in Q3 and it feels to have even better sensitivity as it has printed gps antenna into the plastic case outside https://i.ibb.co/Fqf8mXZ/IMG-20201103-174322.jpg
-
Do you have sample code to test as you mentioned here? @fanoush
just check the method I already linked https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L2135
so remove the#if defined(PUCKJS) ...
or add your board name there. Also you can add jsiConsolePrintf to theif (addr<0x1f000)
part so you know it was called with wrong address. -
Did not think about autodetecting it. was thinking about some systemwide popup that any app/watchface could load where you could select current activity and it would then disable/enable various sensors including gps and start/stop logging. The rest would work on background so you could switch between apps freely. Not sure how doable it is or how it fits current app/widget model.
Also any app/watchface could detect it and possibly show activity status and its relevant data.
-
I think the protection is only enabled for official board names
https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L2135If it is reproducible then maybe logging in jshFlashErasePage for zero address could be interesting to see if it gets triggered. Or the procection there could be enabled to see if it goes away.
Anyway uploading similar code for two different devices to third device without reset() in-between is definitely asking for trouble and is great stress test. Anything could happen during upload
- watchdog trigger
- out of memory
- stack overflow
- mix of old and new code running from watches and intervals
However erasing MBR is still interesting result of such abuse, the js code uploaded does not write/erase internal flash anywhere. If the code was really uploaded to ram only and not storage then even storage bug in not likely.
- watchdog trigger
-
I think with segger tools this is pretty straightforward - google for Segger RTT. With OpenOCD google for SWO tracing - however this need GPIO pin 18 = TRACEDATA[0] to be free. RTT does not need any extra pins since this is just preallocated buffer in SRAM read over SWD.
Or maybe opeocd already has Segger RTT support merged https://www.reddit.com/r/embedded/comments/80dg3a/how_exactly_does_the_segger_rtt_work/ that works with any SWD dongle?
Or as a poor man's RTT you can allocate fixed buffer, write to it and dump it periodically from openocd via memory dump commands, it s not needed to stop CPU to read memory.
Of course you can also setup plain uart with just TX pin and log to that.