[Openocd-development] STM32, openocd and eCos
Hi all, I'm a bit lost with a problem concerning OpenOCD, eCos and my STM32 board. I'm running with a ftdi2232-based usb2jtag adapter. I'm already using this adapter for quite a long time for my ARM9-based projects, so the hardware should be fine. I'm currently porting eCos to a STM32 MINI board, which John announced a while ago. The port is based on the STM3210E board port. A simple demo program which prints out some lines on the serial channel is being flashed into the chip's on-chip flash. When I let the processor run it directly without debugger, it works fine. But when I'm stepping through the code and want to step over a thread-delay routine OpenOCD or the CPU gets somewhat confused and I'm unable to continue debugging. That's what I'm doing in gdb (arm-eabi-gdbtui actually): target remote : mon reset init load b simple_prog c b serial.c:99 [the line before the thread delay function] c n And that's what I'm getting in GDB then: -- snip -- JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 Polling target failed, GDB will be halted. Polling again in 100ms Program received signal 0, Signal 0. cyg_thread_delay (delay=0) at /home/manuel/Arbeit/netX-ACCOS/netx_accos/trunk/src/ecos/ecos-cvs/packages/kernel/current/src/common/kapi.cxx:292 Current language: auto; currently c++ -- snip -- OpenOCD seems to lose the connection to the target as I get the following lines repeatedly on the shell: -- snip -- Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 Polling target failed, GDB will be halted. Polling again in 6300ms -- snip -- The CPU seems to continue running, as I get the output from the program correctly. The parameter delay = 0 seems to be bogus, because the function is called with delay=1000 (which is 10s delay with the default config) from the application thread. My openocd config is attached. I'm running the git version pulled an hour ago, but had no luck with stable 0.4.0 either before. I'm quite new to the STM32 / Cortex-M3 familiy, but already did a lot work on ARM9 before. I also tried lowering the JTAG speed to 100kHz which did not help. The thread delay is doing a 10 sec delay, but signal 0 is hit immediately after stepping. I tried with a cyg_thread_delay(1) et voila: stepping suddenly works! So what's goind on here? Has anyone worked with openocd on an STM32? I'm not sure if the problem lies in openocd or the STM32 eCos port... I came to the problem because I'm writing and debugging a SPI-Flash driver (based on the M25Pxx driver) for the on-board flash (SST25VFxxxB) which uses the cyg_thread_delay function when kernel support is available. But I reduced it to a simple serial example, which is delaying between outputting lines... Any help appreciated. Regards, Manuel -- Manuel Borchers Web: http://www.matronix.de eMail: man...@matronix.de set WORKAREASIZE 0x source [find interface/usb2jtag_mb.cfg] source [find target/stm32.cfg] source [find cpu/arm/cortex_m3.tcl] source [find chip/st/stm32/stm32.tcl] #reset_config srst_only reset_config trst_and_srst #jtag_khz 100 #stm32x mass_erase 0 stm32.cpu configure -event reset-init { halt flash probe 0 #stm32x mass_erase 0 } #gdb_flash_program enable init reset init signature.asc Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
Replying to myself: Sorry, this mail was intended for the eCos mailing list first... But if anyone here is familiar with the STM32 and even eCos, I'm all ears for some tips... Cheers, Manuel Am Sonntag, den 12.12.2010, 17:22 +0100 schrieb Manuel Borchers: > Hi all, > > I'm a bit lost with a problem concerning OpenOCD, eCos and my STM32 > board. > > I'm running with a ftdi2232-based usb2jtag adapter. I'm already using > this adapter for quite a long time for my ARM9-based projects, so the > hardware should be fine. > > I'm currently porting eCos to a STM32 MINI board, which John announced a > while ago. The port is based on the STM3210E board port. > > A simple demo program which prints out some lines on the serial channel > is being flashed into the chip's on-chip flash. When I let the processor > run it directly without debugger, it works fine. > > But when I'm stepping through the code and want to step over a > thread-delay routine OpenOCD or the CPU gets somewhat confused and I'm > unable to continue debugging. > > That's what I'm doing in gdb (arm-eabi-gdbtui actually): > > target remote : > mon reset init > load > b simple_prog > c > b serial.c:99 [the line before the thread delay function] > c > n > > And that's what I'm getting in GDB then: > -- snip -- > JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed > MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 > Polling target failed, GDB will be halted. Polling again in 100ms > > Program received signal 0, Signal 0. > cyg_thread_delay (delay=0) > > at > /home/manuel/Arbeit/netX-ACCOS/netx_accos/trunk/src/ecos/ecos-cvs/packages/kernel/current/src/common/kapi.cxx:292 > Current language: auto; currently c++ > -- snip -- > > OpenOCD seems to lose the connection to the target as I get the > following lines repeatedly on the shell: > > -- snip -- > Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed > Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 > Polling target failed, GDB will be halted. Polling again in 6300ms > -- snip -- > > The CPU seems to continue running, as I get the output from the program > correctly. > > The parameter delay = 0 seems to be bogus, because the function is > called with delay=1000 (which is 10s delay with the default config) from > the application thread. > > My openocd config is attached. > I'm running the git version pulled an hour ago, but had no luck with > stable 0.4.0 either before. > > I'm quite new to the STM32 / Cortex-M3 familiy, but already did a lot > work on ARM9 before. > > I also tried lowering the JTAG speed to 100kHz which did not help. The > thread delay is doing a 10 sec delay, but signal 0 is hit immediately > after stepping. > > I tried with a cyg_thread_delay(1) et voila: stepping suddenly works! So > what's goind on here? Has anyone worked with openocd on an STM32? > > I'm not sure if the problem lies in openocd or the STM32 eCos port... > > I came to the problem because I'm writing and debugging a SPI-Flash > driver (based on the M25Pxx driver) for the on-board flash (SST25VFxxxB) > which uses the cyg_thread_delay function when kernel support is > available. But I reduced it to a simple serial example, which is > delaying between outputting lines... > > > Any help appreciated. > Regards, > Manuel > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- Manuel Borchers Web: http://www.matronix.de eMail: man...@matronix.de signature.asc Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On Sun, Dec 12, 2010 at 5:22 PM, Manuel Borchers wrote: > Hi all, > > I'm a bit lost with a problem concerning OpenOCD, eCos and my STM32 > board. > > I'm running with a ftdi2232-based usb2jtag adapter. I'm already using > this adapter for quite a long time for my ARM9-based projects, so the > hardware should be fine. > > I'm currently porting eCos to a STM32 MINI board, which John announced a > while ago. The port is based on the STM3210E board port. > > A simple demo program which prints out some lines on the serial channel > is being flashed into the chip's on-chip flash. When I let the processor > run it directly without debugger, it works fine. > > But when I'm stepping through the code and want to step over a > thread-delay routine OpenOCD or the CPU gets somewhat confused and I'm > unable to continue debugging. > > That's what I'm doing in gdb (arm-eabi-gdbtui actually): > > target remote : > mon reset init > load > b simple_prog > c > b serial.c:99 [the line before the thread delay function] > c > n > > And that's what I'm getting in GDB then: > -- snip -- > JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed > MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 > Polling target failed, GDB will be halted. Polling again in 100ms > > Program received signal 0, Signal 0. > cyg_thread_delay (delay=0) > > at > /home/manuel/Arbeit/netX-ACCOS/netx_accos/trunk/src/ecos/ecos-cvs/packages/kernel/current/src/common/kapi.cxx:292 > Current language: auto; currently c++ > -- snip -- > > OpenOCD seems to lose the connection to the target as I get the > following lines repeatedly on the shell: > > -- snip -- > Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed > Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 > Polling target failed, GDB will be halted. Polling again in 6300ms > -- snip -- > > The CPU seems to continue running, as I get the output from the program > correctly. > > The parameter delay = 0 seems to be bogus, because the function is > called with delay=1000 (which is 10s delay with the default config) from > the application thread. > > My openocd config is attached. > I'm running the git version pulled an hour ago, but had no luck with > stable 0.4.0 either before. > > I'm quite new to the STM32 / Cortex-M3 familiy, but already did a lot > work on ARM9 before. > > I also tried lowering the JTAG speed to 100kHz which did not help. The > thread delay is doing a 10 sec delay, but signal 0 is hit immediately > after stepping. > > I tried with a cyg_thread_delay(1) et voila: stepping suddenly works! So > what's goind on here? Has anyone worked with openocd on an STM32? > > I'm not sure if the problem lies in openocd or the STM32 eCos port... > > I came to the problem because I'm writing and debugging a SPI-Flash > driver (based on the M25Pxx driver) for the on-board flash (SST25VFxxxB) > which uses the cyg_thread_delay function when kernel support is > available. But I reduced it to a simple serial example, which is > delaying between outputting lines... > > > Any help appreciated. > Regards, > Manuel > It may be that the scheduler or the idle thread puts the core in low power mode if no thread is ready to run. That will break the debugger connection. See if anything executes a WFI or WFE instruction, and disable it. There's likely a configuration setting for it. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
Hi Andreas, hi list, On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote: > It may be that the scheduler or the idle thread puts the core in low > power mode if no thread is ready to run. That will break the debugger > connection. See if anything executes a WFI or WFE instruction, and > disable it. There's likely a configuration setting for it. Yes, thanks for hint, I already got a hint on the eCos list about the idle thread executing 'wfi'. I suspected something like that but didn't find it myself in the sources. I also got a hint how to keep the clock for JTAG active when the CPU goes to wfi. I'll try that tonight and report back if it didn't solve my problem. Thanks again! Cheers, Manuel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On 13/12/2010 08:47, Manuel Borchers wrote: Hi Andreas, hi list, On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote: It may be that the scheduler or the idle thread puts the core in low power mode if no thread is ready to run. That will break the debugger connection. See if anything executes a WFI or WFE instruction, and disable it. There's likely a configuration setting for it. Yes, thanks for hint, I already got a hint on the eCos list about the idle thread executing 'wfi'. I suspected something like that but didn't find it myself in the sources. I also got a hint how to keep the clock for JTAG active when the CPU goes to wfi. I'll try that tonight and report back if it didn't solve my problem. Thanks again! Cheers, Manuel Look for the define HAL_IDLE_THREAD_ACTION in packages/hal/cortexm/arch/current/include/hal_arch.h - i comment that out while debugging. However it does work ok if slow the jtag clock to about 1kHz aswell. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On Mon, Dec 13, 2010 at 10:16 AM, Spencer Oliver wrote: > On 13/12/2010 08:47, Manuel Borchers wrote: >> >> Hi Andreas, hi list, >> >> On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote: >>> >>> It may be that the scheduler or the idle thread puts the core in low >>> power mode if no thread is ready to run. That will break the debugger >>> connection. See if anything executes a WFI or WFE instruction, and >>> disable it. There's likely a configuration setting for it. >> >> Yes, thanks for hint, I already got a hint on the eCos list about the >> idle thread executing 'wfi'. I suspected something like that but didn't >> find it myself in the sources. >> I also got a hint how to keep the clock for JTAG active when the CPU >> goes to wfi. I'll try that tonight and report back if it didn't solve my >> problem. >> >> Thanks again! >> Cheers, >> Manuel > > Look for the define HAL_IDLE_THREAD_ACTION in > packages/hal/cortexm/arch/current/include/hal_arch.h - i comment that out > while debugging. > > However it does work ok if slow the jtag clock to about 1kHz aswell. Are you sure? I can't see why that would work. Unless you have a high frequency interrupt running that happens to match with the jtag transitions. Removing WFI/WFE in debug builds, or setting DBGMCU_CR to keep clocks running solves most cases, anyway. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On 13/12/2010 21:51, Andreas Fritiofson wrote: On Mon, Dec 13, 2010 at 10:16 AM, Spencer Oliver wrote: On 13/12/2010 08:47, Manuel Borchers wrote: Hi Andreas, hi list, On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote: It may be that the scheduler or the idle thread puts the core in low power mode if no thread is ready to run. That will break the debugger connection. See if anything executes a WFI or WFE instruction, and disable it. There's likely a configuration setting for it. Yes, thanks for hint, I already got a hint on the eCos list about the idle thread executing 'wfi'. I suspected something like that but didn't find it myself in the sources. I also got a hint how to keep the clock for JTAG active when the CPU goes to wfi. I'll try that tonight and report back if it didn't solve my problem. Thanks again! Cheers, Manuel Look for the define HAL_IDLE_THREAD_ACTION in packages/hal/cortexm/arch/current/include/hal_arch.h - i comment that out while debugging. However it does work ok if slow the jtag clock to about 1kHz aswell. Are you sure? I can't see why that would work. Unless you have a high frequency interrupt running that happens to match with the jtag transitions. Did last time i tried it - it has been a while however. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development