Troubleshooting the nRF51822

Troubleshooting the nRF51822

posted in: Arduino, BLE | 4

I’ve had quite a few comments where people are having problems uploading or running sketches on the nRF51822, so as I don’t have time to answer individual questions, I thought it best to try to cover the main reasons that things may not work

 

Device is not recognised by Blackmagic probe or possibly not by JLink

Originally I had a lot of issues with Blackmagic probe not recognising the ID code in the nRF51822. When this happens the Blackmagic probe reports the nRF51822 just as ARM cortex M0 rather than nRF51822

If you have this issue with my latest repo, please let me know, as the only option is to manually read the ID code and send it to me, so I can add that code to the list in the firmware and then rebuild the Blackmagic probe firmware.

The main problem is that Nordic do not keep an updated document of what ID codes they use, and most of the codes have been gathered and compilated by various users from various sources.

However I think this situation has now stabilized and Nordic have not released any new ID codes recently

This is not so much of an issue with JLink as you have to tell JLink which device you are programming,but this is not an option with the Blackmagic probe firmware.

 

nRF51822 chip is read protected / locked

This problem can occur if you are using a module which is pre-flashed with some firmware already.

In my case the  modules I bought from Wireless-tag (http://www.wireless-tag.com/index.php/product/9.html) , specifically http://www.wireless-tag.com/index.php/product/dis/25.html had this problem

I hoped the my JLink could disable the read protection, as this is a menu option in JFlash, however the option is greyed out and JFlash gives some erroneous error message when you connect, about an issue with the RAM

This problem can also be caused if you use JFlash to “Fill with zero”, as I found out by accident one day

Eventually I found a solution to this, on Nordic’s website https://devzone.nordicsemi.com/question/631/cannot-recover-with-nrfgo-could-not-read-ahb-ap-id-could-not-connect-to-target/

And the solution is to manually write commands into 3 of the nRF58122’s registers

In JLInk the commands are

w4 4001e504 2
w4 4001e50c 1
w4 4001e514 1

And GDB has an equivalent write command

After these registers are changed, it will cause the whole MCU to be erased and you should be able to connect via JFlash or Blackmagic probe without an errors and upload your new firmware

 

S130 softdevice has not been flashed into the bottom of flash (0x00000)

The bluetooth API functions provided by Nordic some in the form of a “Softdevice”

The best way I can describe a Sottdevice is a cross between a bootloader and a dynamic link library.

The code for all the BLE functions is in this closed source Softdevice, and the sketch makes calls into the Softdevice in order to access that functionalityAdditionally, the Sketch code is compiled to run at address 0x1c000 (for the V9 Soft device) – Note the latest version of the Softdevice, at the time of writing, is V2.0.1 from SDK V11, and is slightly smaller and expects the sketch (application) code to be at 0x1B000 – so make sure you download the old SDK V9 and use the S130 softdevice from that SDK.Basically the Softdevice is installed at address 0x00000 and when the MCU starts up, it runs a small amount of Softdevice initialisation code, and then the Softdevice passes control to the application sketch at 0x1B000, the Softdevice also attaches to some interrups to do its own functions, but all other iterrupts are forwarded to the application, as the softdevice inspects the applications (sketches), interrupts vector table and calculates the address to call inside the application code for each interrupt.Consequently unless you have installed the S130 softdevice into address 0x00000, the sketch will not run because it will be installed at 0x1C000 with jibberish in the flash at addresses 0x00000 to 0x1BFFF, which the MCU will run at startup.
I suppose if the flash from 0x00000 to 0x1BFFF was filled with nops this may work, but there are better ways of running without the softdevice e.g. change the linker script to position the sketch at 0x00000 and change the upload script to make sure its flashed at 0x00000Overall, just make sure the correct version of the Softdevice is flashed at 0x00000

 

Module does not have the 32Khz RealTime Clock crystal

If you installed the Softdevice and uploaded the sketch code and nothing works, e.g. including a “Blink” sketch, the reason is probably that your “no name” board does not have a 32Khz cystal oscillator

My current repo only works with modules that have the RTC.

I am working on an updated version that works without the RTC, but if you have a module that omitts this, you have 4 options

  1. Solder a 32khz crystal and the 2 capacitors to the correct pins on your module (I did this with a Wireless-tag module)
  2. Use Mbed instead of Arduino
  3. Hack the latest version of the RedBearLabs Arduino repo to work with your board (this is what I’m now working on)
  4. Wait for me to release my new version

 

Windows Blackmagic Probe driver problems

The BMP drivers work fine on Windows 7 but I have not tested them on Windows 8, or 8.1 or 10.

I have had a report that they may not work on W10 because of signing issues, which is strange as W7 requires signed drivers and they work fine.

If you have problems with driver signing on W10, just google for running unsigned drivers and there are some work-arounds, but its generally not recommended to run Windows permanently in a special mode to allow unsigned drivers, as it could be a security issue.

 

Other ways to work out whats going wrong

If you are not sure if you code is being uploaded, I’d recommend you powercycle your board and then reconnect and read back the flash from 0x1c0000 for about 1k and compare with the first 1k of the binary compiled by the Arduino IDE

If they are different, then you have not really uploaded, and with the Blackmagic probe this normally indicates that it has not recognised the MCU as a nRF51822 and is treating it as a normal ARM cortex M0 in which case I don’t think it can correctly erase the flash before programming it.

If you can’t connect via SWD, one cause can be transposed SCK and SDIO lines, so try swapping them over

JLink will not connect unless you feed 3.3V from the target board back into the “sense” input

With BMP its often best to manually run GDB and connect to the BMP and then connect to the nRF51822. See this post about connecting via GDB

https://github.com/blacksphere/blackmagic/wiki/Useful-GDB-commands

 

I’m afraid I do not have much free time to answer individual questions about installation or other problems, but feel free to post in case your questions or solutions help out others

4 Responses

  1. John Carter
    |

    Hi Roger!
    My windows does not recognize the BMP (Un) in the STM32F103C8 Generic (Blue pill), however if I install the STM32duino Bootloader it is recognized normally.
    I have already checked the USB circuit several times, and also replace the resistor in PA12 with a new 1K5 resistor, incluse not to depend on the USB connector on board, I used an adapter that I have in hand, below follows the image of the adapter that I connected In PA11 and PA12.

    http://i.ebayimg.com/images/g/zrYAAOSwImRYNwnN/s-l500.jpg

    Have you seen any problems like that?

    Thank you!!

    PS: sorry for my English.

  2. Roger Clark
    |

    BMP needs special drivers, which were in with my repo.

    If those don’t work, your best bet is to look on the official Blacksphere BMP repo on github and check what drivers they recommend.

  3. Mark Cooke
    |

    To share my experience with the nRF52832.
    I was unable to disable the read protection / flash lock with a BMP or ST-Link V2, but i was successful with a J-Link.

    When nRF52832 chip is read protected / locked, the first step is to try:
    nrfjprog –recover -f nrf52

    This performs the same task as:
    >Jlink -if swd -device nrf52
    J-Link>SWDSelect
    J-Link>SWDWriteDP 1, 0x50000000
    J-Link>SWDWriteDP 2, 0x01000000
    J-Link>SWDWriteAP 1, 0x00000001

    Wait until AP 2 is 0, and the operation is complete
    J-Link>SWDReadAP 2

    If two successive reads from AP 3 produce 0, then 1 then protection is disabled
    J-Link>SWDReadAP 3
    J-Link>SWDReadAP 3

    Tested with JLink v6.20b

  4. Roger Clark
    |

    Thanks

    Coincidently someone else I know had a similar problem as they after trying to upload via DFU.

    I think they managed to fix the problem by changing the contents of the BPROT reg

    http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fbprot.html

    But I don’t know the exact details

Leave a Reply