Menu

#134 Pb in debugging session.

Version 1.x
closed
None
5
2015-05-17
2015-04-10
rvlander
No

Hello!

I can't have a debugging session working correctly with a STM32F417IE.
When I click on launch, A tab keep beeing displayed with errors such as :
No source available for "(gdb[9].proc[42000].threadGroup[i1],gdb[9].proc[42000].OSthread[1]).thread[1].frame[0]"
No source available for 0x0
No source available for 0x<more complex="" address=""> (eg. 0x80123251)

In console: I have this output :
Starting target CPU...
...Target halted (PC = 0x030CF002)
Reading all registers
Removing breakpoint @ address 0x08001304, Size = 2
WARNING: Failed to read memory @ address 0x030CF002
Read 4 bytes @ address 0x2001FF7C (Data = 0x00000002)
Reading 64 bytes @ address 0x2001FF40
Read 4 bytes @ address 0x00000002 (Data = 0x02B92002)
Read 4 bytes @ address 0x00000000 (Data = 0x20020000)

Basically, I can't have my program running and I can't see what is in memory.

Thx in advance for your answer!

Discussion

<< < 1 2 (Page 2 of 2)
  • Liviu Ionescu (ilg)

    Here is the output of your project, executed on a F407:

    SEGGER J-Link GDB Server V4.98c - Terminal output channel
    Hello ARM World!
    System clock: 168000000Hz
    Second 1
    Second 2
    Second 3
    Second 4
    Second 5
    Second 6
    Second 7
    Connection closed by the GDB server.

    If you use the -DOS_USE_TRACE_SEMIHOSTING_DEBUG, you need to Enable semihosting in the debug configuration.

     
  • rvlander

    rvlander - 2015-04-27

    Maybe the template is not compatible with STM32F417

    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B04
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B04
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B06
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B06
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B08
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B08
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B0A
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B0A
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B0C
    Reading 64 bytes @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B00
    WARNING: Failed to read memory @ address 0x289B4B0C

     
    • Liviu Ionescu (ilg)

      Maybe the template is not compatible with STM32F417

      I doubt so, 417 is very similar to my 407, and both share the same CMSIS headers and library code.

      the only difference is the list of interrupt vectors, which you can easily check if it is appropriate for your processor.

      Failed to read memory @ address 0x289B4B00

      once your program crashes, it should be no surprise that it accesses illegal addresses.

      to diagnose it you need to trace it up to the point it crashes, not after it.

       

      Last edit: Liviu Ionescu (ilg) 2015-04-27
  • rvlander

    rvlander - 2015-04-27

    What about the first 0x0 I got?

     
    • Liviu Ionescu (ilg)

      a closer look shows that you messed the debug configuration; you changed the initial connect speed, you disabled the 'Continue' button, used absolute paths, etc.

      restore defaults in both tabs, configure paths properly and it should work.

       
  • rvlander

    rvlander - 2015-04-27

    You are right, the first 0x0 was due to misconfiguration (i changed a lot of things trying to find a solution to my pb). Now I will sort out the pb with the clock stuff.

    Thx for your help.

     
  • rvlander

    rvlander - 2015-04-27

    Hum it does not always crash at the same place ...

     
  • Liviu Ionescu (ilg)

    I cannot reproduce any crash, I duplicated your build configuration, restored defaults in the Debugger and Startup tabs, and it just works.

     
  • rvlander

    rvlander - 2015-04-27

    Thx for your time. If I come up with a fix. I'll let you know.

     
  • Liviu Ionescu (ilg)

    any progress?

     
  • rvlander

    rvlander - 2015-05-05

    I did not had time to look further into it, yet. Sorry.

     
  • Liviu Ionescu (ilg)

    • status: accepted --> closed
     
  • rvlander

    rvlander - 2015-05-16

    Hi,

    I eventually found out what as the pb (with some help).

    In _initialize_hardware.c, l140:
    RCC_OscInitStruct.PLL.PLLM = (HSE_VALUE/1000000u);

    It is evaluated to 8 with current parameters, my setup needs 16.
    Apparently the board I am using has a quartz with a different frequency than the one on the dev board.

    One last question:
    Where is configured HSE_VALUE?

    Thx

     
  • Liviu Ionescu (ilg)

    Where is configured HSE_VALUE

    in C/C++ General -> Paths and Symbols?

    in the Wizard?

     
  • rvlander

    rvlander - 2015-05-17

    Yep. Thanks.

    Sorry for noob question.

     
<< < 1 2 (Page 2 of 2)