• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 62 subscribers
  • Views 5364 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104970
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What is the right way to flash s110 7.1.0?

jeremysf

Hi,

I'm on OSX, and I'm having problems where the first service calls I make on my own device fails but work fine on the second generation Nordic development board.

I am pretty sure I'm compiling my code against the headers matching the softdevice (i.e. the ones that came in the ZIP with the softdevice) but I have problems in the first softdevice calls.

My device only has a 16mhz clock, so I've set to NRF_CLOCK_LFCLKSRC_SYNTH_250_PPM, but In the process of trying to figure out what's going on I noticed that verifybin fails which seems like a bad sign? My hypothesis is that I'm not able to correctly flash the softdevice for some reason.

Do these commands look OK for flashing the s110 firmware to a nRF51822?

$ JLinkExe -device nrf51822 -if swd -speed 4000
SEGGER J-Link Commander V4.94i ('?' for help)
Compiled Dec  8 2014 19:04:27
Info: Device "NRF51822_XXAA" selected.
DLL version V4.94i, compiled Dec  8 2014 19:04:20
Firmware: J-Link V9 compiled Nov 28 2014 09:34:59
Hardware: V9.00
S/N: 269302235 
OEM: SEGGER-EDU 
Feature(s): FlashBP, GDB 
VTarget = 3.287V
Info: Found SWD-DP with ID 0x0BB11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 4 code (BP) slots and 0 literal slots
Cortex-M0 identified.
Target interface speed: 4000 kHz
J-Link>w4 4001e504 2
Writing 00000002 -> 4001E504
J-Link>w4 4001e50c 1
Writing 00000001 -> 4001E50C
J-Link>sleep 100
J-Link>loadbin ../../s110_nrf51822_7.1.0/s110_nrf51822_7.1.0_softdevice.hex, 0
Downloading file [../../s110_nrf51822_7.1.0/s110_nrf51822_7.1.0_softdevice.hex]...Info: J-Link: Flash download: Flash programming performed for 2 ranges (84992 bytes)
Info: J-Link: Flash download: Total time needed: 0.663s (Prepare: 0.048s, Compare: 0.016s, Erase: 0.000s, Program: 0.589s, Verify: 0.006s, Restore: 0.002s)
O.K.
J-Link>verifybin ../../s110_nrf51822_7.1.0/s110_nrf51822_7.1.0_softdevice.hex, 0
Loading binary file ../../s110_nrf51822_7.1.0/s110_nrf51822_7.1.0_softdevice.hex
Reading 237504 bytes data from target memory @ 0x00000000.
Verify failed @ address 0x00000000.
Expected 3A read C0J-Link>
  • 0

    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.

  • 0

    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!

  • 0 in reply to RK

    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!

Related