Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf51 DK using Keil: Error: Flash Download failed - "Cortex-M0"

It is amazing how common this error is - there must be 100 posts. Yet none solve the problem and none explain it. It suggests that there is some serious work needed to improve the error message. This error message is almost as bad as saying Error: Flash Download failed.

I have tried two SDKs with my new nrf51 DK for nrf51822: SDK 10.0.0 and SDK 8.1.0 Both give the same result

I get as far as being able to build the project (BTLE peripheral health thermometer), flash the SoftDevice, and then when I try to flash the actual hts HEX file I get

Erase Failed

Error: Flash Download failed - "Cortex-M0"

Now there are many perturbations one starts to try to solve this ubiquitous bug.

  • Turn off erasing in the flash config. Well, big deal. Now I get just the Error: Flash Download failed - "Cortex-M0" message.
  • Found one needed to migrate to new project formats with 8.1.0 - cost 6 hrs but in the end, same result.
  • Try changing the address bounds (which are the same for the SoftDevice flash and the hts flash). No difference (seems to be ignored)
  • Use nrfConnect to erase the entire chip and install the SoftDevice - no change
  • I tried to use nrfConnect to install the hts HEX on top of SoftDevice but could never figure out how to set it up in the file memory window
  • I've seen comments about incompatible SoftDevice and SDKs so I have tried a couple of SDK versions - none worked so far (at least when using s110 - I think I got one to work using s120 in SDK 10.0.0 but I need s110)

This stuff should work out of the box. I had no such issues with nrf52. What is going on?

Parents
  • brianreinhold said:
    I have been erasing the board using that.

     Well, this ensures that the debugger and Nordic chip are able to communicate. So there is no SWD connection issues here. So the only thing i can think of the is application trying to write to the reserved memory. And if you are trying the examples without any changes, then I cannot think of anything else than wrong memory address.

    Can you please attach your application hex (zipped) file here, so that i can do a smoke test on my desk to confirm my theory.

Reply
  • brianreinhold said:
    I have been erasing the board using that.

     Well, this ensures that the debugger and Nordic chip are able to communicate. So there is no SWD connection issues here. So the only thing i can think of the is application trying to write to the reserved memory. And if you are trying the examples without any changes, then I cannot think of anything else than wrong memory address.

    Can you please attach your application hex (zipped) file here, so that i can do a smoke test on my desk to confirm my theory.

Children
Related