Olimex ARM-USB-TINY-H + STM32F4 problem + IAR

[DGermana]

Hello,
I'm trying to use an ARM-USB-TINY-H debugger to program an STM32F407 processor.

I had it working a few weeks ago, but it was flaky.  I had to unplug the debugger and reboot the processor every time I made a code change.

Tonight, the debugger is not successfully talking to the processor any more.

Earlier this evening it successfully connected to the processor and gave this output:

Code Select Expand

Open On-Chip Debugger 0.7.0 (2013-05-05-10:41)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0x
ba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6
413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

However, when I tried to flash the board from IAR, it was unable to flash successfully, and since then it appears that the debugger can't even read the device number from the processor.  I now get this output:

Code Select Expand

Open On-Chip Debugger 0.7.0 (2013-05-05-10:41)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 300ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 700ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 1500ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 3100ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 6300ms


Does anyone have any suggestions to get this working again?

Thanks,

Dominic

[JohnS]

I've had I think the same thing.  I had a tough time getting it back and I'm unsure:
1. what caused it
2. exactly which step fixed it (sorry)

One of the things I think helped was dropping back to ST's own tools on WinXP (I use Linux) and I set level 0 and BOR OFF.

I also resorted to QStlink2 and that worked and still does.

I'm not sure if I needed to use the DFU stuff (jumpers from JP2 & JP3 to BOOT0:VDD & BOOT1(PB2):GND) - my notes are a bit unclear.

I tried texane stlnk but that didn't fix it at the time though it appears OK with a board not in a bad state.

When bad, I was seeing the board reported as only having 16K RAM.  I think what happened was that the Option Bytes were corrupted (see RM0090 p89).  I think good values are:
0x1fffc000: 5500aaff    option bytes AA=RDP no prot, ff=nRST_* etc
0x1fffc004: 5500aaff
0x1fffc008: 0000ffff    f=N/A, fff=flash sector write prot off
0x1fffc00c: 0000ffff

OOCD 0.8.0 is now out but I don't know if it's different.  I don't think OOCD caused my troubles but it may have let me set the bad values (if that's what happened).

John

[DGermana]

Thank you very much for your reply John.  If I understand your comments correctly, I think you're saying that you used an ST-LINK V2 debugger in combination with the QStlink2 GUI, and you were able to get the processor communicating with a debugger again.  After the STM32 device was talking to the ST-LINK debugger, you were able to revert back to using the Olimex ARM-USB-TINY-H debugger.

Is that correct?

Thanks!

Dominic

[DGermana]

I just want to follow up on this issue in case anyone else finds this in a future search.

The problem was due to a silly mistake on my part.  I thought that when I tried to flash the board the first time, it didn't work because I got an error message.  However, it did successfully program the board.

The reason for the error message, and the subsequent inability for the debugger to communicate with the processor, is because the code that I flashed to the board accidentally changed the GPIO configuration of the JTAG pins, effectively disabling the debugger interface!

I was able to solve the problem by holding the BOOT0 pin high while powering up the board so that it booted to the factory bootloader.  From there, the JTAG interface worked and I was able to reflash a corrected version of the code that did not disable JTAG.

Thanks again for your help John!

Dominic

[JohnS]

Good result!

Yes, I did mean an stlinkv2

John