Menu ▾ ▴

#149 ST-Link Unsupported status code 0x09

0.9.0
closed
nobody
None
2018-11-30
2017-03-31
steve
No

Using STM32L031 Nucleo for detailed investigation, although suspect similar problem on STM32L050 Nucleo. Running ST-Link software 2J28M18 (latest as of now). OpenOCD release 0.10 final
Fails to connect to target.
Relevant debug output:

Debug: 256 47 stlink_usb.c:817 stlink_usb_init_mode(): MODE: 0x01
Debug: 257 47 stlink_usb.c:442 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x9
Error: 258 47 stlink_usb.c:1779 stlink_usb_open(): init mode failed (unable to connect to the target)

Looking in the source, this status code does not appear to be recognised at all - presumably recent addition.

I tried reducing clock speed from 300kHz to 100kHz without any difference.

Note: I can connect to the target using ST-Link.

Discussion

  • Paul Fertser

    Paul Fertser - 2017-03-31

    Hello,

    On Fri, Mar 31, 2017 at 11:44:33AM +0000, steve wrote:

    Debug: 256 47 stlink_usb.c:817 stlink_usb_init_mode(): MODE: 0x01
    Debug: 257 47 stlink_usb.c:442 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x9

    No idea what this might mean, it's not present in the information
    available to me.

    Note: I can connect to the target using ST-Link.

    Have you tried "reset_config connect_assert_srst" with OpenOCD?

    --
    Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
    mailto:fercerpav@gmail.com

     

  • Uwe Bonnes

    Uwe Bonnes - 2017-03-31

    Check with -v if there is some successfull communication with the device? I suspect not, perhaps the device is in deep sleep or openocd refuses to attach, as I have seen often with openocd.

    Otherwise some header file tells 0x09 = STLINK_JTAG_IDCODE_ERROR.

     

  • steve

    steve - 2017-03-31

    Uwe,
    I think the error code you've found is right, and should be added - I've been doing some more debugging, and am getting an ID code of zero returned.
    Will pursue your suggestion of 'deep sleep' - that could have happened in the course of messing around.
    I tried Paul's suggestion on reset, and that enabled me to connect sufficiently to get back the ID code, although it did give an error message! Error: BUG: can't assert SRST
    Will investigate further.

     

    • Paul Fertser

      Paul Fertser - 2017-03-31

      On Fri, Mar 31, 2017 at 02:45:31PM +0000, steve wrote:

      I tried Paul's suggestion on reset, and that enabled me to connect sufficiently
      to get back the ID code, although it did give an error message! Error: BUG:
      can't assert SRST

      Does it mean you use a board config that lacks "reset_config
      srst_only" when in fact this board has SRST properly connected?

      --
      Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
      mailto:fercerpav@gmail.com

       

  • Spencer Oliver

    Spencer Oliver - 2017-03-31

    Just had a scan through some docs that ST sent us ages ago and I have the following error codes listed.

    /* JTAG Status codes ---------------------------------------------------------*/
#define STLINK_JTAG_OK                  0x80  /* 0x80 in order to avoid API break */
#define STLINK_JTAG_UNKNOWN_ERROR       0x01
#define STLINK_JTAG_SPI_ERROR           0x02
#define STLINK_JTAG_DMA_ERROR           0x03
#define STLINK_JTAG_UNKNOWN_JTAG_CHAIN  0x04
#define STLINK_JTAG_NO_DEVICE_CONNECTED 0x05
#define STLINK_JTAG_INTERNAL_ERROR      0x06
#define STLINK_JTAG_CMD_WAIT            0x07
#define STLINK_JTAG_CMD_ERROR           0x08
#define STLINK_JTAG_GET_IDCODE_ERROR    0x09
#define STLINK_JTAG_ALIGNMENT_ERROR     0x0A
#define STLINK_JTAG_DBG_POWER_ERROR     0x0B
#define STLINK_JTAG_WRITE_ERROR         0x0C
#define STLINK_JTAG_WRITE_VERIF_ERROR   0x0D

