2013-12-11 04:39 AM
to be migrated, sourceId: 36070:697285D7-A9CA-445D-B16C-F23BF0E3B1A3
2013-12-11 06:22 AM
I'm no expert
but
try to verify
all
of the
jtag
pin
STM32 start with JTAG enabled and change to SWD when receive a clk/data command sequence. Check the pullup/pulldown for all pin of jtag interface (Mine is
just an idea
I do not want
to waste your time
) form my stm32f4 manualUsing serial wire and releasing the unused debug pins as GPIOsTo use the serial wire DP to release some GPIOs, the user software must change the GPIO
(PA15, PB3 and PB4) configuration mode in the GPIO_MODER register. This releases
PA15, PB3 and PB4 which now become available as GPIOs.
When debugging, the host performs the following actions:
• Under system reset, all SWJ pins are assigned (JTAG-DP + SW-DP).
• Under system reset, the debugger host sends the JTAG sequence to switch from the
JTAG-DP to the SW-DP.
• Still under system reset, the debugger sets a breakpoint on vector reset.
• The system reset is released and the Core halts.
• All the debug communications from this point are done using the SW-DP. The other
JTAG pins can then be reassigned as GPIOs by the user software. I think you must connect also reset pin to interface
2013-12-11 06:29 AM
Will try, tnx
2013-12-11 08:26 AM
Check supply actual voltage.
Have a 10K Pull-up on PB2 (BOOT1) Connect NRST to interface, ideally have pull-up on that too, and SWDIO/SWCLK Secondary signs-of-life test via USART1 PA9/PA10 sending 0x7F @ 9600 8E1, receiving 0x79 back, with BOOT0 pulled high.2013-12-11 12:33 PM
Good evening, mates!
Tnx for your advices, it may be helpful in other time.. but this problem solved from another way. I'd say, very unexpected way. I'm update firmware of stm32vldiscovery ST-Link module from 1.10 to 1.12 and all gets ok. I hope this solution can help anyone else2013-12-11 01:32 PM
Thanks for the update, I'd kind of discounted that because it was another Value Line part.