This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

freertos with wdt reset problem, nrfjprog

Hello

my setup is a nrf52840, the sdk15.3, Softdevice s140.

I'm running an application with freertos and wdt and have the openbootloader and s140 also flashed.

- if in freertos the wdt is disabled and i set the GPREGRET register and make a reset with NVIC_SystemReset, i have to make a reset from outside by nrfjprog -r over jlink and then the dfu device comes up...

- and after update the device over dfu it has to be reset by nrfjprog -r and it resetarts in application as wanted

- If the wdt is enabled and do the same, set the GPREGRET register and make a reset with NVIC_SystemReset, the device restarts in application....

How can i make a reset or restart similar to nrfjprog -r from software so that no jlink is needed ?

Thanks in advance

twittich

Parents
  • Hello Twittich,

    The WD timer is not reset through a NVIC_SystemReset (Reset behavior) so it will keep running on subsequent startup when the program enters DFU mode inside the bootloader.  The bootloader feeds the WD by default for this reason. But you may need to adjust the reload interval if you have a short timeout, see NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS in the bootloader's sdk_config.h file. 

  • Hello

    Thank you. This i tested already but it's still the same. While debugging the bootloader at the function

    static bool dfu_enter_check(void)

    it's not entering in the following

       if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
           (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
        {
            NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
            return true;
        }

    the problem is at

    nrf_power_gpregret_get()

    i'm not getting 0xb1 .  If I set this hardcoded to 0xb1 it's starting in dfu mode.....

    But in the application i'm setting it and then make a reset.

    Can I use the sd functions ?

    sd_power_gpregret_set(0,0xB1);
    sd_nvic_SystemReset();

    Or use the GPREGRET2 and change that in the application and bootloader ?

    And regarding the reset of the device after the dfu and update, any idea ?

    Thank you for any help....

    twittich

  • Yes i had set it already to 15 and 30 secs but still no difference, the timeout which should be used in future is 1.5 sec if possible.
    Do you mean when i make a wd reset (feed the dog) the register is affected or when the wd time out?

  • I meant to say that the retention register will be reset if you let the WD timer time out (i.e., not reloaded in time). I'm not sure why you still see this with a timeout of 15-30 seconds though. Can you check the RESETREAS register in the bootloader on startup and see if the 'Reset from watchdog detected' bit is set? 

  • Ok, i thought so. I'm one step further. Slight smile

    The bootloader feeds the WD by default for this reason

    The bootloader isn't feeding the WD, the device stays in the bootloader and is waiting to start the update process ( the inactivity timeout is set to 0 ) until the wd timeout . If i start the update process then it's feeded and the update proceeds as normal.

    But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

    Can the function "nrfjprog -r" be reconstructed by software?

  • Glad to hear that you had some progress.

    twittich said:
    But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

    I agree it is strange. But are you testing this on a custom board? In that case, have you tried the same on a DK? The only difference I can think of is that nrfjprog -r will put the chip in debug interface mode for a brief moment in order to obtain write access to the reset register.

      

  • Yes it's a custom board but what could be the problem with it ?

    How can i make a soft reset via CTRL-AP ?

    nrfjprog -r will put the chip in debug interface mode for a brief moment in order to obtain write access to the reset register

    Means, what can i do to get this by software ?

    It's always working: if i set the gpregret, (this i forgot to write -> ) make aftwards a "self reset" by a gpio which triggers the nreset and then over terminal the nrfjprog -r. .

Reply
  • Yes it's a custom board but what could be the problem with it ?

    How can i make a soft reset via CTRL-AP ?

    nrfjprog -r will put the chip in debug interface mode for a brief moment in order to obtain write access to the reset register

    Means, what can i do to get this by software ?

    It's always working: if i set the gpregret, (this i forgot to write -> ) make aftwards a "self reset" by a gpio which triggers the nreset and then over terminal the nrfjprog -r. .

Children
  • twittich said:
    Means, what can i do to get this by software ?

     It may be possible to do enable the debug interface and do this in SW, it is something I could look into. But I don't think it's good a solution to the problem. And it would be good to understand what's causing this. I tried to through the case again to see if I've overlooked something and realize now that you seem to get similar behavior without the WDT enabled as well? I thought it was only with when you had WDT enabled.

    ^^

    - if in freertos the wdt is disabled and i set the GPREGRET register and make a reset with NVIC_SystemReset, i have to make a reset from outside by nrfjprog -r over jlink and then the dfu device comes up...

    twittich said:
    But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

     What happens if you debug the bootloader project while you perform your grepregret->nvic_systemreset() sequence from the app? Is the bootloader program getting stuck in a loop somewhere? Do you need to do a reset for it to become discoverable on Bluetooth?

  • At the beginning the timeout time wasn't changed, it was still set to 1.5 sec which is way too less. So for now it makes no difference if enabled or disabled because it's set it to 50 sec. I know now that i have to feed the wd from beginning on in the bootloader so this i'll change later.

     It may be possible to do enable the debug interface and do this in SW, it is something I could look into.

    If you could tell me a first solution would be great, afterwards it can always be changed.

    debug the bootloader project

    This i'll check now ....

  • I debugged the application... After calling " nrf_power_gpregret_set(0xB1); " it jumps to " 00000A60  4B01 " and ends up at " 0002A968  BE00 "  " NRF_BREAKPOINT_COND; " in  " app_error_weak.c ".

    After that if i do same procedure with nrfjprog -r the dfu isn't coming up. To work like before i have to reflash the device. I have just seen that if i start debug the application the part of the bootloader before the softdevice in flash is deleted,  (checked with nrf connect) 0x00000FF8 - 0x00001000. The mbr is still there 0x00000000 - 0x00000B00

    If i debug the bootloader, i call in the application the function which includes the " nrf_power_gpregret_set(0xB1); " and " self reset " then in bootloader debug it starts at " 00000A60  4B01 " then end up at " 0002A968 BE00". Not coming to the first breakpoint which is "  ret_val = nrf_bootloader_init(dfu_observer); " ( the previous code with flash protect is commented out )  Hanging in Unknon function. After pressing " restart debug " dfu comes up.

    Bluetooth is not used. The bootloader uses dfu over usb-serial.

    In the file see after debug and before.
    flash bootloader part deleted after app debug.pdf

  • twittich said:
    I debugged the application... After calling " nrf_power_gpregret_set(0xB1); " it jumps to " 00000A60  4B01 " and ends up at " 0002A968  BE00 "  " NRF_BREAKPOINT_COND; " in  " app_error_weak.c ".

    nrf_power_gpregret_set() accesses the register directly which is not allowed when you have the Softdevice enabled, see Error handlingMemory isolation and runtime protection and Hardware peripherals. This is why your code ends up in the app error handler. You should use SD APIs you mentioned earlier to access grepregret instead:

    err_code = sd_power_gpregret_clr(0, 0xffffffff);
    VERIFY_SUCCESS(err_code);

    err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    VERIFY_SUCCESS(err_code);

    0x6A0 is the address of the Hardfault exception handler inside the MBR. 

  • Yes Slight smile i also just tried the sd function and that was the problem.

    And now i have to feed the dog from the bootloader.

Related