[SOLVED] Can't successfully program STM32 board with HEX file generated in Segger Embedded Studio 6.32

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

  • [SOLVED] Can't successfully program STM32 board with HEX file generated in Segger Embedded Studio 6.32

    Not sure if this needs to be in the SES or J-Link forums since it isn't clear what part of the process is failing.

    Using SES 6.32 I am creating an application for the STM32L062K8U6 on a custom PCB. I have code that works correctly when I do "Build->Build and Run". The output window says that it is downloading the ELF file, which is 57kb. In the project options Common->Linker setting I have the HEX file enabled as an additional output. In contrast to the 57kb ELF file the HEX file is 5kb which is an immediate cause for suspicion. When I select this file as the source for both J-Flash and J-Flash Lite the tool says it programs the device, but the code is clearly not executing correctly (as an aside, I don't understand why Segger's own tool won't use their own ELF format). It is not clear what part of this process I can troubleshoot. I have tried generating HEX, BIN, and SREC, none work.

    In the SES options, there is the "Additional Output File Gap Fill Value" field, but when I pick one of the macros for that the HEX file is still 5kb. When selecting the STM32L062K8U6 as the device to be programmed in the J-Flash utilities, there is an "allow extra optional bytes" version, and there is a choice of picking "big endian" or "little endian", but it is also not clear how I would verify which of these options would be correct, if I'm picking the wrong ones (I leave these at default).
  • Hi,
    Thank you for your inquiry.

    Eqqman wrote:

    as an aside, I don't understand why Segger's own tool won't use their own ELF format
    I do not understand what you mean with "own ELF format".
    The Executable and Linkable Format (ELF) is a standardized format for executable files.
    en.wikipedia.org/wiki/Executable_and_Linkable_Format ELF

    There are many IDEs/Toolchains that use this format as it provides a good way to integrate debug information via the DWARF standard.
    Why reinvent the wheel when you can simply use a proven and accomplished format?

    Eqqman wrote:

    In contrast to the 57kb ELF file the HEX file is 5kb which is an immediate cause for suspicion.
    Can you explain why you think this is a cause for suspicion?
    As the ELF-File created contains a lot of debug information, it is expected that the hex file, which only contains data and address information is much, much smaller.
    57KB vs 5KB looks very reasonable.

    I am absolutely confident that the .hex file is exactly what is flashed to the target via the IDE.
    You can verify this by comparing the flash content (read back), or via the VerifyBin command of the J-Link Commander:
    wiki.segger.com/J-Link_Commander#VerifyBin

    Eqqman wrote:

    When I select this file as the source for both J-Flash and J-Flash Lite the tool says it programs the device, but the code is clearly not executing correctly
    The two most common reasons for this are:
    1) The application is not reset after flashing the application. This can be solved by either issuing a reset or power-cycling the device.
    If this does not work it is usually (2).
    2) IDEs do much more besides downloading an application.
    The standard and expected behavior is that they reset the device after download and set PC and SP to the expected values of the application entry.

    This means, that
    - application bootloaders might be skipped
    - the application might start even in the wrong boot mode
    - the application might start even when the CPU thinks that it is not valid.

    You can check if your setup is correct by doing the following:
    a) Start a debug session with the IDE (this will download the application and run the program).
    b) Stop the debug session and power cycle the device.
    If the application does not start after power-cycle, your device is either
    - not configured correctly (e.g. boot mode) or
    - the flashed image lacks some requirements.
    For example, some devices expect a valid boot header as part of the image in flash and will not boot unless it is deemed valid.

    Could you please check this?

    BR
    Fabian
    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.
  • Hi,
    I am sorry if my words are raising a condescending impression.
    It was not meant that way and I will try to prevent this from happening in my future messages.

    BR
    Fabian
    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.
  • Further review indicates that I failed to have the STM32L0 BOOT0 pin wired correctly on the board. With this grounded out (== boot from flash) the code executed correctly after using the "no option byte" HEX file generated by SES and programmed with J-Flash Lite. This issue can be marked as closed/solved.
  • Hi,
    Good to hear that you are up and running again.

    BR
    Fabian
    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.