[ABANDONED] High current draw after flashing memory

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] High current draw after flashing memory

    I've noticed that after flashing an MCU, when the MCU enters stop mode (deep sleep), the current usage is like 160 µA, where I would expect only a few micro amps. Toggling the MCU reset line has no impact. Only when I remove and restore power, the MCU when in stop mode only draws like 4 µA.

    Some details:
    • MCU STM32L151CC (Multitech xDot)
    • SEGGER J-Link Commander V6.34c (Compiled Aug 23 2018 10:59:18), on a Mac


    I flash command line using
    JLinkExe -If SWD -Device "STM32L151CC" -Speed 8000 -AutoConnect 1 -ExitOnError 1 -CommandFile command.jlink
    with as command file:

    r
    loadbin BUILD/XDOT_L151CC/GCC_ARM/lmp.bin, 0x08000000
    r
    q

    A ST-Link flasher I've tried does not show this behavior.

    Apparently some SWD related stuff gets activated on the MCU. How do I reset this without power cycle? This is important for our project as it is a battery powered device.

    Thanks,

    Mark
  • Hello Mark,

    Thank you for your inquiry.
    Is the reset line connected to the MCU?
    If not this would explain why you see no impact when toggling it.
    How are you toggling the reset line? With a button or with J-Link?
    What is the serial number of the J-Link you are using?

    mark.ruys wrote:

    Apparently some SWD related stuff gets activated on the MCU. How do I reset this without power cycle? This is important for our project as it is a battery powered device.
    J-Link will try to keep the debug port of the target device active even when low power or sleep modes get activated to give the user the opportunity to debug the MCU during that modes which otherwise would not be possible.
    To work around this simply change the reset type to Type 2: ResetPin. More information can be found in the J-Link user guide UM08001.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    Alternatively our support system can be used as well: segger.com/ticket/
  • Hi Nino,

    > Is the reset line connected to the MCU?

    Yes it is.

    > How are you toggling the reset line? With a button or with J-Link?

    Using a J-Link commander script.

    > What is the serial number of the J-Link you are using?

    269402480

    > To work around this simply change the reset type to Type 2: ResetPin

    Yes, I've tried every SetResetType in the documentation, from 1 to 8. Not all worked of course, but none had impact on the higher power consuption after the J-Link closes the connection. Even if I force a reset by manually ground the nRESET pin of the MCU, it keeps in this high power usage. So whatever I do, the debug port seems to remain open.

    In all my experiments the J-Link gave me these warnings:


    Source Code

    1. Active read protected STM32 device detected.
    2. This could cause problems during flash download.
    3. Note: Unsecuring will trigger a mass erase of the internal flash.
    4. Device will be unsecured now.
    5. Found SW-DP with ID 0x2BA01477
    6. Found SW-DP with ID 0x2BA01477
    7. Found SW-DP with ID 0x2BA01477
    8. Found SW-DP with ID 0x2BA01477
    9. Scanning AP map to find all available APs
    10. AP[1]: Stopped AP scan as end of AP map has been reached
    11. AP[0]: AHB-AP (IDR: 0x24770011)
    12. Iterating through AP map to find AHB-AP to use
    13. AP[0]: Core found
    14. AP[0]: AHB-AP ROM base: 0xE00FF000
    15. CPUID register: 0x412FC230. Implementer code: 0x41 (ARM)
    16. Found Cortex-M3 r2p0, Little endian.
    17. FPUnit: 6 code (BP) slots and 2 literal slots
    18. CoreSight components:
    19. ROMTbl[0] @ E00FF000
    20. ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 002BB000 SCS
    21. ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 002BB002 DWT
    22. ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
    23. ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 002BB001 ITM
    24. ROMTbl[0][4]: E0040000, CID: B105900D, PID: 002BB923 TPIU-Lite
    25. ROMTbl[0][5]: E0041000, CID: B105900D, PID: 002BB924 ETM-M3
    26. Cortex-M3 identified.
    27. Reset delay: 1 ms
    28. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    29. Reset: Halt core after reset via DEMCR.VC_CORERESET.
    30. Reset: Reset device via reset pin
    31. **************************
    32. WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
    33. **************************
    34. Downloading file [BUILD/XDOT_L151CC/GCC_ARM/lmp.bin]...
    35. Comparing flash [100%] Done.
    36. Erasing flash [100%] Done.
    37. Programming flash [100%] Done.
    38. Verifying flash [100%] Done.
    39. J-Link: Flash download: Bank 0 @ 0x08000000: 2 ranges affected (227328 bytes)
    40. J-Link: Flash download: Total time needed: 7.112s (Prepare: 0.035s, Compare: 0.304s, Erase: 0.008s, Program: 6.635s, Verify: 0.126s, Restore: 0.003s)
    41. O.K.
    42. Reset delay: 1 ms
    43. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    44. Reset: Halt core after reset via DEMCR.VC_CORERESET.
    45. Reset: Reset device via reset pin
    Display All
    The remarkable thing is that when J-Link closed the connection, I did get a 4 mA power consumption instead of 160 mA.