strange behavior after segger -> target -> reset

puff gravatar image

asked 2018-01-14 11:36:02 +0100

Finally, I managed to compile ble_beacon in segger. However, here's what I can not understand.

Using either Segger -> Target -> Download File or RKNRFGO I managed to upload the ready-made hex from that example to nrf chip, and I can see it on my smartphone. Then I upload the freshly built firmware (with a bit altered UUID - to see which version of firmware is flashed) - segger reports that the new fimware has been flashed successfully, but I can not see anything on the smartphone (I attached the log below). But when I do

The most interesting part is that yesterday when instead of FLASH ADDRESS 1B000 I mistakenly used 1F000, after having failed to discover the device and doing Segger - Target - JLink connect - Reset I could see the initial stock ble_beacon on the smartphone - the device was again alive!

Now, after I fixed the flash size issue, I cannot reproduce this behavior, the device doesn't work with my own build firmware.

The question is how to debug this elf file - how do I check, what's wrong?

Here's the log:

CPUID register: 0x410CC200. Implementer code: 0x41 (ARM)
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ F0000000
ROMTbl[0][0]: E00FF000, CID: B105100D, PID: 000BB471 ROM Table
ROMTbl[1] @ E00FF000
ROMTbl[1][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl[1][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl[1][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
ROMTbl[0][1]: F0002000, CID: B105900D, PID: 000BB9A3 ???
Preparing target for download
Executing script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘s130_nrf51_2.0.0_softdevice.hex’ to J-Link
Programming 1.9 KB of addresses 00000000 — 000007bf
Programming 103.9 KB of addresses 00001000 — 0001aff3
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Download successful
Downloading ‘ble_app_beacon_s130_pca10028.elf’ to J-Link
Programming 17.5 KB of addresses 0001b000 — 0001f613
Programming 0.0 KB of addresses 0001f614 — 0001f62a
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (18432 bytes)
J-Link: Flash download: Total time needed: 0.610s (Prepare: 0.083s, Compare: 0.023s, Erase: 0.170s, Program: 0.277s, Verify: 0.002s, Restore: 0.052s)
Download successful

Besides, I am not sure about my memory map, but I couldn't find the working example

<!DOCTYPE Board_Memory_Definition_File>
<root name="nRF51822_xxAA">
 <MemorySegment name="FLASH" start="0x00000000" size="0x00040000" access="ReadOnly" />
 <MemorySegment name="SRAM" start="0x20000000" size="0x00004000" access="Read/Write" /> 
edit retag flag offensive close delete report spam

1 answer

Sort by » oldest newest most voted
puff gravatar image

answered 2018-01-14 12:28:38 +0100

UPD. I had the same project, which after some tinkering flashed just fine on another machine. After comparing those two, I decided just to substitute the failed project file with the one from the working machine. It failed to compile, complaining on the line in ses_nrf51_startup.s (at the bottome of it):

#ifndef __NO_SYSTEM_INIT
ldr r0, =__SRAM_segment_end__
mov sp, r0
bl SystemInit

so I changed it to __RAM_segment.., and it compiled just fine.

But which is strange, when I decided to look once again at the error message and changed it back to __SRAM_segment.., I couln't reproduce that build error, even after cleaning the project and solution.

edit flag offensive delete publish link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

User menu

    or sign up

Recent questions

Question Tools

1 follower


Asked: 2018-01-14 11:36:02 +0100

Seen: 42 times

Last updated: jan. 14