Program always jump to/boot from 0x20000000?

[StephanMair]

Posted on January 03, 2015 at 13:50

Hello all, I just began working on an old project which had some problems that had not been solved, of which I did manage to pinpoint (in relative terms) the source.

Developing platform: Keil uv4 Chip:                          F105RBT6 Debugging Tool:        Jlink It seems that the current program that I wrote always try to run from the 0x20000000 address, which is to the best of my knowledge, the RAM starting address. To be more specific, whether I press F5 or F11 in the debug mode of Keil, it always jump right to : 0x20000000 BE00      BKPT     0x000x08 And as you can see, since there is a BKPT there, the program gets halted. In other words, the program just jump to 0x20000000, then stops. When I hit the reset button, the program can return to: 0x00000000 2308      MOVS     r3,#0x08FF   ; ? Undefined Just fine, but when I hit F11, expecting it to run to 0x00000002 2000      MOVS     r0,#0x001A   ; ? Undefined It doesn't. It just jump right to 0x20000000. I've also placed breakpoints between 0x00000000 and 0x20000000, but no, the program never stops at any of those breakpoints, in other words, the program didn't executed step by step all the way to 0x20000000, but skipped all the lines in between. Besides all that, I had BOOT0 set to 0, which means it will always boot from USER Flash. And this whole ''skip'' thing does not change one bit regardless of the BOOT0/BOOT1 configuration combination. I'm suspecting I made some wrong configurations under ''Target Options'', but I really don't know which one, and it's just a suspicion. I was also thinking about faulty .s startup file and system_stm32f10x.c, and replaced them with official library files (I didn't modify any of them in the first place, no reason to), and the problem remains. Could anyone please help me as to what may have caused all these problems?

[Tesla DeLorean]

Posted on January 03, 2015 at 14:42

Start by focusing on the code in startup_stm32f1xx.s, what's in the vector table, and in the ResetHandler path. This will include code in, and called by, SystemInit() prior to getting to your main() code.

Try also unchecking ''run to main'' in the debug options, and walk through the code until it gets to 0x20000000

[StephanMair]

Posted on January 04, 2015 at 00:01 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6gm&d=%2Fa%2F0X0000000btG%2FfVEBlxmAOjUBkJUFjaCLehsVlV1gdRiHExv4Bgq6rhc&asPdf=false

[Tesla DeLorean]

Posted on January 04, 2015 at 00:48

I'd probably review the .MAP and output code.

So if you have working projects for this exact hardware/platform, then clone the project, and then merge in the differences a bit at a time.

[StephanMair]

Posted on January 04, 2015 at 03:08

Yes, I was thinking about that and had tried the comment - uncomment method for some time now but no luck. I guess I'll have to do it the hard way, like you said, find an earlier working project, then merge in the changes and modifications bit by bit.

Sometimes this is caused by an overlooked erroneous configuration. The difficult part is there are so many configurations you just don't know where to look.

[Tesla DeLorean]

Posted on January 04, 2015 at 14:41

The difficult part is there are so many configurations you just don't know where to look.

Which is why you'd look at the output code, as it's what the processor is being instructed to do. If you understand what was created you'd be able to determine why it was created that way. I wasn't suggesting commenting out stuff, but rather cloning (copying) and entire working project structure, with all it's internal settings/configuration, and then copying in the problem files starting with the start up code, and an empty main() loop.