The qeustion:

I would like to know what is different about the way JTAG treats the "step over" and "step into" commands.


I am trying to set a GPNVM bit on a SAM3N (ARM Cortex M3) chip by using the In-application programming (IAP) function in the ROM.

The code calls efc_perform_command(EFC, EFC_FCMD_CGPB, 1); which is a function in the Atmel Software Framework.

In essence their code looks like this (after removing all the macro magic):

uint32_t efc_perform_command(Efc *p_efc, uint32_t ul_command, uint32_t ul_argument)
    static uint32_t(*iap_perform_command) (uint32_t, uint32_t);

    iap_perform_command = (uint32_t(*)(uint32_t, uint32_t)) *((uint32_t *) CHIP_FLASH_IAP_ADDRESS);

    iap_perform_command(0, EEFC_FCR_FKEY(FWP_KEY) | EEFC_FCR_FARG(ul_argument) | EEFC_FCR_FCMD(ul_command));

    return (p_efc->EEFC_FSR & EEFC_ERROR_FLAGS);

If you want to have a look at their full code you can look up their reference here and the full source here.

It follows the process recommended in the datasheet (section 20.5.3 In Application Programming (IAP) Feature) correctly from what I can see.

When I am debugging the code over JTAG I step through this function. If I step through it using F10 (Step Over), or if I try to just run the code, it breaks and ends up executing from memory location 0x00000000.

However, if I'm debugging the code and step through using F11 (Step Into), the code works the way I would expect it to.

This suggests to me that there is something strange going on with my link register... Though I would like this problem solved this question regards the Atmel Studio behaviour. I would like to know what is different about the way JTAG treats the "step over" and "step into" commands.

Edit 1:

The problem was resolved and seems to have been caused by the FreeRTOS tick interrupt. Since I was modifying flash the requirement that I must not execute from it holds. It seems that I was either modifying the Stack Register in some way or executing an interrupt routine (in flash) causing me to get into an invalid state. Though this explains a little about what might be happening there are still two options:

  1. The debugger disables the SysTick interrupt (or interrupts in general) when using F11 (Step Into), but lets them to run with F10 (Step Over).
  2. The debugger tries to enter the code, realizes it cannot and then manipulates the link register, in some way, to return to the next line.

I suspect that 2 is unlikely and that 1 is the answer here but I would like someone who knows this as a fact to confirm it for me.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.