15 Replies Latest reply on Jul 5, 2019 11:47 PM by ilg

    Debbugger not going to main.c

    enesm

      I am not really comfortable with the title but I hope you will understand what I mean.

      So I started using Eclipse recently (about a few weeks ago). Before that I used Keil. I used library version 1.0.8 (so not HAL) however when I tried to create an empty project (although those packs aren't even installed) the empty project used HAL libraries. Basically same problem as in this post How to create a stm32F407 stdperiph project?. Later I found this guide STM32 Project From Scratch on Eclipse – TECH Inside . What very helpful and exactly what I needed. I followed all the steps and created the project from scratch.

       

      Build the whole project no errors or warnings. However when I start debugging the debugger never comes to main.c file.

      Debugger

      This is the first view when I enter (J-Link) debugger. I put a breakpoint in the beggining of main() and processor never hits it. When I open the disassembly and run, it quickly comes back to start at "0x20000000 bkpt 0x0000" also at left it says:

      "Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)  

          0x20000000  

          0xfffffffe"

      I really have no clue what the problem is. If anyone can at least point tell me what the problem could it would be very much appreciated.

       

      Thanks in advance

        • Re: Debbugger not going to main.c
          ilg

          there are many things before main() that can go wrong, set your breakpoint in the Reset_Handler and trace it from there.

           

          and enable the program listing, to take a look at the resulting code, to be sure it is what you want.

            • Re: Debbugger not going to main.c
              enesm

              I looked for Reset_Handler and could not find it. While I was looking for it I noticed a couple of things.

              First one was there were no comment part in disassembly view. It was as such in attachment.

               

              Another thing was although console said done with 0 errors and 0 warnings when i clicked on problems it said: "cannot find entry symbol _start; defaulting to 0000000008000028". I looked it up it should be inside startup file among with Reset_Handler.

               

              And after these I thought somehow eclipse couldn't find my startup file and uses a built in default sort of thing. I backed whole project and deleted all files with "*.s" and "*.S" extension (I say all because as described in the link in the post i picked the correct one and excluded others from build). Then I compiled everything is the same , I debug everything is the same.

               

              I think this certainly means my startup file is not used. I am not sure though. And I don't how to tell "use my startup file which is here!"

                • Re: Debbugger not going to main.c
                  ilg

                  reading your disassembly file is difficult, enable the creation of the listing file, it is much easier to read (go to the Settings -> C/C++ -> Toolchain)

                   

                  also be sure you do not enable --gc-sections at link time, otherwise the linker will remove code that it considers useless.

                   

                  rebuild your project and inspect the listing file, it should show exactly what it contains, and the Reset_Handler should be there.

                    • Re: Debbugger not going to main.c
                      enesm

                      Sorry if I didn't explain it well enough i was referring to the absence of lines with "<--------" in the one I uploaded now.

                      I did what you said, a linker file was created but inside there was no Reset_Handler. It keeps saying "cannot find entry symbol _start; defaulting to 0000000008000028" (I recovered from the backup).

                       

                      I can find main in list file when i search. Which, I think, means main is being is compiled. However still breakpoint in main is not reached also my main is an empty "while(1)" but when I run in debugger it quickly goes to start of rom and stops.

                       

                      I didn't think it was relevant but sometimes it also says "Description    Resource    Path    Location    Type

                      Invalid project path: Duplicate path entries found (/template [Include path] base-path:template isSystemInclude:true includePath:lib/STM32F4xx_StdPeriph_Driver/inc), path: [/template].    template        pathentry    Path Entry Problem"

                      • Re: Debbugger not going to main.c
                        enesm

                        Sorry if I didn't explain it well enough i was referring to the absence of lines with "<--------" in the one I uploaded now.

                        I did what you said, a linker file was created but inside there was no Reset_Handler. It keeps saying "cannot find entry symbol _start; defaulting to 0000000008000028" (I recovered from the backup).

                         

                        I can find main in list file when i search. Which, I think, means main is being is compiled. However still breakpoint in main is not reached also my main is an empty "while(1)" but when I run in debugger it quickly goes to start of rom and stops.

                         

                        I didn't think it was relevant but sometimes it also says "Description    Resource    Path    Location    Type

                        Invalid project path: Duplicate path entries found (/template [Include path] base-path:template isSystemInclude:true includePath:lib/STM32F4xx_StdPeriph_Driver/inc), path: [/template].    template        pathentry    Path Entry Problem"

                          • Re: Debbugger not going to main.c
                            ilg

                            as far as I can tell, you project does not include a startup file.

                             

                            your image must start with the two Cortex-M pointers (reset and stack), followed by the array of interrupt handlers.

                             

                            unless you see this in the image, with both pointers valid, there is no point of waiting for the main breakpoint to fire, since the core will crash before, probably because the address of the reset handler is invalid, or the stack pointer is invalid.

                              • Re: Debbugger not going to main.c
                                enesm

                                That's what I think too. The reason it does not crash might because of this "cannot find entry symbol _start; defaulting to 0000000008000028". Or maybe it crashes because all I can see is I press resume and for a brief moment the yellow arrow (that points to where program counter is) disappears and reappears at the beginning of ROM.

                                Do you know how I can specifically tell the directory and the name of the startup file that I want to use ?

                                  • Re: Debbugger not going to main.c
                                    ilg

                                    the startup file is just a regular source file as all other source files, you cannot point to it, it must be in one of the source folders and must have a known extension (.c or .S).

                                     

                                    you can check which files were compiled by inspecting the hierarchy in the build folder (Debug or Release), you should find the corresponding .o file there.

                                     

                                    you can also check which files entered the link step by inspecting the linker map file.

                                     

                                    and I'd not be sure the program did not crash, given the missing startup code, the program most probably raised an exception.

                                      • Re: Debbugger not going to main.c
                                        enesm

                                        "you can check which files were compiled by inspecting the hierarchy in the build folder (Debug or Release), you should find the corresponding .o file there." I don't know what you meant by the hierarchy but in the Debug folder there was only one .o file which was main.o in Debug/src .

                                         

                                        I looked at the map file there weren't any ".s" or ".S" file or anyone that included the name "startup". I am confident that there is no startup file being used.

                                         

                                        By the way forgive me for my lack of knowledge but is the order of the directories in "properties->c/c++ build->settings->includes" important ? (just asking since you mentioned hierarchy)

                                          • Re: Debbugger not going to main.c
                                            ilg

                                            > only one .o file which was main.o

                                             

                                            did you really tell Eclipse the folders where to search for source files?

                                              • Re: Debbugger not going to main.c
                                                enesm

                                                I think it does. Here are my screenshots. Also It does resolve " RCC_AHB1PeriphClockCmd" and others which are in "std_periph_driver" libraries which makes me think source files directories are listed properly.

                                                  • Re: Debbugger not going to main.c
                                                    ilg

                                                    please check Properties -> C/C++ General -> Path and Symbols -> Source Locations; the folder where the startup file is (or a parent folder) should be listed there. and there should be no exclusions.

                                                     

                                                    btw, in what folder is the startup file located?

                                                      • Re: Debbugger not going to main.c
                                                        enesm

                                                        The path of startup file was there present (gcc_ride7 by the way). It was excluded as you suspected.

                                                        Then I cleaned the filter as such: (in both debug and release)

                                                        But after i proceeded build after the first time i get this:

                                                        After this , I go ahead and don't clean the filter and try and build once more and i get this:

                                                        Still i can not find "Reset_Handler" int the .map file , but i get .o files of std_periph_drivers in debug.

                                                         

                                                        I later managed to fix duplicate folders issue (in Properties -> C/C++ General -> Path and Symbols -> includes some directories were present among some of their subdirectories)

                                                         

                                                        But "can not find entry symbol ..." error is still present

                                                          • Re: Debbugger not going to main.c
                                                            enesm

                                                            Amazing update I was desperately looking through "c/c++ General" when I noticed in the tab "File Types" there was no "*.s". So ultimately no one was looking for a startup file .  I added it  in the workspace preferences and everything worked. I never thought I would be so happy to see led's light up, after writing rtos projects with 20+ threads in Keil.

                                                             

                                                            Although there still is one small thing, after I added "*.s" to workspace preferences I still got the "cannot find entry symbol..." error. I don't know how but I noticed that the address was a little different this time. To be honest that's when I thought it might work this time and proceeded to debug to see the heavenly leds light up.

                                                             

                                                            By the way thank you "Liviu Ionescu" for helping me through all this process , it means a lot. I am very grateful.

                                                              • Re: Debbugger not going to main.c
                                                                ilg

                                                                > after I added "*.s" to workspace preferences

                                                                 

                                                                due to some very complicated Eclipse internals, it is recommeded to use .S for the assembly files, not .s.

                                                                 

                                                                I'm glad you managed to configure it.

                                                                 

                                                                however, the recommended solution remains HAL, not StdPeriph.