Code not going directly to main loop

[Cooke.Ernest]

Posted on June 22, 2017 at 11:16

Hi,

I am currently in the process of converting project code I have using the Standard peripheral library to the Hardware Abstraction Layer (HAL).

I noticed that when I try to debug the code and place a breakpoint in the main loop that the code does not go directly to the main loop when I press the 'Run' (F5) button in Keil uVision.  The 'Run' button instead must be pressed 4 times before it goes to the main loop.

Before the code goes to the main loop, it is caught in the following location in the startup file.

After this I can get the code to execute a basic function i.e.

blink an

 LED.  

However when I try to execute the code in standalone mode it does not work.

When I tried this code using the

Standard peripheral library, it went directly to the main loop the first time I pressed the 'Run' button in debug mode and it worked fine in standalone mode i.e. I got the LED to blink.

Does anyone have any suggestions as to what the issue might be or how I could solve it?

Kind Regards,

Ernest

#main-loop #standard-peripheral #stm32f1 #debug #hardware-abstraction #standalone-mode #startup-code

[Tesla DeLorean]

Posted on June 22, 2017 at 15:00

Make sure you have 'Run to main()' option checked.

That you don't have printf() code in SystemInit()

Check that code isn't getting stuck in the SystemInit() code you provided, ie system_stm32fxxx.c, clock and PLL initialization.

The __main function is not your main() function, but rather code that initializes the C runtime, and copies/zeros the statics in RAM, expanding the load region.

Look at where specifically it is stopping.

[Cooke.Ernest]

Posted on June 26, 2017 at 11:43

Hi Clive,

To answer your questions:

The 

''Run to main()'' option is checked.

I don't have printf() code in SystemInit().

In the startup_stm32f10x_md.s file, the code is getting stuck at the following location:

After I press the 'Run' button 4 times, the code will jump from here to the main loop.

Kind Regards,

Ernest

[Tesla DeLorean]

Posted on June 26, 2017 at 14:00

Right now it looks like you have 4 breakpoints set on assembler code, you need to click on those to remove.

Step-Into the line 136 code to see where it goes

[Cooke.Ernest]

Posted on June 26, 2017 at 14:16

I have removed the breakpoints and when I step into line 136 of the code, I am brought to the _mutex_release function (line 342) in the RTX_CM_lib.h file.

The code then goes to line 346.  When I step into the code further, the program hangs.

[Tesla DeLorean]

Posted on June 26, 2017 at 18:55

Is this a debug version of the library?

Check the Debug->Breakpoint settings, or if some RTOS level debug/trace options were enabled.

Not really familiar with this code being in,or called by,  __main

If it were me, I'd disassemble the project with

FROMELF -c project.axf  >project.lst

[Cooke.Ernest]

Posted on June 28, 2017 at 10:36

Sorry, I don't quite understand your question.

Which part is the Breakpoint settings?

To disassemble the project, where should I put '

FROMELF -c project.axf  >project.lst'?

Regards,

Ernest

[Tesla DeLorean]

Posted on June 28, 2017 at 11:56

Is it a 'Debug' or 'Release' build? Could there be a reason it would be breakpointing on the code in question? I didn't create the project, so have minimal insight into the specifics.

Start perhaps with 'Kill All Breakpoints', and see if that alters the fact pattern.

FromELF is a command line tool/application that comes with Keil, the project.axf is the file generated by the build process in the output directory, the name will depend on your project settings/naming. You will likely need to address the pathing to the tool, and project output directory. I would use it to generate a disassembly listing so I could walk the code flow and understand where/when the breakpoints are applied. Probably a bit beyond your scope.

[tomtom9195]

Posted on June 29, 2017 at 05:09

That is pretty much exactly the behaviour you get if your build includes the semihosting library code but the semihosting is not enabled in the debugger. The breakpoints ('bkpt 0xab') are in the startup code in rdimon-crt0.o. Look for rdimon in the map file. If it is there then check your linker configuration if you didn't expect semihosting.

If you try and run it standalone it will stop at the first breakpoint.

See 'Building an application for a non semihosting environment': 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.kui0099a/armlib_ciheeaja.htm

[bbee]

Posted on July 05, 2017 at 14:02

To stop guessing here, could you please be so kind to tell us which tools you use?

It looks like you have RTX running, which version? Which STM part? Which version of uvision? Which version of the HAL libary?

__main is not your int main(void) function.

__main is the program entry point provided by some kind of library which gets called before your int main(void) function gets called. Usually main is called from within __main after some other initialisation has been done there (like initializing variables). So __main is the secret incredient placed there by KEIL to be able to call your main after all global initialized data has been initialized.

What you need is a linker map file (or list file) that shows the content of the program (try option --list=<filename> along with --map and pass it to the linker). Then have a look into the linker generated map file and search for main or __main. You will see that __main is different from main and thats the reason why you are not getting directly to your main when you step after startup.