-
Hello,
Following up to my own posts:
I realised the JLink had an unpopulated connector, and sure enough it carries signals. So I was able to solder the Adafruit board onto the JLink connector and reflash the Adafruit firmware, and the board worked. Phew! So I'm going to assume that the pi openocd stuff isn't working reliably and put it aside for now.
I built from a clean github clone:
NRF51822DK=1 RELEASE=1 make
I'm not getting any advertisements from the device however. JLink seems to report that it is flashing ~120kbytes, which is slightly more than the size reported by 'size' for the espruino elf file. I suspect this doesn't include the soft device.
JLink flash report:
Cortex-M0 identified.
Target interface speed: 100 kHz
J-Link>loadfile espruino_1v84.60_nrf51822.hex
Downloading file [espruino_1v84.60_nrf51822.hex]...Info: J-Link: Flash download: Flash programming performed for 1 range (120832 bytes)
Info: J-Link: Flash download: Total time needed: 19.748s (Prepare: 0.562s, Compare: 0.875s, Erase: 2.307s, Program: 15.940s, Verify: 0.005s, Restore: 0.057s)
O.K.I tried manually loading the soft device - looks like it was already flashed - looks like JLink skips programming matching parts which explains the size.
loadfile s110_nrf51_8.0.0_softdevice.hex
Downloading file [s110_nrf51_8.0.0_softdevice.hex]...Info: J-Link: Flash download: Flash download into internal flash skipped. Flash contents already match...and tried manually flashing the .bin file just to be sure (.text segment starts at 0x18000 I believe)
espruino_1v84.60_nrf51822.elf: file format elf32-littlearm
SYMBOL TABLE:
00018000 l d .text 00000000 .textJ-Link>loadbin espruino_1v84.60_nrf51822.bin 0x18000
Halting CPU for downloading file.
Downloading file [espruino_1v84.60_nrf51822.bin]...Info: J-Link: Flash download: Flash programming performed for 2 ranges (113664 bytes)
Info: J-Link: Flash download: Total time needed: 18.553s (Prepare: 0.678s, Compare: 0.192s, Erase: 2.630s, Program: 14.971s, Verify: 0.021s, Restore: 0.058s)
O.K.
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
J-Link>g (I believe runs the CPU)I might have to begin debugging to see why there are no advertisements. Very strange that the same build did advertise yesterday!
-
Hello,
I did some more investigations, trying a Nordic PCA10006 board which had SWD pins that I could solder onto the Raspberry Pi. I noticed it has the 256k flash, 16k ram variant (opposed to the 128k I originally thought). So I compiled with ram set to 16k, modifying boards/NRF51822DK.py and also setting variables to 100.
The same thing happened - espruino programmed OK first time
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xffffffd8
Info : nRF51822-QFAA(build code: E0) 256kB Flash
verified 210504 bytes in 4.054331s (50.704 KiB/s)
** Verified OK **...then the next time
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf51.cpu - Not haltedFortunately I was able to connect the JLink programmer to this board, and was able to reflash it. So I will assume that the problem is down to openocd or the GPIO bit bang. Not sure why it flashed OK with the Adafruit code running but not with Espruino.
Having said that, I didn't get any device adverts appearing on my phone. Is it feasible for Espruino to run in a 16k RAM variant? I think the soft device uses about 8k which might not leave much for the JS interpreter. Developing on the board with JLink would be much easier.
Colin
-
Hello,
Some sort of progress (for a short period anyway)....
I tried using the raspberry pi GPIO version of openocd to program the nrf51822, as described in:
https://github.com/adafruit/Adafruit_nRF51822_Flasher
This successfully flashed the Adafruit files for the Flora module, so I figured I was good to restore in case of problems.
I flashed the Espruino hex file I built with gcc4.9, which flashed and verified OK.
I used the Nordic toolbox, and "Espruino NRF51822DK" appeared as a BTLE device, which looked promising.
When I tried to connect using the Nordic nRF UART 2.0 a connection was made. When I tried entering text something obviously went wrong, as the UART app reported a "This device does not support the UART service" or similar error message, and closed the connection.I now seem unable to reprogram the device using openocd.
pi@raspberrypi ~/Adafruit_nRF51822_Flasher $ sudo ./openocd-0.9.0/rpi_gpio/openocd -s openocd-0.9.0/scripts -f interface/raspberrypi-native.cfg -c "transport select swd" -c "set WORKAREASIZE 0" -f target/nrf51.cfg -c init -c "reset init" -c halt -c "nrf51 mass_erase" -c "program /tmp/espruino_1v84.60_nrf51822.hex verify" -c reset -c exit Open On-Chip Debugger 0.10.0-dev-00002-g3397eae (2015-06-24-16:08) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html BCM2835 GPIO nums: swclk = 25, swdio = 24 BCM2835 GPIO config: srst = 18 srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst swd 0 cortex_m reset_config sysresetreq adapter speed: 1000 kHz Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : SWD only mode enabled (specify tck, tms, tdi and tdo gpios to add JTAG mode) Info : clock speed 1006 kHz Info : SWD IDCODE 0x0bb11477 Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints Error: timed out while waiting for target halted TARGET: nrf51.cpu - Not halted in procedure 'reset' in procedure 'ocd_bouncer'
Worse, the device doesn't seem to be advertising any more after power cycling. Perhaps it managed to slightly flash some firmware (I tried reflashing a few times so maybe it progressed slightly).
There doesn't seem to be much on the module which would cause a problem (Schematic is at https://learn.adafruit.com/assets/25434), though I did have an FTDI 3v3 cable connected to its UART ports. I wonder if Espruino was driving a GPIO with opposite polarity to the FTDI chip which has upset things?
Failing that, I suppose the other reason might be the pi GPIO bit bang being "a bit iffy". It looks as though it successfully recognises the SWD IDCODE - Googling 0x0bb11477 suggests a Cortex-M0 which is correct, and suggests things aren't completely dead.
I actually have a JLink adapter from the older nrf51822 dev kit, but the pin pitch is so small I have no chance of soldering to it. This comes with a USB module with JLink and nrf51822 on, which would be perfect for debugging Espruino, but the chip is the older 128k flash/16k RAM version which I think might be a bit too small for Espruino.
Has anyone else tried the Raspberry Pi GPIO bit bang method? Maybe I'd have better luck with a ST-Link or something instead. Of course, I'm hoping I haven't just simply fried the Pi or the BTLE module...
Colin
-
Hello,
It did help very much. Thanks!
I tried using gcc-arm-none-eabi-4_9-2015q1 and it compiled:
arm-none-eabi-size espruino_1v84.60_nrf51822.elf
text data bss dec hex filename
119996 196 4820 125012 1e854 espruino_1v84.60_nrf51822.elfI'll need to wire up a flash programmer and I'll let you know how I get on. I have to admit that fiddling problems like this with gcc are what draws me to an easy to use development environment like Espruino!
I might not get round to programming it for a while, but I'll let you know what happens. It looks like there is more to be added for the nrf51 so when I get time (which might not be for a while) I will see if I can add anything.
Thanks,
Colin
-
Hello,
I've always thought the Nordic nRF chip looks to have lots of uses, and wondered about porting Espruino to it. I was very excited to discover that it looks as though lots has been done already.
It looks as though it should run on the Adafruit Flora sewable BTLE module (https://www.adafruit.com/products/2487) - which has the 256k flash nrf51822 chip - Wearing a Javascript interpreter just sounds super geeky :-)
I was curious to try building it and have a problem:
NRF51822DK=1 SOFTDEVICE=1 BLE_INTERFACE=1 RELEASE=1 make
...gives:
LD espruino_1v84.60_nrf51822.elf
/home/colinp/espruino/Espruino/targetlibs/nrf5x/nrf51_sdk/components/toolchain/gcc/gcc_startup_nrf51.o: In functionReset_Handler': (.text+0x40): undefined reference to
SystemInit'
/usr/local/gcc-arm-none-eabi-4_8-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m/crt0.o: In function_start': (.text+0x4e): undefined reference to
main'
collect2: error: ld returned 1 exit status
make: *** [espruino_1v84.60_nrf51822.elf] Error 1Main for this board appears to be in targets/nrf5x/main.c, which is defined in the Makefile. main.o appears, which implies it is being compiled, but not linked.
I tried various hacks to get it to compile, and encountered different problems. When I got to the stage of patching the include path in the auto-generated gen/platform_config.h I figured I was probably doing something wrong.
I thought perhaps nrf51 build had fallen out of use as nrf52 was in there. If I try to build for nrf52 using the command in README_Building.md I get a different error:
NRF52832DK=1 RELEASE=1 make
targets/nrf5x/jshardware.c:482:23: error: 'nrf_adc_config_t' undeclared (first use in this function)
I'm using commit 6dbda86c of Friday 8th Jan 2016.
I'm using gcc-arm-none-eabi-4_8-2014q1 (I can't remember where it came from) but I think this should be OK - the stm32 Espruino compiles fine.
I get the problem even when using commit 904ca0ac8c19828 which is marked "nRF51 now working". This makes me think I'm doing something dumb.
Am I missing some sort of Make flag or something?
Thanks,
Colin
Hello,
The Youtube video looks really nice.
I modified boards.py and communication_interface.c for 16k and to use the flow control pins+hardware flow control and I can now at least get it to start up on the Nordic dev kit USB dongle (which is much nicer as it means I can develop on my laptop without accidentally pulling a pile of hastily soldered together debug cables off...)
The serial shell appears to be working OK, but Bluetooth is unreliable. I can sometimes connect and it works, but other times connect with immediate disconnect. At least having a reliable programmer and serial port makes it much easier to begin to debug!
Anyway - it looks like you've made lots of changes to the uart in your last commit so I'll update to that and see what happens...
Oh - something else I discovered the other night should anyone else be reading this. The FTDI TTL 3v3 dongle only has 3v3 levels on its UART lines. The Vdd line is 5volts, NOT 3v3 as I thought. So it turns out I've verified the nrf51822 will operate at 5v supply. cough...