Hi,
I have made a few custom boards based on the nrf51822 but on my latest design, I'm having a new problem that I haven't seen before. I have read the posts in the forums that seem related to the issue I'm having but I've had no luck with the kinds of solutions others have had.
I have VCC, GND, SWDIO and SWDCLK connected to the JLink from the custom board. On OSX, when I run JLinkExe, all looks good initially:
$ JLinkExe -if SWD -device nRF51822 -speed 1000
SEGGER J-Link Commander V5.02f ('?' for help)
Compiled Oct 2 2015 20:55:08
Info: Device "NRF51822_XXAA" selected.
DLL version V5.02f, compiled Oct 2 2015 20:55:03
Firmware: J-Link V9 compiled Sep 18 2015 19:53:12
Hardware: V9.30
S/N: 269302235
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Emulator has Trace capability
VTarget = 3.298V
Info: Found SWD-DP with ID 0x0BB11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 4 code (BP) slots and 0 literal slots
Info: CoreSight components:
Info: ROMTbl 0 @ F0000000
Info: ROMTbl 0 [0]: F00FF000, CID: B105100D, PID: 000BB471 ROM Table
Info: ROMTbl 1 @ E00FF000
Info: ROMTbl 1 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
Info: ROMTbl 1 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
Info: ROMTbl 1 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Info: ROMTbl 0 [1]: 00002000, CID: B105900D, PID: 000BB9A3 ???
Cortex-M0 identified.
Target interface speed: 1000 kHz
J-Link>
So next, I try to erase the chip. Still all looks pretty good:
J-Link>w4 4001E504, 2
Writing 00000002 -> 4001E504
J-Link>w4 4001e50C, 1
Writing 00000001 -> 4001E50C
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
J-Link>
I am able to read the device ID of the 51822, which is 0x72, what I expect for the variant of the chip I'm working with. So still, all looking good.
J-Link>mem32 0x1000005c,12
1000005C = FFFF0072 0E89FB6C E86641A9 FFFFFFFF
1000006C = FFFFFFFF 33524748 14113837 FFFFFF08
1000007C = FFFFFFFF 59F9FD4A AA699DFB 6E7139E5
1000008C = 779D6822 144890AF 7C386378 B85A33A6
1000009C = C5603544 FFFFFFFF
Just for fun, I can take a look at some flash memory to make sure it is erased. It returns lots of 0xFF which also looks good.
J-Link>mem32 0,12
00000000 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000010 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000020 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000030 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000040 = FFFFFFFF FFFFFFFF
Finally, try to loadfile the softdevice and/or my application which is where the problems start:
J-Link>loadfile s110_nrf51_8.0.0_softdevice.hex
Downloading file [s110_nrf51_8.0.0_softdevice.hex]...Info: J-Link: Flash download: Restarting flash programming due to program error (possibly skipped erasure of half-way erased sector).
Info: J-Link: Flash download: Skip optimizations disabled for second try.
Error while programming flash: Programming failed.
J-Link>
No matter what I do, to halt, reset, reboot, power cycle the chip and the JLink adaptor, I still get the "Error while programming flash: Programming failed." error. I've also tried stepping the "-speed" command down to 100khz with no effect. I briefly thought maybe I wasn't picking the right variant of 51822, but checking the device ID (0x72 for my QFAAH0/256kb/16kb convinced me that I am.
*** UPDATED ***
Here is the output of of the JLinkExe "log" command:
T736A6000 042:288 SEGGER J-Link V5.02f Log File (0000ms, 0414ms total)
T736A6000 042:288 DLL Compiled: Oct 2 2015 20:55:03 (0000ms, 0414ms total)
T736A6000 042:288 Logging started @ 2015-10-12 11:13 (0000ms, 0414ms total)
T736A6000 055:837 JLINK_IsHalted() returns TRUE (0000ms, 0414ms total)
T736A6000 055:837 JLINK_DownloadFile()JLINK_BeginDownload(Flags = 0x00) (0009ms, 0423ms total)
T736A6000 055:837 JLINK_WriteMem(0x00000000, 0x07C0 Bytes, ...) - Data: C0 07 00 00 D1 06 00 00 D1 00 00 00 B1 06 00 00 ... returns 0x7C0 (0010ms, 0424ms total)
T736A6000 055:837 JLINK_WriteMem(0x00001000, 0x15918 Bytes, ...) - Data: 00 15 00 20 CD 64 01 00 25 22 00 00 33 64 01 00 ... returns 0x15918 (0010ms, 0424ms total)
T736A6000 055:837 JLINK_EndDownload() -- -------------------------------------- -- Start of determining dirty areas in flash cache -- End of determining dirty areas -- Start of preparing flash programming -- Calculating RAM usage -- RAM usage = 5804 Bytes -- Preserving CPU registers -- Preparing memory -- Determining CPU clock frequency -- CPU clock frequency: 15924 kHz -- CPU frequency = 15924 kHz -- Preparing target -- Downloading RAMCode -- Checking target RAM -- Preparing RAMCode
-- End of preparing flash programming -- CPU is running at 15924 kHz. -- Start of comparing flash -- CRC check was estimated as fastest method -- Comparing range 0x0000 - 0x07FF (2 Sectors, 2 KB), using multi-block CRC calculation -- CRC does not match for sectors 0-1 -- Comparing range 0x1000 - 0x16BFF (87 Sectors, 87 KB), using multi-block CRC calculation -- CRC does not match for sectors 0-86 -- End of comparing flash -- Start of erasing sectors -- End of erasing sectors -- Start of flash programming
-- Programming range 0x00000000 - 0x000007FF (002 Sectors, 2 KB) -- Programming range 0x00001000 - 0x00008FFF (032 Sectors, 32 KB) -- End of flash programming -- Start of restoring -- Restore RAMCode -- End of restoring -- Total time needed: 0.087s (Prepare: 0.053s, Compare: 0.019s, Erase: 0.000s, Program: 0.014s, Verify: 0.000s, Restore: 0.000s) -- Restarting due to program error (possibly skipped erasure of half-way erased sector). -- Skip optimizations disabled for second try.
-- Restarting flash programming due to program error (possibly skipped erasure of half-way erased sector). -- Skip optimizations disabled for second try. -- -------------------------------------- returns 0xFFFFFFFD (0098ms, 0512ms total)
Based on reading the flash memory after programming, it looks like flash programming the range 0x00000000 - 0x000007FF goes ok:
J-Link>mem32 0,32
00000000 = 000007C0 000006D1 000000D1 000006B1
00000010 = 00000000 00000000 00000000 00000000
00000020 = 00000000 00000000 00000000 00000751
00000030 = 00000000 00000000 000000DB 000000E5
00000040 = 000000EF 000000F9 00000103 0000010D
00000050 = 00000117 00000121 0000012B 00000135
00000060 = 0000013F 00000149 00000153 0000015D
00000070 = 00000167 00000171 0000017B 00000185
00000080 = 0000018F 00000199 000001A3 000001AD
00000090 = 000001B7 000001C1 000001CB 000001D5
000000A0 = 000001DF 000001E9 000001F3 000001FD
000000B0 = 00000207 00000211 0000021B 00000225
000000C0 = 46C0B51F F00046C0
But it fails attempting to program the range 0x00001000 - 0x00008FFF:
J-Link>mem32 1000,32
00001000 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001010 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001020 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001030 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001040 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001050 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001060 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001070 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001080 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00001090 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
000010A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
000010B0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
000010C0 = FFFFFFFF FFFFFFFF
I also forgot to mention that I think I was able to flash a softdevice and app successfully initially, but I was trying to get DFU working and attempting to flash a bootloader when things stopped working for me. Again, I am trying to erase the device first with writes to 4001E504 and 4001e50C, which as per above seems to work due to reading back 0xFF, including from places like BOOTLOADERADDR in the UICR:
J-Link>mem32 0x10001014,4
10001014 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
Anybody have any ideas?
Thanks!
Jeremy
