[ABANDONED] Calling a function completely hoses the debugger

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

  • [ABANDONED] Calling a function completely hoses the debugger

    In our project there is a UART transmission function that didn't appear to produce any output, so I edited the code to call it from an infinite loop so I could get it to just spam characters. In release mode, the code doesn't work but the device is still responsive, however, when I try to debug the code to see what is happening I am unable to do so. The two screenshots show the result before and after trying to enter the HAL_UART_Transmit() function. Everything appears normal here at the breakpoint; however, after I click in the assembly view and attempt to step into the function I get what you see in the after picture. The memory views on the right are giving bogus values and I have no idea what the debugger thinks is happening as I can no longer move through the code. I have no clue what I should be looking at here to resolve the issue. The project goes over the 1Mb attachment limit so I can't include it, but it is compiled under SES Release 6.32a Build 2022062102.50602. The board hardware is very simple, a JLINK is attached to Reset, GND, and SDIO/CLK. BOOT0 is wired to ground and an o'scope probe is on PA2 (UART channel 2 TX).
    Images
    • before.jpg

      590.07 kB, 1,869×1,026, viewed 386 times
    • after.jpg

      609.37 kB, 1,922×1,024, viewed 389 times
  • Hi! I agree this seems like the debugger is perhaps being disconnected. The debugger pins for the L062 are PA13/14 while UART2 is PA2/3 and UART1 is PA9/10. None of my code touches the debugger pins but I am writing on top of the ST MXCube framework. If I comment out the Cube code to initialize the UARTs this issue still happens. Our dev board is a custom product that is as bare-bones as you can get, nothing is attached to any of the GPIO pins except a USB connector and we're also using the Cube code to run the board as a USB CDC device.
  • Now this was a pure assumption on my side.

    My next step would be to step into the "offending" code on instruction level, and watch relevant port and RCC registers.
    The latter one's are where the power to the individual peripherals are enabled.
    In my case, I had accidentally written a GPIO config to port A instead B, overwriting the SWD pin config.

    Eqqman wrote:

    The debugger pins for the L062 are PA13/14 while UART2 is PA2/3 and UART1 is PA9/10. None of my code touches the debugger pins but I am writing on top of the ST MXCube framework. If I comment out the Cube code to initialize the UARTs this issue still happens.
    I have quite a distaste for Cube/HAL, to be frank.
    But if I remember correctly, most of the peripheral init routines start with a DeInit call.
    I would check they don't do anything out of the ordinary.

    Another failure option is the power supply.
    I remember having had such a debug fail on a board with a LCD display attached.
    As soon as I initialised the display the power supply folded, and the debug connection was lost.
    It worked fine with an external supply.

    Anyway, I would continue debugging on instruction level, and check if the point of failure is consistent.
    And if so, which addresses it involves.

    Perhaps you have noticed the recent posts about mistakes in the F3xx support packages.
    For me they caused a hardfault on the first stack access, because of non-existing memory.
    Other support packages (seems you have an L0xx device) could be erranous, too.
  • Hello,

    Thank you for your inquiry.
    Release mode usually includes some kind of code optimization. Please note that with code optimization active debugging becomes oftentimes impossible and the code referencing of our debugger is a complete guessing game. So your Breakpoint that you set on some function could be in reality somewhere completely else in your optimized application.

    So first for debugging we recommend to use the debug build with code optimization disabled.
    Does your application work now as expected?
    If not, how does it behave now? Do you have any low power/sleep modes active that might block the debug interface temporarily e.g. WFE/WFI instructions?
    Oftentimes ST HAL has sleep active on default. We recommend to disable/avoid them for debugging.

    Once you have a working debug build try building the release build and flash it to your target. Does your application work now standalone as expected? If yes everything is fine.

    Also we always recommend to use the latest Embedded Studio version where possible to avoid running into bugs that might already been fixed by newer versions of our toolchain and IDE.

    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.
  • My next step would be to step into the "offending" code on instruction level, and watch relevant port and RCC registers.
    Everything craps out at the function prologue assembly for HAL_UART_Transmit() : ldr r0, =0x200007D8 <huart2>. I know bad things happen when we de-reference illegal areas of memory, but this command is just loading the address into a register. At this stage all the initialization for this function have been commented out.

    I've been using the "Debug - Internal" build with no ST library issues until I added the UART (this includes working with ADC, USB, and I2C) and optimizations set to "none". I can try doing the IDE update.

    EDIT : Did the IDE update; getting same results.

    The post was edited 1 time, last by Eqqman ().

  • As Nino posted, sleep modes and wake-up are a known source of trouble for debugging.
    Though this seems not to apply in your case.

    Eqqman wrote:

    Everything craps out at the function prologue assembly for HAL_UART_Transmit() : ldr r0, =0x200007D8 <huart2>.
    I am not too well versed in assembler code, but this code is supposed to load a 32-bit word into a core register.
    I can't really imagine how it could fail. Or does it happen in following instructions ?

    Leaving aside the quality of the HAL code/library in general, two things come to my mind.
    First, I hope the UART peripheral is properly initialized. Some MCUs hardfault when trying to access peripherals which have the clock not enabled (RCC). Which includes the GPIO pins they are routed to (GPIOx).
    Second, some incorrectly configured DMA might cause your problems. Which is again pure assumption.
    You could try to remove/disable other peripherals, and run the code with the UART enabled.

    By the way, when I wrote about "destroying" the debug connection by reconfiguring the debug pins, this looks different.
    As soon as I stepped over the erraneous pin init, the debugger displayed a message box "connection lost", and that was it.
    The score register values "0xdeadbeef" and "0xaaaaaaaa" for variable hown in your case suggest that something is messing with the debug peripheral.
    The first one ("0xdeadbeef") looks suspiciously like a stack/memory initialisation value to check for runtime overflows.

    I never devoted much time to study debugger internals or Cortex ETM/ITM peripherals ...