[SOLVED] External Loader not recognized by STM32CubeProgrammer

[svcguy]

Hello,

I'm hoping that someone out there can help me with the last bit of getting an external loader working for my custom board. I'm in the very early stages of developing, specifically at the whacking together dev boards for proof of concept stage. So anything can be changed at this point.

Ultimately my issue is that I've built an external loader that runs tested/verified QSPI flash routines, adpated that to the loader format (Loader_Src.c, Dev_info.c, etc) and built that using example linker scripts. For the life of me, I can't get CubeProgrammer to see the *.stldr. I can see the Dev_info object in the elf, as well as Init, Write, etc. Is there anyone out there that knows the specifics that CubeProgrammer is looking for?

Project specifics:

STM32CubeIDE 1.4.2

STM32CubeProgrammer 2.5.0

STM32F767IGT MCU

MT25QL512A QSPI Flash

I've attached a zip of the project and a copy of the .stldr

Thanks,

Andy

[svcguy]

Just noticed I have two linker scripts in the project. Project is currently configured to use Target.ld

[Tesla DeLorean · Accepted solution]

Finds and loads it here, from the ...\bin\ExternalLoader subdirectory.

Would recommend installing outside of ProgramFiles subdirectory so copying in is permitted.

[svcguy]

Thanks Clive! You’re the guy I hoped would find this thread.

Guess I should have been a little more verbose. I’ve copied the stldr to the ExternalLoader folder in my CubeProg install folder but it never appears in the list.

I’ll try moving cube prog to a different folder.

More specifically I’m asking what CubeProg needs to see in the stldr to consider it valid

[svcguy]

Wait a second! It loads it in your CubeProg install??? I’ve been building and rebuilding that thing dozens of times!

[svcguy]

Yup. Moving my STM32CubeProgrammer install fixed the problem! Clive, thank you sir! Did not expect that to be an issue...

[Tesla DeLorean]

Here, v2.4.0 as that's the version I've been using.

Some earlier versions had some weird requirement that the name of the file exactly matched the internal name, but no longer.

The "program files" directory is virtualized on a per-user basis, it is generally considered bad-form to copy things there due to virus/rootkit issues.

Select "verbosity level" of 3, and click one of the other existing loaders, and double check the pathing being used, and that it matches where the tool is loading from.

.ELF / .STLDR looks internally consistent, so not a build issue