Posted on July 01, 2015 at 01:23I have been using a STM32373C-EVAL board and programming it via the onboard STLink. Recently we've moved towards our own hardware design and so to verify that our SWD programmer was working I was testing programming the eval board via the CN17 JTAG port in SWD mode.
The adapter I was using is an OLIMEX ARM-USB-OCD-H with the ARM-JTAG-SWD attachment and then jumper cables between the appropriate pins. Everything was working fine but at some point I accidentally connected two of the ARM-JTAG-SWD adapters to the same cable. Ever since then I've been unable to program the board via either JTAG or SWD connected to CN17, but the onboard STLink still works fine.
I'm able to connect via openocd but when performing a load I get errors such as:
Info : SWD IDCODE 0x2ba01477
Error: Failed to write memory at 0x200001cc
Error: error writing to flash at address 0x08000000 at offset 0x00000000
adapter speed: 1000 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc, semihosting
Info : dropped 'gdb' connection
I also tried with an STM32F4Discovery as an STLink device but I get errors like:
Error: timed out while waiting for target halted
TARGET: stm32f3x.cpu - Not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08000770 msp: 0x20007fd8
semihosting is enabled
adapter speed: 1000 kHz
Error: timed out while waiting for target halted
TARGET: stm32f3x.cpu - Not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
Error: Target not halted
Error: failed erasing sectors 0 to 1
Error: flash_erase returned -304
Info : dropped 'gdb' connection
However programming with the onboard STLink USB device on the EVAL board continues to work as normal.
Does anyone have a clue as to what the problem may be? I notice in the schematic there's some zener diodes on the JTAG/SWD lines coming from the external connector. Is it possible those got damaged and are now causing communication to be unreliable? Based on the fact that the chip is still programmable via the onboard STLink I assume the problem is not there?