#define STLINK_SWD_AP_WAIT              0x10
#define STLINK_SWD_AP_FAULT             0x11
#define STLINK_SWD_AP_ERROR             0x12
#define STLINK_SWD_AP_PARITY_ERROR      0x13
#define STLINK_SWD_DP_WAIT              0x14
#define STLINK_SWD_DP_FAULT             0x15
#define STLINK_SWD_DP_ERROR             0x16
#define STLINK_SWD_DP_PARITY_ERROR      0x17

#define STLINK_SWD_AP_WDATA_ERROR       0x18
#define STLINK_SWD_AP_STICKY_ERROR      0x19
#define STLINK_SWD_AP_STICKYORUN_ERROR  0x1A

#define STLINK_SWV_NOT_AVAILABLE        0x20 // New in ST-Link/V2
#define STLINK_NO_JUMP_TO_USB_LOADER    0x21 // New in ST-Link/V2, from V2J18S4

#define STLINK_JTAG_RUNNING             0x80
#define STLINK_JTAG_HALT                0x81


#define STLINK_JTAG_OLD_ERROR           0x81  /* 0x81 is the general error code of first API */
     

  • steve

    steve - 2017-03-31

    Thanks all for very prompt and helpful responses.
    I managed to use ST-Link to upload a known good program and everything burst into life - so looks like Uwe was right about some odd mode having been set.
    I used the stm32l0discovery.cfg file (unchanged, in the end), even though I was on a STM32L031 Nucleo-32 board.

    So in summary:
    a) Spencer's error code list looks worth comparing against current support - since at least code 0x09 isn't currently supported
    b) Maybe investigate why ST-Link can access the target when OpenOCD can't. One possible clue is that ST-Link says ' Debug in Low Power mode enabled.' when connecting.

     

  • steve

    steve - 2017-04-02

    Found the root cause of the inability to connect to the target; must have had brain in neutral when configuring the I/O, and had reassigned PA13/PA14 away from SWD function. The ST-Link software obviously manages to handle this - maybe connects soon enough after reset to prevent software execution on the target.
    [A further source of confusion was that the Nucleo uses ST-Link 2-1 transport, whereas my standalone ST-Link uses ST-Link 2 - is auto-identification a possibility?]

     

    • Paul Fertser

      Paul Fertser - 2017-04-02

      On Sun, Apr 02, 2017 at 11:47:26AM +0000, steve wrote:

      Found the root cause of the inability to connect to the target; must have had
      brain in neutral when configuring the I/O, and had reassigned PA13/PA14 away
      from SWD function.

      The most usual cause indeed.

      The ST-Link software obviously manages to handle this - maybe
      connects soon enough after reset to prevent software execution on
      the target.

      Most probably it uses the reset line and approach that's called
      connect_assert_srst in OpenOCD. Haven't you tried it yet?

      [A further source of confusion was that the Nucleo uses
      ST-Link 2-1 transport, whereas my standalone ST-Link uses ST-Link 2
      - is auto-identification a possibility?]

      Please see http://openocd.zylin.com/#/c/3961/ . I do not know why but
      this patch is not getting any traction. Feel free to add you review.

      --
      Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
      mailto:fercerpav@gmail.com

       

  • pierre

    pierre - 2018-10-10

    Hello,

    I've the same error on STM8s001J3 which have no reset pin.
    do i need to set some config to explain openocd that the mcu don't have reset pin ?
    how to check that frequency is correct ? between target and openocd config ?

    i'm sure that ST-link v2 is doing well and MCU too.

    [...] MODE: 0x01
    [...] stlink_usb.c:442 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x9
    [...]

    don't know where to look for this error. what is this "init" refers to? (rephrased : "init" of what ?)

    thanks in advance.

     

  • Spencer Oliver

    Spencer Oliver - 2018-11-30
    • status: new --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB