nRF51 Espruino build problem

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_nRF­51822_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