[SOLVED] Memory data changes abnormally during debugging

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

  • [SOLVED] Memory data changes abnormally during debugging

    Hi,

    I wrote a program using the SES + STM32 platform, which has been running well and has been applied to over a million products, but recently I found that there are occasional hardfault cases. After analyzing the stack data and the corresponding assembler code, it was found that the value of a variable was unexpectedly changed to a particularly large value. This is a static local variables within the function, I checked the code, feel code should not lead to this problem, I also analyzed the map file, find the address of the variable, in the front of the RAM, the system stack at the end of the RAM, so should not because the reason of stack overflow, also because the stack is large enough (8 KB in size), and between the variables and stack separated by about 4 KB address, if the stack overflow, so should be in before they lead to hardfault affects this variable. Then I also looked at whether the variable's adjacent address (especially its previous address) had some pointer manipulation that might cause it to be tampered with, and found no such pitfalls. The only thing I can think of right now is, in order to save code space, I'm going to use optimize for size. I know I shouldn't doubt the compiler, but there's no other explanation.

    Then I'm ready to debug it, and it turns out that sometimes when the program runs to the main function, the value of this variable is already a large value (it should be 0), but it's amazing that even then, sometimes the program can continue to run, but sometimes it goes straight to hardfault. So I set a conditional breakpoint, when writing the variables corresponding to the RAM address into the breakpoints, and then I found is in thrumb_crt0.s file Settings. The BSS into breakpoints, and then I switch to the assembly instruction window one step to run the program, and then discovered a strange phenomenon in particular, when I perform to a STRB r2, (r0) instruction, RAM data of unexpected changes have taken place. I tried it over and over and over and over again. I took screen pictures from debugging and videotaped them, and I uploaded them. I don't know how this happens, but after using compiler optimization, the result of debug is no longer trusted?

    Source Code

    1. /* Zero the bss. */
    2. ldr r0, =__bss_start__
    3. ldr r1, =__bss_end__
    4. movs r2, #0
    5. bl memory_set
    6. ldr r0, =__tbss_start__
    7. ldr r1, =__tbss_end__
    8. movs r2, #0
    9. bl memory_set
    Images
    • 屏幕快照 2018-08-13 16.32.17.png

      640.51 kB, 2,560×1,600, viewed 762 times
    • 屏幕快照 2018-08-13 16.34.01.png

      633.03 kB, 2,560×1,600, viewed 496 times
    • 屏幕快照 2018-08-13 16.34.10.png

      634.8 kB, 2,560×1,600, viewed 518 times
    • 屏幕快照 2018-08-13 16.34.14.png

      641.25 kB, 2,560×1,600, viewed 451 times
    • 屏幕快照 2018-08-13 16.34.19.png

      642.75 kB, 2,560×1,600, viewed 478 times
  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.

    You seem to be using Embedded Studio commercially so we suggest contacting our official support channels. More information can be found in my signature.
    Simply fill out the form and state your Embedded Studio license.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • This project USES KEIL, and I now use the MAC OS X system, so I will transplant it to SES to see if it can be used normally. Currently, I do not use SES as the official commercial product development. If we decide to use SES to develop official commercial products, we will buy them.
  • It's a very strange problem isn't it? Because the problem has not run into user code at all, and the phenomenon is not understood. If I cannot understand the principle of this problem and solve it, I think I may not be able to develop products with SES safely, thinking that there will be unknown hidden dangers.
  • Hello,


    hiqrf3 wrote:

    Currently, I do not use SES as the official commercial product development.
    OK, we got the impression that ES is used commercially due to your first sentence in this thread: "I wrote a program using the SES + STM32 platform, which has been running well and has been applied to over a million products, but recently I found that there are occasional hardfault cases."
    This sounded a lot like commercial use to us.

    Anyways, does right clicking the disassembly and selecting refresh fix the display issue?
    If that does not work, could you open the J-Link control panel under View and toggle the option "Allow caching of flash contents" and "Allow instruction set simulation" to off.
    Does that make a difference? A screenshot with the options can be found attached.

    Best regards,
    Nino
    Images
    • Capture.PNG

      17.14 kB, 536×509, viewed 496 times
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.