ST-LINK Utility 3.6 on Win7 HW won't write to STM32F205RGT7

[gary239955_stm1_stmicro_com]

Posted on March 04, 2015 at 10:22

I am still an STM32 newbie, so I apologize in advance for

potential dumb questions.

I recently installed ST-LINK Utility 3.6 on a workstation

running Windows 7 and need to erase and program a couple of ARM Cortex micros, P/N STM32F205RGT7, using the JTAG port. The board was designed by a customer and I followed his suggestion to use an Olimex ARM-JTAG-20-10 adapter cable to convert the 20-pin connector on my ST-LINK/V2 to the 10-pin headers on the board.  The signals that make it through are: - TMS/SWDIO, - TCK/SWCLK, - TDO/TRACESWO, - TDI, & - TRST.

The first thing we noticed when power it up (out of the box)

was that the embedded firmware was out of date.  The update button did not work until we disconnected the ST-LINK/V2 from the target hardware, but thereafter the update succeeded.

Examining the settings, there appear to be 3 different

connect modes:   - Normal,   - Connect under reset, &   - Hot plug,

We could not get the first two modes to work at all, but

could connect to the target in hot plug mode. After connection, the system could read RAM, flash, and registers; report things like supply voltage and CPU serial number, etc.

But when we attempt the 'Erase chip' command, the process

terminates in a sequence of 3 dialog boxes:   - ''Internal command error''   - ''Elf loader could not be transferred to device.''     ''Change 'Target/Settings/Connetion' to <<Connect Under      Reset>> and Try Again.''   - ''Error occurred during mass erase!''

If I then follow its advice and try to connect under reset,

the connection fails.

I captured the trace.log file during this process and attach

it for reference.

Ideas, anybody?

[AvaTar]

Posted on March 04, 2015 at 14:26

From your description, I assume it is no power issue. Some debug adapters (IMHO including the ST-Link V2 standalone version) allow powering the target, albeit with limited capabilities.

The board was designed by a customer and I followed his

suggestion to use an Olimex ARM-JTAG-20-10 adapter cable to convert the 20-pin connector on my ST-LINK/V2 to the 10-pin headers on the board. Your description sounds like the debug connection is logically correct, but rather shaky. Could the adapter cable be too long, or the JTAG PCB traces on the board be inappropriate ? Perhaps some pullup resistors on JTAG/SWD pins missing ? Most IDEs allow you to configure the JTAG/SWD clock frequency. I remember I once had to reduce it down to 1MHz for a STLink to get debug working.

[gary239955_stm1_stmicro_com]

Posted on March 04, 2015 at 16:37

Thanks for the pointers.

 1. The target is independently powered--always. It doesn't     need anything from the JTAG connector.

 2. When you say my connection is shaky, do you mean I lack

    a certain signal or that the connection is intermittent?

 3. The Olimex cable is 97 mm/3.8'' long, considerably

    shorter than the original cable that came with the ST-     LINK/V2.

    Still, I decided to probe the JTAG signals, as they

    appeared on the board:     - All (save 1) were perfectly square--no bandwidth       problems.     - The TCK signal frequency measured 1.1 MHz.     - The TRST-L signal idled high.  When I attempted to       erase the flash, ST-LINK/V2 pulled it low briefly       (~ 50 usec).  Although the falling edge was steep, the       rising edge was a exponential with a time constant in       the range of 10-20 usec. I find this a bit fishy.

 4. The ST-LINK Utility won't let me change clock frequency

    for a JTAG interface.

On my board, the TRST-L signal is also connected to the

micro's RST-L input.  I just parsed the data sheet and found a voltage spec (<= 0.8 V) but no minimum pulse width for the RST-L.  For TRST-L the answer probably lies in the JTAG spec.

Is it possible my ST-LINK/V2 is defective because it can't

pull the reset line low long enough?

[Tesla DeLorean]

Posted on March 04, 2015 at 16:43

with a similar issue had tried different JTAG pods.

I've recommended, and have used, the aforementioned Olimex converter, with an ST-LINK/V2 and an F205ZC (same die, only 256KB FLASH tested), on a boards we designed. It definitely works with 3.4, perhaps there is a problem with 3.6? I provided a mirror for 3.4 in the [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/Can%27t%20install%20ST-LINK%20Utility%20on%20Win7%20computer&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx&currentviews=30]other thread, and can provide mirror links to all the other versions I have. We wired a full JTAG, though others often wire enough for SWD, make sure the appropriate mode is selected. Ideally confirm the interface with different JTAG pods, and ones with native 10-pin connectors. I don't think the interface would function to the current level absent SWD connectivity, or if the connectors/cables were backward.

[Tesla DeLorean]

Posted on March 04, 2015 at 16:49

As Gary mentions the board comes with a cable, in my systems it's going to be no more than 5'' pin-to-pin using the stock Olimex cable, and that's fine. Problems with cables usually occur when people start using foot, or yard, long cables, or if the cable's plain defective or incorrectly orientated.

I use NRST and SWO also, mainly because I want to reset the board properly, and use SWV, and the production guys want to boundary scan.