Debugging Issue: Single Step vs Brakepoint not Yielding Same Result.

RE: Debugging Issue: Single Step vs Brakepoint not Yielding Same Result.

Ole Morten — Tue, 26 Nov 2013 10:23:49 GMT

Sorry for overlooking that part. I edited my answer a little to expand somewhat on this, although I don't really have any great suggestions.

RE: Debugging Issue: Single Step vs Brakepoint not Yielding Same Result.

Dalbert — Mon, 25 Nov 2013 19:47:23 GMT

Hey, thanks for the response. I really appreciate it. I do intend to use the official SDK, and thanks for the tips on the issues with the flash. The only point of my code was a learning exercise -- In regards to CLENR0, I was just trying to see if changing it made any difference.

But, all this is besides the point. Why would the same code work on the PCA10005 and not the PCA10000? And what could cause a different result if I use a breakpoint vs a single step? I can use J-Commander and see that the two devices are flashed exactly the same way. If it is something that is unexplainable, that's fine, maybe I will discover the answer as I continue learning...

Thanks Again.
Dal

RE: Debugging Issue: Single Step vs Brakepoint not Yielding Same Result.

Ole Morten — Mon, 25 Nov 2013 14:14:09 GMT

It seems that you don't use the official SDK. I'd strongly recommend you to do so, since it contains a lot of defines that makes your code nicer and easier to write. Especially consider using nrf51.h and nrf51_bitfields.h. There are also examples of a lot of things, that could be useful to refer to.

I'm also having a little trouble understanding what you try to do at the start of your main function. The CLENR0 register in UICR is a flash register, and there is no need to write to it on every reset. I'd therefore recommend you to remove this snippet completely, and see if that changes anything.

Also, beware that the upper 8 kB of flash is not on by default, and must be explicitly turned on. This doesn't seem to be the problem here, but I guess it's an issue you'll easily hit later. In the SDK code, this is done with the following assembly code in the Reset_Handler:


/* Reset Handler */

    .equ    NRF_POWER_RAMON_ADDRESS,            0x40000524
    .equ    NRF_POWER_RAMON_RAMxON_ONMODE_Msk,  0xF  

    .text
    .thumb
    .thumb_func
    .align 1
    .globl    Reset_Handler
    .type    Reset_Handler, %function
Reset_Handler:
    .fnstart

/* Make sure ALL RAM banks are powered on */
    LDR     R0, =NRF_POWER_RAMON_ADDRESS
    LDR     R2, [R0]
    MOVS    R1, #NRF_POWER_RAMON_RAMxON_ONMODE_Msk
    ORRS    R2, R1
    STR     R2, [R0]

You may also have use in looking at this GitHub repository.

Edit: As for the difference between the boards, I don't have any immediate good explanations for that. The only thing I can think of that could be worth checking is the "Allow instruction set simulation" option in the J-Link settings (right-click the J-Link icon in the taskbar, go to settings tab). I've seen previously that this sometimes give unexpected behavior, although I can't remember having seen anything like what you describe.

You should of course also make sure that you start from blank flash before programming on both chips, but I assume you have already done so.