Skip to main content
gary239955_stm1_stmicro_com
gary239955_stm1_stmicro_com
Associate II
March 4, 2015
Question

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

  • March 4, 2015
  • 4 replies
  • 2246 views
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?

    This topic has been closed for replies.

    4 replies

    AvaTar
    AvaTar
    Senior III
    March 4, 2015
    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
    gary239955_stm1_stmicro_comAuthor
    Associate II
    March 4, 2015
    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
    Tesla DeLorean
    Guru
    March 4, 2015
    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Tesla DeLorean
    Tesla DeLorean
    Guru
    March 4, 2015
    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.
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Terms & ConditionsAccessibility statement