On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <[email protected]> wrote: > Hi Guys, > > I have the following problem.. > > Each time I try to Debug I got this Error Message it is out of my logfile.. > > Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: > CTRL/STAT error, 0xf0000021 > Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP > STICKY ERROR > Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: > CTRL/STAT 0xf0000001 > Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW > 0x23000052, MEM_AP_TAR 0xfffffffc > Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: > CTRL/STAT error, 0xf0000021 > Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP > STICKY ERROR > Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: > CTRL/STAT 0xf0000001 > Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW > 0x23000052, MEM_AP_TAR 0xfffffffc > Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error > address 0xfffffff8, count 0x1
At a first glance, it seems fairly normal. The failed accesses to 0xfffffffX are because GDB tries to backtrace through the stack frames as far as it goes. Sooner or later it will reach one with the special exception return value and stop because it can't read memory there. I assume debugging isn't working for you (and not just the phony error message nagging you)? What are the symptoms? Any other error messages? > I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse, > OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd > 0.4.0 You should be aware of a bug in 0.4.0 causing the first debug session, after OpenOCD has been started, to fail if the target is running when GDB connects. It is fixed in recent git and can be worked around in 0.4.0 by either doing 'reset init' in a gdb-attach event handler, or adding -c init -c 'reset init' to the command line when starting OpenOCD. > > here are my GDB commands: > > target remote localhost:3333 > monitor reset halt > monitor stm32x mass_erase 0 > monitor stm32x options_read 0 > monitor stm32x unlock 0 > monitor reset > monitor flash write_image main.bin 0x8000000 bin > file main.out > load main.out > break main This looks a bit strange. Nowadays, 'reset init' seems to be preferred over 'reset halt'. I don't really know the difference but feel it works better. The 'flash write_image' is superfluous since you later tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB handle the flash programming. Also, I believe a second 'reset init' is needed right after the load in order to update the initial SP and PC from the newly loaded image. The 'mass_erase' is not needed, unless you want to clear unused areas of flash, since the GDB load will erase flash on a page by page basis. The 'unlock' is of course only necessary if you have previously activated the readout protection. You could make a separate script to unlock protected chips instead of doing it each debug session. My GDB initialization looks something like this (out of my head): target remote localhost:3333 monitor reset init load (if GDB has been told on the command line which executable to debug, there's no need to specify a file here) monitor reset init tbreak main continue /Andreas _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
