STM32F410 Elf Loader Problem

[nickcupery]

Posted on March 19, 2016 at 15:23

  I have a brand-new project (with brand-new circuit board) based

on the STM32F410CBT6 chip.  This chip, which I think is relatively

new, supposedly has 128KB of FLASH and 32KB of SRAM.  However, the

default linker script provided by STM incorrectly says the FLASH

is 64KB.  So, I corrected the linker script and I will (try to)

attach a copy.

  Like all of my STM projects, this is a VisualGDB project (and

VisualGDB is the best thing since sliced bread).  Thus, I first

noticed my STM32F410 problem when I tried to load/debug the new

program with VisualGDB.  VisualGDB claims the stack address

0x20007FFC is not writable, yet the data sheet (and the linker

script) say that address is perfectly legal.  When I tried a

much lower value for _estack, I got the same failure but with

the new supposedly illegal address correctly indicated in the

error message.

  So I then tried to load my new program with STM's ST-Link

Utility program.  No joy!  ST-Link Utility connects to the

device and correctly identifies it as an STM32F410xx Rev A,

but when I try to ''erase chip'' I get a MessageBox saying that

''the elf loader is bigger than the RAM size''.  When I explicitly

tell ST-Link Utility to examine SRAM memory addresses, it does

successfully access the addresses from 0x20000000 to 0x20007FFC,

and then fails at 0x20008000 as expected.  Hmmm.  So, how big

is this ''elf loader'' anyway?  Does anyone know?  I don't really

know anything about elf loaders, but I've written a few ''loaders''

in my day and they are all just a coupla hundred bytes of tightly

coded assembly language -- certainly nothing approaching 32KB!

  Ideas?  Note that I've run this problem by the VisualGDB folks

(who provide TOP QUALITY tech support), and they haven't seen

this one before.

  Maybe I've purchased a load of Rev A chips that don't work?  

I'm not fond of that answer. :)

- eNick

#tl

[Tesla DeLorean]

Posted on March 19, 2016 at 20:04

I don't see any attachments, the .ELF and .MAP would be of interest.

I wasn't aware the ST-LINK Utilities handled .ELF/.AXF, I thought they only did .HEX and .BIN

Try creating a .HEX and seeing what that looks like.

[nickcupery]

Posted on March 20, 2016 at 13:36

Hello, Clive1.  Thanks for the quick response.

The ST-Link Utility (STLU) program does not, in fact, deal in

.ELF files.  I was trying to get it to load a .BIN version of

my project.  (I have VisualGDB set to generate both a .ELF and

a .BIN for everything.)  When STLU generated that MessageBox

saying ''The elf loader is bigger than the RAM size'', it was

trying to load the .BIN not the .ELF.  My conclusion: the error

message has little or nothing to do with the actual error.

Also, please remember that I got the same error message from

STLU when I told it to ''erase chip'' -- which would/should have

nothing to do with my project at all.

Note that VisualGDB DOES successfully load my project; it just

cannot RUN the loaded image under the debugger.  In case you

are not familiar with VisualGDB, let me just mention that we

are talking about VisualGDB conning Visual Studio into invoking

the GDB debugger from the GNU ARM toolchain to talk to the

on-chip hardware debugger that is part of the ARM Cortex M4

specification.  Thus, it appears that it is the on-chip hardware

debugger that does not like the chip!  Yeah, hard to believe...

You didn't see any attachments to my message because I have yet

to figure out this, um, enigmatic forum software.  (Someone less

charitable than I might have said ''demented''.)  I did try to

attach some evidence, but the message got posted before I came

close to figuring out how to attach anything.  

Meanwhile, I think the thing to dwell on here is the fact that

STM's own ST-Link Utility doesn't like STM's own STM32F410 chip,

and won't even erase it, and issues an insane error message when

it tries.  Something seems rotten in STMland.

Note that I first suspected an error (on my part) concerning

BOOT0, but I have checked that carefully (and I now don't even

think BOOT0 could cause this problem anyway).  Let me explicitly

state that I have BOOT0 on my STM32F410CBT6 connected to ground

through a 1k resistor.

At this point, I would very much like to see someone, anyone,

inform me that he has successfully incorporated an STM32F410CB

into a working project.

eNick

[Tesla DeLorean]

Posted on March 20, 2016 at 15:01

Unfortunately no one has provided me with any F410 boards.

[nickcupery]

Posted on March 24, 2016 at 11:33

  It turns out STM has made a new one of those ''Nucleo'' boards

that incorporates the F410, and I have ordered one that should

arrive tomorrow (Friday 25Mar16).  I should learn something

from that.

  I haven't been ignoring you for four days, Clive.  When you

added that 4th post to this thread on 20Mar16, this insane

forum software neglected to bump the post-count from 3 to four.

Whan I post a new message, I am semi-religious about checking

for developments several times per day, but I have been relying

on the thread post-count (which apparently doesn't work around

here).

  Speaking of insane STM forum software, yesterday I also posted

an official request for tech support on this issue in the

Support section of the official STM website.  That software

issued me a Ticket Number (TECH17108), then briefly flashed a

message saying my issue already appears 16 times in their

Knowledge Base, and then thoroughly resisted all my attempts

to look at that issue (or any other issue) in the KB.  This

morning, I logged into the official website Support forum again

and could not find any reference to my TECH17108 ticket at all.

(I also tried again, and failed, to see ANYTHING in the STM

Knowledge Base.)  I can't even figure out if THAT forum is the

same forum as THIS forum, which would imply that the STM forum

is somehow ''My'' STM forum.

  In a couple of hours, the STM Tech Support telephone hours

will start, and I will call them again, this time with a

Ticket Number.  If I ever get a cogent answer, I will post it

here.

 - eNick

[Tesla DeLorean]

Posted on March 24, 2016 at 11:58

I think the forum software and search here are universally hated.

I don't hang on responses, but rather bat at what is currently being pitched. The user base tends to be transitory.

[nickcupery]

Posted on March 25, 2016 at 13:06

  Okay, here's the latest.  It turns out that there are several

problems in the default STM32F410 linker script, AND the very

latest v3.8 of the ST-Link Utility (STLU) is required for the

F410. The STLU does not automatically check for updates, so it's

best to check every three minutes. :)  

  The new v3.8 STLU seems to work fine with my new custom circuit

board, but VisualGDB does not.  The VisualGDB folks are now

looking into this.  They told me I am their first known customer

to work with the F410.  I am the pioneer with the arrows in my

back!

  I received my STM32F410RB Nucleo board yesterday, and STLU

seems to like it just fine.  However, I managed to brick it

during my testing, and it appears that there is no way (yet)

to get the demo software program that came already loaded.

(There is also no schematic available yet, far as I can tell.)

BOTTOM LINE:  It appears that there is nothing wrong with the

Rev A F410 chips, and I am happy to wait for the VisualGDB guys

to weigh in.

[TarekB-ST]

Posted on March 25, 2016 at 18:01

Hello eNick,

Glad to hear that the latest version of STLU proves that there is no issues with your F410 revA chips.

Concerning VisualGDB (vGDB): I think that this problem is not related to vGDB it self.

Because vGDB relies on openOCD to program STM32 chips.

So I can say that this issue is absolutely related to openOCD maintained by its own community.

But I think that vGDB does not include the latest version of openOCD (I'm not that sure).

If yes : your problem could be solved using the latest one,

which you can download it from Freddie Chopin's website (latest release is 0.9).

Best Regards,

Tarek BOUCHKATI

[Amel NASRI]

Posted on March 25, 2016 at 18:06

Hi cupery.e._nicholas,

There is also no schematic available yet, far as I can tell.

==> Please note that the schematic of the STM32F410 Nucleo board is available in the

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00105823.pdf

(STM32 Nucleo-64 boards).

 It turns out that there are several problems in the default STM32F410 linker script

==> Could you please precise the example where the linker file is wrong?

-Mayla-

[nickcupery]

Posted on March 29, 2016 at 23:18

  Hello Tarek.  I share your suspicion that there is something

not quite right about my version of OpenOCD.  However, I am

deferring that investigation until I get my custom F410 program

to behave better.  It still doesn't work as I expect, even when

loaded into the STM Nucleo F410RB board by STM's own ST-Link

Utility.  I have opened a support ticket complaining that the

Nucleo F410RB demo program is missing from the STM website, and

STM has responded that the program will be posted soon.  I want

to see exactly what it does at startup.  Please stay tuned.

 - eNick

[nickcupery]

Posted on March 29, 2016 at 23:21

  Hello Mayla.  Yeah, I found that schematic right after posting

that message.  I had not recognized it when I first read that

App Note, because it never occurred to me that ALL the Nucleo

boards with LQFP-64 chips could/would have the SAME schematic!

The same, that is, given the liberal use of enough ''SB''s (which

I assume are Solder Bridges) to confuse even the world chess

champion. :)  Sheesh.   Anyway, I want the demo program source

code more than I want the schematic, and STM says it's ''coming

soon''.

  I probably should not have said that the default linker

script had errors, because I'm not really sure that the one I

found is actually STM's ''default'' script.  The ''errors'' that

I found were just that the script said the chip has 64KB of

FLASH when it really has 128KB (which probably would have

worked fine), and that it claimed the interrupt vectors were

in SRAM instead of in the FLASH.  (I doubt that the F410 demo

program copies the vectors to SRAM, but, of course, I cannot

tell until I see the source code.)

 - eNick