[SOLVED] SES debug pod support

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] SES debug pod support

    I understood that SES basically supports only the J-Link debugger, which is ok for.
    Though I have some questions related to J-Link conversion firmware for other debug pods.

    The ICDI (from TI, e.g. used on their Launchpad boards) is not and probably will not be supported, right ?

    There is such a conversion J-Link firmware for the LPC-Link2. I suppose it does not support the older version, called "LPC-Link".

    And thirdly, I successfully converted several ST-Links on STM32 discovery boards to J-Links.
    But does this firmware support the standalone version of the ST-Link (which also supports both JTAG and SWD, and SWIM) ?
    Since this standalone version has some additional features (JTAG, SWIM), I am hesitant to experiment.


    Finally a feature I wish SES had.
    When creating a new project, the default folder is always the user directory (e.g. under Windows "C:/Users/<user>/Documents/SEGGER Embedded Studio for ARM Projects").
    Not the best choice IMHO, but a good one to start with.
    However, project creation dialogs of other IDEs remember that last used directory, as do many other PC applications.
    It would be nice if SES had this as well.

  • Hello,

    Thank you for your inquiry.

    _frank_ wrote:

    The ICDI (from TI, e.g. used on their Launchpad boards) is not and probably will not be supported, right ?
    Not supported. Correct.

    _frank_ wrote:

    There is such a conversion J-Link firmware for the LPC-Link2. I suppose it does not support the older version, called "LPC-Link".
    Correct. Only LPC-Link2 is supported:
    segger.com/products/debug-prob…other-j-links/lpc-link-2/

    _frank_ wrote:

    But does this firmware support the standalone version of the ST-Link (which also supports both JTAG and SWD, and SWIM) ?
    You can use the GDB interface of Embedded Studio.
    You can enable it as follows:
    - Set Debug > Debugger > Target Connection > GDB Server
    - Set Debug > GDB Server > Type to the GDB Server type you are looking to use, in this case ST-Link

    - Edit the option Debug > GDB Server > GDB Server Command Line accordingly to start the ST-Link. For this and the other ST GDB Server setting we recommend to check out ST documentation.


    But SWIM will not be supported as it is a STM8 specific feature which is not supported in Embedded Studio.



    Generally we recommend to use a J-Link where possible as this will give you the best debug experience in Embedded Studio overall.

    As you mentioned there are plenty of reflash tools for different third party debuggers so most eval boards out there you should be able to reflash to a J-Link and use all its features and advantages natively.




    _frank_ wrote:

    Finally a feature I wish SES had.
    When creating a new project, the default folder is always the user directory (e.g. under Windows "C:/Users/<user>/Documents/SEGGER Embedded Studio for ARM Projects").
    You can change the default new project folder under: Tools->Options->New Project Directory

    Currently there are no plans to change the behaviour of the project generator in that regard.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Thanks for the quick response.

    And to respond in reverse order ...

    > You can change the default new project folder under: Tools->Options->New Project Directory
    This is exactly what I needed.
    I overlooked this property until now - but to my defense, the number of setting items is a bit overwhelming ...

    For the standalone ST-Link, it sounds as I can write it off now.
    I'm using mostly Linux, and I suppose you mean a GDB server from ST, which needs to match the host OS.
    While ST's Cube IDE somewhat supports Linux, I am not sure if I want to go through the hassle - to say the least.
    While IMHO their silicon is great, their IDE and Cube libraries ... suck. And their support of non-Windows OSs even more.
    My personal opinion.

    My point is, I have several older board around (LPC14xx, LPC17xx, FRDM-64F, Stellaris Launchpad, Same70 Xplained), with MCUs which are still in production.
    Though I have no intention to install another 1GB+ IDE for each of them, just for the debug pod support.

    It seems I need to go the other route - disable the onboard pods on this boards, and use one of the converted ST-Link / JLink pods broken off from an eval board. And make the adapter cables.

  • Hello,

    _frank_ wrote:

    This is exactly what I needed.
    I overlooked this property until now - but to my defense, the number of setting items is a bit overwhelming ...
    Great to hear. Yes the number of options is quite something on Embedded Studio :D

    _frank_ wrote:

    I'm using mostly Linux, and I suppose you mean a GDB server from ST, which needs to match the host OS.
    While ST's Cube IDE somewhat supports Linux, I am not sure if I want to go through the hassle - to say the least.
    While IMHO their silicon is great, their IDE and Cube libraries ... suck. And their support of non-Windows OSs even more.
    Completely understandable. We will add native support to our wishlist but no promises.


    _frank_ wrote:

    My point is, I have several older board around (LPC14xx, LPC17xx, FRDM-64F, Stellaris Launchpad, Same70 Xplained), with MCUs which are still in production.
    Though I have no intention to install another 1GB+ IDE for each of them, just for the debug pod support.
    You could try openOCD/pyOCD. Both support a big variety of different debug probes and can be used in Embedded Studio via the universal GDB interface.
    It might not have all debug features then but the basics should be there.
    But where possible we recommend to reflash the debug probes to J-Link where available. Just make sure that you familiarize yourself with the license conditions for each port. As some allow breakout boards and some not.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • > Completely understandable. We will add native support to our wishlist but no promises.
    > You could try openOCD/pyOCD. Both support a big variety of different debug probes and can be used in Embedded Studio via the universal GDB interface.
    > It might not have all debug features then but the basics should be there.


    To be honest, I didn't even try that route (GDB-Server) yet.
    If I understood this correct you mean the Segger GDB server which supports openOCD/pyOCD debuggers. And one of the named debug probes re-flashed with openOCD/pyOCD firmware.
    I had thought about getting the ST GDB server, copying it to the host, and pointing the debugger to it.
    The ST toolchain is free, I wouldn't expect any licence problem there.
    I remember doing something similiar with the Crossworks toolchain, pointing ST-Link pod settings (under Linux) to a Windows driver DLL - Rowley had explicitly documented it that way.

    > Just make sure that you familiarize yourself with the license conditions for each port. As some allow breakout boards and some not.

    I'm looking into it.
    Some boards like the ST Nucleo are pre-cut for easy break-off, so I assumed it is not illegal ...

  • Hello,

    _frank_ wrote:

    If I understood this correct you mean the Segger GDB server which supports openOCD/pyOCD debuggers.
    No. In this context Embedded Studio is the GDB Client. The GDB Server is from openOCD or pyOCD. We have a universal GDB Client interface in ES, so you can technically hook up any debug probe that has a GDB Server to it.

    The J-Link GDB Server on the other hand is its own piece of software and has nothing to do with ES. It is simply our GDB Server that we ship with J-Link so J-Link can be used in third party IDEs that support the GDB interface (where the IDE is the GDB Client), otherwise every IDE would need to add J-Link support natively via our J-Link SDK. But that is of course not needed for ES where we added native J-Link support.

    _frank_ wrote:

    And one of the named debug probes re-flashed with openOCD/pyOCD firmware.
    That is correct. Although IIRC it is not a FW reflash, but you replace your host USB driver which openOCD will use to send JTAG/SWD signals directly via the probe. That way it is very universally usable but also very very slow compared to the native implementations of the debug probes.


    _frank_ wrote:

    I had thought about getting the ST GDB server, copying it to the host, and pointing the debugger to it.
    Yes that would be the approach if you want to use ST-Link via the ST GDB Server in Embedded Studio.


    _frank_ wrote:

    I'm looking into it.
    Some boards like the ST Nucleo are pre-cut for easy break-off, so I assumed it is not illegal ...
    Depends on your setup. If you use the ST-Link FW it might be legal. I recommend to check with ST in that regard.
    If you reflash it to a J-Link there are restrictions:
    segger.com/products/debug-prob…nk-on-board/#terms-of-use

    That is why I wrote to check the corresponding license conditions as not in all cases breakout boards would be allowed for custom hardware. It depends on the license deal that was set up with the corresponding board/silicon manufacturer and SEGGER.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Reading up on openOCD and GDB, I (hopefully) understand that point a bit better.
    Up to now, I usually preferred native support within the IDE/Debugger, or readily configured GDB server setups (like the one's Eclipse-based IDEs come with).

    And checking my revived old hardware, the results were not exactly encouraging.
    The standalone ST-Link is V.1, i.e. the broken USB driver implementation by ST.
    While I managed to find a LPC-Link2 and successfully converted it, the JLink "disappears" as soon as I connect the target.
    There seems to be some hardware issues.

    SEGGER - Nino wrote:

    If you use the ST-Link FW it might be legal. I recommend to check with ST in that regard.
    If you reflash it to a J-Link there are restrictions:
    segger.com/products/debug-prob…nk-on-board/#terms-of-use
    I will keep that in mind.


    Thank you again, I think my questions are answered so far.
    Frank