cancel
Showing results for 
Search instead for 
Did you mean: 

Early breakpoint dosen't prevent startup code from beeing executed

tbt
Associate
Posted on January 19, 2007 at 21:07

Early breakpoint dosen't prevent startup code from beeing executed

2 REPLIES 2
tbt
Associate
Posted on January 08, 2007 at 07:39

I have a STR7 dev. board with a JTAG debugger attached and are using Multi 2000 dev. environment. If I set a breakpoint early in the code, it dosen't prevent the startup code from being processed. It seems that the processor starts running after reset, and the debugger then creates a connection afterwards, this means that some hardware are initialized before I would want it to!

Is it the STR7, the debugger or the debugger software that has a problem?

PS: It works fine on the Atmel AT91 we used before!

[ This message was edited by: T-Bee on 22-01-2007 08:37 ]

mohamed23
Associate II
Posted on January 19, 2007 at 21:07

Dear T-Bee,

You have to check if you are booting from the right hardware boot mode

Internal Flash, internal RAM or external Flash/RAM if you are using STR710 device and to ensure that your compiler / debugger is loading the firmware code accordinately.

I think, it is a problem of the debugger / software debugger because each

toolchain from a lot of vendors are not the same.So each one implements a different scheme of breakpoint handling mainly from the flash memory( like using SWI ) etc...

Another Point also is that the debugger has to Reset the micro using a software JTAG reset before that the CPU has excecuted some startup code

and most of debuggers introduces some delay in this start-up phase.

I hope that this may help you 🙂

regards, Rave :o

[ This message was edited by: Rave on 21-01-2007 17:39 ]