Not being able to flash any binary file to nrf51822 using STLink-v2

[mhdismail]

It's not an issue specific to RIOT OS, it's more an issue with openOCD and STLink-v2.

I was interested in trying RIOT OS, before trying to flash it on my nrf51822 module I was trying an example from Nordic, I concatenated the bin file with the s110 file and it worked fine. Now, when I went ahead to flash the bin file, here's what I got (I followed the wiki http://github.com/RIOT-OS/RIOT/wiki/Board:-yunjia-nrf51822)

> flash probe 0
nRF51822-QFAA(build code: Gx0) 256kB Flash
flash 'nrf51' found at 0x00000000

> flash banks
#0 : nrf51.flash (nrf51) at 0x00000000, size 0x00040000, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1

for some reason, I have no idea why size 0x00000000.. any clue?

If I do

> nrf51 mass_erase
> flash banks
#0 : nrf51.flash (nrf51) at 0x00000000, size 0x00040000, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000100, buswidth 1, chipwidth 1

Now when I try to flash the firmware, I get the following:

> flash write_image erase ~/NRF51822/Board/pca10001/s110/ble_app_proximity/gcc/_build/test.bin 0
auto erase enabled
Padding image section 0 with 12596 bytes
using fast async flash loader. This is currently supported
only with ST-Link and CMSIS-DAP. If you have issues, add
"set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
jtag status contains invalid mode value - communication failure
error waiting for target flash write algorithm
Failed to enable read-only operation
Failed to write to nrf51 flash
error writing to flash at address 0x00000000 at offset 0x00000000

Previous state query failed, trying to reconnect

It's driving me crazy, I have no clue why that's happening. I couldn't get it to work.

Note: I have an STLink-v2 dongle, no STM32 board involved. I also updated the stlink-v2 firmware using stlink utility.

One last thing, the test.bin file I'm using is basically the output of the following (using S110 v6 and example from sdk v6): srec_cat ~/Downloads/s110_nrf51822_6.2.1/s110_nrf51822_6.2.1_softdevice.hex -intel ble_app_proximity_s110_xxaa.hex -intel -o ./test.bin --line-length=44

[PeterKietzmann]

@moenad sorry I currently don't have time for a detailed test. I've still never used the nrf51822 even if I bought some. Maybe @mehlis or @haukepetersen have an idea? @jhollister did you already use the device? Any ideas? I don't think that I have time until after next week. Sorry..

[haukepetersen]

Not sure what the problem is. When I call flash banks on one of my working nrf51822 devices, i get

> flash banks
#0 : nrf51.flash (nrf51) at 0x00000000, size 0x00000000, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1

so a wrong? size output seems to be normal... After calling the mass_erase, I get

> nrf51 mass_erase
nRF51822-QFAA(build code: Gx0) 256kB Flash
Target not halted

> flash banks
#0 : nrf51.flash (nrf51) at 0x00000000, size 0x00040000, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1

so same as your output.

Just for info, I am using

Open On-Chip Debugger 0.9.0-dev-00415-g2d4ae3f-dirty (2015-04-20-15:09)

Now to your problem: Are you trying to flash RIOT in parallel to the S110 soft device? Or are you flashing RIOT 'stand-alone' to flash address 0x00000000? Because only the second case will work...

[mhdismail]

I'm using this version Open On-Chip Debugger 0.9.0-dev-g2d4ae3f (2015-04-19-20:54)

> nrf51 mass_erase
nRF51822-QFAA(build code: Gx0) 256kB Flash
Target not halted

You should halt first with the command halt but it's fine, it shouldn't be an issue.

About my main post, I wasn't flash a RIOT example back then, I was trying it on a bin file provided by nordic in the NRF51822 SDK(v6). Anyway I tried flashing the Hello World example from RIOT and here's what I got:

### Flashing Target ###
Open On-Chip Debugger 0.9.0-rc1-dev-00001-gabd7ad0 (2015-05-07-13:46)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.185799
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf51.cpu          hla_target little nrf51.cpu          running
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : nRF51822-QFAA(build code: Gx0) 256kB 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
Error: jtag status contains invalid mode value - communication failure
Error: error waiting for target flash write algorithm
Error: Failed to enable read-only operation
Error: Failed to write to nrf51 flash
Error: error writing to flash at address 0x00000000 at offset 0x00000000
embedded:startup.tcl:454: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 510
at file "embedded:startup.tcl", line 454
Done flashing

Now, I'm not exactly sure why but I think the problem could be from the STLink-v2 dongle I'm using? it's a Chinese one, I bought from aliexpress (this one http://www.aliexpress.com/item/FREE-SHIPPING-ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/1766455290.html)

About the stlink-v2 I have, I managed to upgrade the firmware using st-util and I found out the following:

~ » st-util
2015-05-07T14:23:42 INFO src/stlink-common.c: Loading device parameters....
2015-05-07T14:23:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000

No clue why the chip id is unknown?

In both cases, I ordered a NRF51-DK and a STM32 Discovery board, I'll try it out once I receive them next week but if anyone has any idea why that's happening it would be great.

[haukepetersen]

Hm, I use actually the same type of ST-LINK adapter (with another shiny color :-) ). So far I have 5 of them in use and all of them worked...

Calling 'st-util', I get similar output as you do:

>> st-util 
2015-05-08T16:17:10 INFO src/stlink-common.c: Loading device parameters....
2015-05-08T16:17:10 WARN src/stlink-common.c: unknown chip id! 0

Besides that, I can't really tell what the problem is here... My next tip would be to try a different ST-Link adapter (one reason to always buy more than one of the cheap China stuff), to check if the adapter might be broken.

[mhdismail]

Oh I see... strange. Could it be from the nrf51822 module I have? I got these http://wireless-tag.com/products/bluetooth-module/nrf51822-02.aspx

Anyway, I ordered the original NRF51-DK and an STM32F0 Discovery board, I'll try it when I get them.

[haukepetersen]

let us know how it is going with that new hardware!

[mhdismail]

The problem turned out from the nrf51822, I tried it with a different module and it worked perfectly fine. Same when I flashed the firmware with Segger J-Link from the nRF51-DK board.

[PeterKietzmann]

Well, can we close this issue then?

[haukepetersen]

Yes, lets close this. We can re-open it, if it turns out there is more to this problem.