Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Debugging reset handler

Posted by dalewheat on 2017-01-24 23:16

I’m debugging a trivial LED blinker program on the STM32F030F4P6 device, using a NUCLEO-F030R8 board for the ST-LINK/V2-1 interface, on a Windows 10 machine. The basic debugging process is working fine, except it seems that the reset handler is not being executed when run via the debugger.

If I press the reset button on the STM32F030F4P6 demo board, the application starts and blinks the LED properly. The program uses the SysTick timer interrupt to toggle the LED state. If I try to step through the code using the debugger, the SysTick interrupt handler is never invoked.

I’m using my own reset handler code, which sets up the progam environment, initializes the .data segment and clears the .bss segment. Additionally, it configures the SysTick to generate an interrupt twice a second. Again, all this works if I power-cycle the board or hit the hardware reset button.

When stepping through the code using the debugger, the SysTick peripheral is not properly configured (or not configured at all). If I try to have the debugger halt at the reset handler instead of main, it seemingly ignores this and continues to break at main().

If I put the SysTick initialization code within the main() function, instead of the reset() function, everything works as you would expect.

My questions are: 1) Why will the debugger not allow me to step through the reset handler, and 2) why does the debugger seems to skip over the reset handler while debugging?

Your help is appreciated.

Dale

main.c (2.64 Kb)
Reads: 11916
Link
Posted by diabolo38 on 2017-01-29 20:38

why do you want to rewrite everyting ? Reset handler etc ... Want template startupxxx.s will do fine no?
just use that at first at least. That is proven working.

wihout this “common” .s i would make sure “do not use standard start file” linker option is chedk
that can make standard symbol that you could miss to come from standard crt0 and play you tricks .

are your sure your “vector” section is well placed in the ld at cpu reset vector adress ?

Are you sure sp is setup by default ? in most reset handler s file that is set at very first desite “estack in the vector table”

Normaly if yo not not set stop at main option on your debug config you can debug from reset ,
just set a bkp on it or even hardcode the reset vetor in brake point.
I have use that feature to debug modfied startup.s (debug cmm copy, custom boot laoder etc ...)
if you can’t debug your reset it may be a signe it is not execute on reset , double check in map file symbol and addr

i’m not aware of “openocd” or other stm32 debugger doing anything specific on real debug but wome “reset conect option”.
some debugger play trick and bypass the slow crt0/startup when on simulator but am not aware of anything such here .

They are strnage conect reset option very obscure to me you want to look at dig for
“use hardware reset, connect under reset” reset_config srst_only srst_nogate

good luck

Link
Posted by dalewheat on 2017-01-30 17:59

@diabolo38

Thank you for replying to my request for assistance/clarification.

“why do you want to rewrite everyting ?”

Because I can. Because I’m interested in how things work. Because I want total control over my software. Because I don’t completely trust other people’s code. Because I don’t want to be beholden to anyone’s particular licensing scheme. Because I want to teach other people how to do these things for themselves and not rely on other people’s past efforts. There are other reasons but those are some of the main ones.

” Want template startupxxx.s will do fine no? ”

Yes, it most certainly does work, and I have often started projects using this proven, working code. However, in the dim past (circa 2007) there were no “new project wizards” that created instant ARM Cortex-M projects, and I had to figure out how all this worked, with the assistance of other, like-minded individuals:

http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/p/44559/157356Question

I then went on to use this newly-gained knowledge to write a two-part article that was published in Circuit Cellar magazine, issues 229 & 230 (August & September 2009), titled “Get Started With Embedded Development”, which was well-received, and featured the STM32 line of ARM Cortex-M3 devices.

“wihout this “common” .s i would make sure “do not use standard start file” linker option is chedk that can make standard symbol that you could miss to come from standard crt0 and play you tricks .”

You are correct: this has been done.

“are your sure your “vector” section is well placed in the ld at cpu reset vector adress ?”

and

“Are you sure sp is setup by default ? in most reset handler s file that is set at very first desite “estack in the vector table” ”

Yes. As I stated in the original post, the application does work. Power-on or hardware reset started the LED blinking at the appropriate rate. The only problem is that the SW4STM32 debugger will not debug the reset handler code, nor does it seem to even execute it.

I’ve successfully compiled and debugged this little program using Atollic TrueSTUDIO v7.0.1, both the “Lite” (free-as-in-beer) and “Pro” (commercially licensed) versions, which also use Eclipse+GCC.

Did you try to reproduce the problem using the file I attached? You will also need my custom linker script, attached below.

Any insight into why the SW4STM32 debugger won’t debug this application will be appreciated. I was interested in learning how to use the SW4STM32 offering because it is referenced in some of STmicro’s literature for software development. I understand that not everyone can budget a commercial software IDE for hobbyist projects, and I thought this one might be a good recommendation for future developers. The feedback I’ve received from this forum has also helped me further my own projects.


Dale

STM32F030F4P6_flash.ld (458 b)
Link

Posted by diabolo38 on 2017-01-30 18:52

i see you learning the hard ways then ;)

i do not have any f030 to try out your code

i also found strange you can’t debug from the reset

Did you try settign a break pount at 0x08000000 see what is on your flash memory and what goes wrong wiht debugger ?

The way you put data in flash text is quite strange but i gues sis ok am mor use to synthax like

.data :
{
. = ALIGN(4);
_sdata = .; /* create a global symbol at data start */
*(.data) /* .data sections */
*(.data*) /* .data* sections */

. = ALIGN(4);
_edata = .; /* define a global symbol at data end */
} >RAM AT> FLASH

As you do not have any “inititialzed” data it wan’t make any diference even that could be an issue.
also it wan’t explain why it would work w/o debugger

Some debuger/loader set ram at init from ram section they find in the elf but i do not know if that is the case for opencocd/stlink . Hslal ti be teh case i would expect it work with debuger and not witout rolleyes

they may be a lot of text data and rodata section you may miss with your ld
you shall add
*(.text*)
same for data *(.*data*) and rodata*

that is to collect some fency section such as aligned data.b data.w etc ...

fro text some compile option coud generate mutliple text section ie text1 text2....
i think here aboutMCu GCC c/c++ optimization “place the functon in their own section”

is can see belwo section in f4 ld is that mandatory for some tumb instructon  ?
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */


i’m scared and wan’t be abble to help you much.

Link
Posted by dalewheat on 2017-01-31 20:14

Although I didn’t “try settign a break pount at 0x08000000”, as this is not the entry point (it is a pointer to the initial stack pointer address), it made me think that I hadn’t explicity told the linker where the entry point really was.

By adding “ENTRY(reset)” to the linker script, all is now as it should be. The code in the reset() function is executed in the debugger, and I am able to set a breakpoint at the start of the reset() function, which works just fine now.

So don’t be scared, diabolo38. You nudged me into the right direction, and I appreciate it.

I have attached the corrected linker script in case anyone is interested.

STM32F030F4P6_flash.ld (474 b)
Link

Posted by diabolo38 on 2017-02-01 21:57

great that you got it biggrin
its like if debugger jump into the entry point in elf file and not mcu r eset after flash load. rolleyes

Link