• State Verified Answer
  • Replies 39 replies
  • Subscribers 68 subscribers
  • Views 8579 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 235863
Options
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

twittich

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

  • 0 in reply to Vidar Berg

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

    Vidar Berg said:
    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?

  • 0 in reply to twittich

    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.

      

  • 0 in reply to Vidar Berg

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

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

    Vidar Berg said:
    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. .

  • 0 in reply to twittich
    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?

  • 0 in reply to Vidar Berg

    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.

    Vidar Berg said:
     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.

    Vidar Berg said:
    debug the bootloader project

    This i'll check now ....

Related