Problem changing reset type

  • Problem changing reset type

    I'm trying to reset my device by the reset pin, but it seems that changing the reset type has no effect:

    Source Code

    1. > JLinkExe -device LPC1752 -if SWD -speed 1000
    2. SEGGER J-Link Commander V5.02k ('?' for help)
    3. Compiled Nov 13 2015 18:34:51
    4. Info: Device "LPC1752" selected.
    5. DLL version V5.02k, compiled Nov 13 2015 18:34:47
    6. Firmware: J-Link V9 compiled Oct 9 2015 20:34:47
    7. Hardware: V9.30
    8. S/N: xxxxxxxxx
    9. OEM: SEGGER-EDU
    10. Feature(s): FlashBP, GDB
    11. Emulator has Trace capability
    12. VTarget = 3.300V
    13. Info: Found SWD-DP with ID 0x2BA01477
    14. Info: Found Cortex-M3 r2p0, Little endian.
    15. Info: FPUnit: 6 code (BP) slots and 2 literal slots
    16. Info: CoreSight components:
    17. Info: ROMTbl 0 @ E00FF000
    18. Info: ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 002BB000 SCS
    19. Info: ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 002BB002 DWT
    20. Info: ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB
    21. Info: ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 002BB001 ITM
    22. Info: ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 002BB923 TPIU-Lite
    23. Info: ROMTbl 0 [5]: FFF42000, CID: B105900D, PID: 002BB924 ETM-M3
    24. Cortex-M3 identified.
    25. Target interface speed: 1000 kHz
    26. J-Link>r
    27. Reset delay: 0 ms
    28. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    29. J-Link>exec SetResetType = 2
    30. J-Link>r
    31. Reset delay: 0 ms
    32. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    33. J-Link>exit
    Display All


    Am I doing it wrong, or is there some reason the jlink decides against using the reset pin?

  • Slightly related thread

    How is the reset strategy configured? (PIC32MZ)

    I've been having this same issue. Digging way back in the forums seems to reveal (to me at least) that Segger "knows best" and they may or may not allow you to do anything depending on your processor. Some processors seem to have an enumerated "reset strategy" you can select using a script or the API (but not in any GUI that I can find). But some like the Pic32(what I use) only let you use a fixed reset strategy, which in my case doesn't toggle the reset. In the end I had to hack a script together in a batch file to do my reset. It does cause their tools to get cranky (I have to restart J-Link in the script afterward). Note that this script doesn't use reset strategy because in my case it won't let me change it. Looks just like what's happening in your example.

    Segger seems to cite that toggling reset is bad for some platforms because it "resets debug logic" or something to that effect, but it's really just a limitation that they don't want to fix. There are definitely ways to get this to work. The only real and true way to reset everything is toggling that line. They claim a JTAG reset command to the chip is the same, citing docs to that effect, but the docs are wrong in the case of the Pic32, where I've observed bad state without toggling reset on many boards. Now how to get them to listen, I'm not sure.

    Source Code

    1. r0
    2. sleep 250
    3. r1
    4. sleep 250


    The other thing I had to do is put a software breakpoint in at the top of main. But all this is my old hack that I've used to scrape by waiting for a fix. Fast forward to today-- I'm just using my own GDB stub which toggles the reset and had to abandon J-Link. This was the final straw for me :) Once you do that, you no longer have to ask questions like this. You just patch your code.

    I hope your processor lets you do this but it looks like it's behaving the same as mine. And if that's the case, only complaining loudly might get them to fix it. But we first have to convince them that the customer is right, and so far no dice.

    Good luck!

    The post was edited 8 times, last by Tj256 ().