ST Link External Loader Not Recognized

[cpaye]

Posted on December 01, 2017 at 21:00

Hello,

I am using the ST-Link utility, v4.0.0.  I created a custom external loader in IAR for ARM using one of the example projects.  After I build the loader in IAR I copy the .out file to ST Link's external loader folder and give it an STLDR extension.  However when I go to load the file through ST Link, the Device name is blank, the Device Type is 'Unknown Device, the Start address is 0 and the Device Size is 0.  I know that this information comes from the Dev_Inf file but since I just modified an existing project, I think this is all setup correctly.  I have built this both in IAR v7.3 and v7.8.  Any guidance would be appreciated.

Thanks.

#st-link-external-loader

[Tesla DeLorean]

Posted on December 01, 2017 at 21:42

You probably want to start by looking a the file with an ELF inspection tool to see what data sections and symbols are being exported. In Keil there is FromELF, not sure what the 'objdump' equivalent is in IAR

Compare to working loaders. The one I'm look at were built with V7.20.5.7591/W32

Current version of ST-LINK Utilities is V4.1.0, should try that so as not to fight old demons.

...

    616  AHBPrescTable              0x20001d7c   Gb    4  Data  De   0x10

    617  StorageInfo                0x20001d8c   Gb    5  Data  De   0xc8    618  Info_BLOCK$$Base           0x20001d8c   Gb    5   --   De

...

    AHBPrescTable

        0x20001d7c:    00000000    ....    DCD    0

        0x20001d80:    00000000    ....    DCD    0

        0x20001d84:    04030201    ....    DCD    67305985        0x20001d88:    09080706    ....    DCD    151521030    RAM_BLOCK$$Limit

** Section #5 'P2 ro' (SHT_PROGBITS) [SHF_ALLOC]

    Size   : 200 bytes (alignment 4)    Address: 0x20001d8c

    0x20001d8c:   49 53 36 31 57 56 31 30 32 34 31 36 42 4c 4c 5f    IS61WV102416BLL_

    0x20001d9c:   53 54 4d 33 32 34 78 47 2d 45 56 41 4c 00 00 00    STM324xG-EVAL...    0x20001dac:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001dbc:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001dcc:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001ddc:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001dec:   00 00 00 00 04 00 00 00 00 00 00 64 00 00 20 00    ...........d.. .    0x20001dfc:   00 00 20 00 ff 00 00 00 01 00 00 00 00 00 20 00    .. ........... .    0x20001e0c:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001e1c:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001e2c:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001e3c:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................    0x20001e4c:   00 00 00 00 00 00 00 00                            ........

    Info_BLOCK$$Limit

** Section #6 '.debug_abbrev' (SHT_PROGBITS)

    Size   : 1688 bytes

[cpaye]

Posted on December 01, 2017 at 22:24

I have upgraded to v4.1 and I am now using the map files to compare the one of the example projects with mine.  However, I did copy the .out file from the example I am examining to the ST Link External Loader folder and it too is showing up with an empty Device name, unknown device type, etc.  I did not re-build the example - I just took the .out file as-is, copied it and gave it the .stldr extension.

[cpaye]

Posted on December 02, 2017 at 01:33

IAR has a ELF dump utility that I used to dump the binaries. The main thing that stood out to me is that the known good loader had two program headers in it while my custom loader does not. I noticed that other good loaders also have that (both dumps are attached to this post).

I checked the map file for my loader and the addresses for the Storage Info and Info_Block$$Base were the same, like in the example you gave.

I'm still stymied on what may be wrong.

________________ Attachments : KnownGood.id.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxyG&d=%2Fa%2F0X0000000b5O%2FtOTzme9gTw2nBKYrMJ.M5mNwwCtHExC_I73Y9Zjqyhw&asPdf=falseCustomLoader.id.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyH2&d=%2Fa%2F0X0000000b5N%2FXP.6_BiG0jNPFj2etsDyLy04qjtir9j5ATn2RQ.UN2w&asPdf=false

[cpaye]

Posted on December 03, 2017 at 15:51

I think I found the issue.  I re-built my loader in IAR v7.3 and it was recognized by ST-Link.  I did the same with one of the examples and that worked as well.  (Originally I built my loader in IAR v7.8).  Is there something that could be tweaked to make the build work with IAR v7.8?  

Thanks.

[Tesla DeLorean]

Posted on December 03, 2017 at 18:06

Not using IAR here, and not sure how robust ST's ELF Loader is in reality, my opinion is that it is pulling symbols, but might also depend on section attributes.

If you want to send a working vs non-working variant to

mailto:sourcer32@gmail.com

I'll see if there is anything that might break or confuse the loader.

[cpaye]

Posted on December 05, 2017 at 16:11

Thanks Clive.  I can't provide my specific code but I can provide the ST example code built in v7.3 IAR and built in v7.8 (example code built in v7.8 had the same behavior as mine).  Which files would be the most helpful?  A copy of the .out and .map for each?

[Tesla DeLorean]

Posted on December 05, 2017 at 16:33

Output binaries from linker should suffice for a quick analysis.

[Tesla DeLorean]

Posted on December 06, 2017 at 03:36

The Linker with 7.8 is combining the code (RWX) section with the read only data (R) section holding the StorageInfo structure.

========================================================================

** ELF Header Information

    File Name: IAR_v7.8_N25Q256A_STM32L476G-EVAL.out

    Machine class: ELFCLASS32 (32-bit)

    Data encoding: ELFDATA2LSB (Little endian)

    Header version: EV_CURRENT (Current version)

    Operating System ABI: none

    ABI Version: 0

    File Type: ET_EXEC (Executable) (2)

    Machine: EM_ARM (ARM)

    Image Entry point: 0x2000057b

    Flags: EF_ARM_HASENTRY + EF_ARM_SYMSARESORTED + EF_ARM_MAPSYMSFIRST (0x05000016)

    ARM ELF revision: 5 (ABI version 2)

    Conforms to Base float procedure-call standard

    Header size: 52 bytes (0x34)

    Program header entry size: 32 bytes (0x20)

    Section header entry size: 40 bytes (0x28)

    Program header entries: 1

    Section header entries: 18

    Program header offset: 145448 (0x00023828)

    Section header offset: 145480 (0x00023848)

    Section header string table index: 1

========================================================================

** Program header &sharp0 (PT_LOAD) [PF_X + PF_W + PF_R]

    Size : 6456 bytes

    Virtual address: 0x20000004 (Alignment 4)

========================================================================

vs

========================================================================

** ELF Header Information

    File Name: IAR_v7.3_N25Q256A_STM32L476G-EVAL.out

 ========================================================================

** Program header &sharp0 (PT_LOAD) [PF_X + PF_W + PF_R]

    Size : 6236 bytes

    Virtual address: 0x20000004 (Alignment 4)

====================================

** Program header &sharp1 (PT_LOAD) [PF_R]

    Size : 200 bytes

    Virtual address: 0x20001860 (Alignment 4)

========================================================================

If I split the Program Header in two again the ST-LINK Utility loader then recognizes the StorageInfo structure