What is the right way to flash s110 7.1.0?

RE: What is the right way to flash s110 7.1.0?

Nguyen Hoan Hoang — Thu, 01 Jan 2015 21:35:47 GMT

Follow this blog, it will get you working with OS X. http://embeddedsoftdev.blogspot.ca/p/ehal-nrf51.html

RE: What is the right way to flash s110 7.1.0?

jeremysf — Thu, 01 Jan 2015 19:32:50 GMT

Yes, you are totally right, I wasn't paying close enough attention to the size and it wasn't in fact doing what I thought. Thanks for the tip!

RE: What is the right way to flash s110 7.1.0?

jeremysf — Thu, 01 Jan 2015 19:30:25 GMT

Well, it turned out that everything was working after all but now I have a much better understanding of JLinkExe, softdevice versioning, etc :) By chance I had LightBlue running in the background and noticed when switching windows that my peripheral was showing up after flashing with JLinkExe.

So the issue I'm having is really that I don't have GDB working correctly. I mean, I can load symbols, set breakpoints, see the callstack and step through code, but something is wrong with GDB. I'll post a separate question / comment when I figure out what I'm doing wrong with GDB for future readers of this thread.

Thanks to all who helped me on this thread during the holidays and Happy New Year!

RE: What is the right way to flash s110 7.1.0?

RK — Thu, 01 Jan 2015 03:00:39 GMT

I don't think verifybin is doing what you think. It's loading 237504 bytes instead of the actual size of the softdevice, which is much smaller. If you actually look at the softdevice hex file it does start with 0x3A (because that's the file format, lines start with a colon) however the first actual byte placed at 0x00000000 is 0xC0.

So my assumption here is that loadbin knows how to read hex files, you can see it splits into two ranges, but verifybin doesn't and assumes you are giving it a .bin file to compare against.

.. and looking at the help output of JLinkExe that appears to be the case, verifybin only verifies bin files. In fact loadbin is supposed only to take .bin files and you're supposed to use loadfile for hex files, however it seems that JLinkExe is lenient on that point because I'm pretty sure from the output that it's recognised it as a hex file and loaded it properly.

So .. your softdevice is most-likely properly loaded onto the chip. If you really want to verify it, convert the hex file to a bin file and verify against that, not the hex one.

RE: What is the right way to flash s110 7.1.0?

Nguyen Hoan Hoang — Thu, 01 Jan 2015 02:44:23 GMT

Ok, try to use nRFGo under windows and erase all. The reserved section of softdevice may have been protected. nRFGo will do a full ease, then you can reflash.

RE: What is the right way to flash s110 7.1.0?

jeremysf — Thu, 01 Jan 2015 00:05:30 GMT

Thanks! Same exact result unfortunately :(

RE: What is the right way to flash s110 7.1.0?

jeremysf — Thu, 01 Jan 2015 00:05:00 GMT

Oh, I tried the RC calibrated clock first, but figured the synthesized clock would be more basic, either way same result :(

RE: What is the right way to flash s110 7.1.0?

Nguyen Hoan Hoang — Wed, 31 Dec 2014 22:20:16 GMT

Try RKNRFGO on OS X. Google it, you'll find the site to download.

RE: What is the right way to flash s110 7.1.0?

Marc Nicholas — Wed, 31 Dec 2014 22:10:21 GMT

Not necessarily the cause of your issue, but...

Why are you using the synthesized clock? It requires running the 16MHz clock constantly, which is generally not a preferred design.

Use the RC calibrated mnemonics instead. Use the 2000 or 4000ms recalibration and there're temperature compensated versions in SDK6+ which reduce power consumption further.

-m