2017-06-22 02:16 AM
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-code2017-07-05 05:32 AM
I looked through the code but I could not find
rdimon-crt0.o or rdimon in the startup file?
2017-07-05 08:46 AM
rdimon-crt0 is part of the GCC tool chain but I see you are using Keil which will provide its own startup code.
I think this addresses your problem:
http://www.keil.com/support/docs/3614.htm
By default the tool chain is likely to use semihosting. As explained in the above link you need to either:
Provide retarget.c which redirects the semihosting library calls (from printf etc.), see:
http://www.keil.com/support/man/docs/gsac/gsac_retargetcortex.htm
or use the Keil Compiler pack
or use Microlib which does not use semihosting.
Now why the toolchain builds in libraries that use semihosting when MDK-ARM/uVision doesn't support semihhosting beats me..