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

[Amel NASRI]

Posted on March 30, 2016 at 12:02

Hi cupery.e._nicholas,

You should be able to erase the flash content using the STLink Utility.

Try to do it first.

-Mayla-

PS: There is no demonstration provided for STM32F410 Nucleo board in Cube package.

[nickcupery]

Posted on March 30, 2016 at 12:46

  The ST-Link Utility erased the flash content just fine, which

was why (after saying ''whoops'' to myself) I went looking for the

demo program to reload it.  When I found that the demo program

is not available to reload, I filed that STM Support Ticket.

The tech support guy said the demo code will be posted soon.

 - eNick

[nickcupery]

Posted on April 04, 2016 at 15:34

For about a week now, I have been experiencing and reporting

problems with the relatively new STM32F410 chip from ST Micro.

I've been trying to load a new VisualGDB project into a new

circuit board of my own design, with no joy.  When I tell

VisualGDB to just load the program into the chip, VisualGDB

says that it has successfully loaded the program but is unable

to start the program so I should reset the chip manually.  If

I tell VisualGDB to load the program in Debug mode, VisualGDB

says that the stack at address 0x2000F770 is not writable and

simply halts.

I can now report that there is no problem with my circuit

board, and probably nothing wrong with VisualGDB.  STM's own

ST-Link Utility (STLU) doesn't like my circuit board either,

and STLU also DOES NOT WORK CORRECTLY with STM's own Nucleo

F410RB circuit board.

The behavior of STLU with the Nucleo F410RB is a bit insidious

in that it APPEARS to work okay.  STLU will (usually) connect

to the board, will always ''successfully'' erase the chip, and

always APPEAR to reprogram the chip.  However, it turns out

that THE OLD PROGRAM IS STILL IN THE CHIP -- even after an

erase.  The ONLY thing that will get the new program loaded

is a termination/restart of of the STLU program.  Note that

simply unplugging/replugging the USB cable does NOT fix this

problem.

Note that there are two additional clues concerning the STLU

behavior:

 1) STLU will sometimes crash when trying to ''connect'' to the

chip after an STLU termination/restart.  (This might just be

a non-ideality in the USB interface.)  I cannot provide a

snapshot of the connect crash details, because the error

MessageBox is one of those stupid ''fancy'' jobbies with a

scrollbar and most of the details scrolled out of sight.

 2) STLU, upon successful connect, reports the chip as an

STM32F410xx Rev A with Device ID 0x458, but says that the

flash size is ''unknown''.  Suspicious, methinks.

There are also a couple of clues provided by VisualGDB:

 1) My program runs just fine in both my own circuit board and

in the Nucleo F410RB, after I do Reset the chip after loading

it with VisualGDB.

 2) My program DOES NOT USE ANY SRAM.  None at all.  I suspect

that VisualGDB's complaint about non-writable SRAM in Debug

mode has some merit.

It is clear to me that ST Micro has some problem with the

F410 (and/or STLU), and I recommend that others join me in

avoiding that chip until an explanation is provided.  I have

asked STM to provide the actual demo program that comes with

the Nucleo F410RB board, but I haven't seen it yet.  

- eNick

[Radosław]

Posted on April 04, 2016 at 15:44

>> 2) My program DOES NOT USE ANY SRAM.  None at all.  I suspect

that VisualGDB's complaint about non-writable SRAM in Debug

mode has some merit.

Brave assumption.

Visual GDB, is strange think.  Why you are using this strange IDE?

With STLU, I confirm that from some time this program likes to crash.

But this is very good tool. I never have problems with STLU. 

Did you set correct reset option?

[Tesla DeLorean]

Posted on April 04, 2016 at 17:51

I've always found the ST-LINK stuff to be quite serviceable, it doesn't have the robustness and polish of more commercial solutions (ie where the company's business is making debuggers/pods), but it does the job, and has minimal cost.

Does it crash or have problems occasionally, yes, but often when you are debugging something that is ''broken'', you're going to encounter a lot of conditions and states that are hard to replicate or address, or are simply new issues. I have J-Link and U-Link pods that also snarl up occasionally. You kick the hardware, and try again.

Perhaps there are issues with the F410, I'd expect ST to release updates when it suits them, to address those. I've encountered plenty of tool chains, including linkers, over the years that can make an awful mess of object and executable file output. The quickest way to get these fixed is to present a clear case, and analysis of the file, structure, and settings, that illustrate to the developer of the tools where the issue actually is, and how to replicate it easily. It works a lot better than describing vague maladies, and symptoms.

[TarekB-ST]

Posted on April 05, 2016 at 11:58

Hi cupery.e._nicholas,

>> (1) The behavior of STLU with the NucleoF410RB is a bit insidious

in that it APPEARS to work okay. STLU will (usually) connect

to the board, will always ''successfully'' erase the chip,and

always APPEAR to reprogram the chip. However, it turns out

that THE OLD PROGRAM IS STILL IN THE CHIP -- even after an

erase. The ONLY thing that will get the new program loaded

is a termination/restart of of the STLU program. Note that

simply unplugging/replugging the USB cable does NOT fix this

problem.

>>(2) STLU, upon successful connect, reports the chip as an

STM32F410xx Rev A with Device ID0x458, but says that the

flash size is ''unknown''. Suspicious,methinks.

These two issues has been reported internally.

>> My program runs just fine in both my own circuit board and

in the Nucleo F410RB, after I do Reset the chip after loading

it with VisualGDB.

This means that your linker is correct !

I have tried toreproduce the issue, and my first observation is that vGDB uses the default openocd script:target/stm32f4x.cfg

In which the _WORKAREASIZE isset to 64kb (greater than your ram = 32K).

which explains why :

>> VisualGDB says that the stack at address 0x2000F770 is not writable and simply halts.

=> to fix the issue you have to use a customized board (use the attached file)

VisualGDB Project Properties > Debug settings > Debug method = OpenOCD > Manual setup

Uncheck Interface and Target checkboxes

Check Board checkbox then browse for board cfg, the file chooser will open the following directory:

C:\Users\<username>\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts\board

paste here the attached file and use it as board config

>> My program DOES NOT USE ANYSRAM. None at all. I suspect

that VisualGDB's complaint about non-writable SRAM in Debug

mode has some merit.

You stack is placed in the device ram (=SRAM), and OpenOCD uses the device SRAM as buffer when programming the device flash.

Best Regards,

Tarek BOUCHKATI

________________

Attachments :

nucleo_f410rb.cfg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0gP&d=%2Fa%2F0X0000000bd4%2FA.2tJf4R68Rw4YbtFhHJjSo61PwyjWdAAKB1MsnJFtI&asPdf=false

[nickcupery]

Posted on April 05, 2016 at 13:40

VisualGDB is anything BUT a ''strange'' IDE.  It is the most common IDE on the planet Earth because it is the Visual Studio IDE.  VS is the only IDE I use (I usually write with

editor/assembler/linker), so I was very happy to see VisualGDB come along.  I find that

VisualGDB works GREAT on chips other than the STM32F410.

 - eNick

[nickcupery]

Posted on April 05, 2016 at 13:57

  Clive, there was nothing vague about my description of the

symptoms, and I'm sticking to my claim that there are ''issues

with the F410''.  I promise to change my story if I am proven

wrong. :)

  I agree with you that the ST-Link Utility is perfectly

acceptable, and I certainly don't expect perfection in a

freebie tool.  The truth is that I consider STLU to be

ABSOLUTELY SUPERB when I compare it to the Atmel junk.

I came to ST Micro just recently because I finally could

not STAND the Atmel tools.  (To simply set the fuses in an

XMega, Atmel wanted me to use their new ''Atmel Studio''.  So

I downloaded it and found that I had added 1.3 GIGABYTES to

my system, and it took more than ten seconds to launch the

program, and it was incomprehensible anyway. Worst of all,

it added a large PIECE of Visual Studio 2010 to my system,

which I did NOT want.  Atmel dug their own grave, in my

opinion.)

 - eNick

[nickcupery]

Posted on April 05, 2016 at 14:23

  Wow Tarek, it looks like Christmas! :)  I assume everyone

else is seeing your message in red and green, so I'll just

say Happy Holiday to everyone!

  Anyway, I agree that you are probably right about some

small problem with OpenOCD causing VisualGDB grief.  That is

why I switched to investigating the problem with STM's own

ST-Link Utility.

  Concerning the SRAM, I am not using any.  None at all.

No stack.  If ya avoid the STM bloatware, it only takes

a dozen or so lines of code to fire up one of these M4 chips.

A couple of lines to power up some GPIO port clocks, a couple

of lines to set some GPIOs as push-pull outputs, a single

line of code to set a pull-up on a user pushbutton, and a few

lines of code dedicated to turning an LED ON/OFF based on

input from the pushbutton.  All code, no stack, no SRAM.

  I don't really expect to find that there is any problem

with SRAM on the F410 -- that would never have made it to

the production line.  I expect that any perceived SRAM

problem with the F410 will simply disappear when STM figures

out what is preventing my ST-Link Utility from operating as

expected.

 - eNick

[Tesla DeLorean]

Posted on April 05, 2016 at 18:32

Concerning the SRAM, I am not using any.  None at all. No stack.  If ya avoid the STM bloatware, it only takes a dozen or so lines of code to fire up one of these M4 chips.

Indeed, but the processor still expects you to set a valid stack address, and when things fault or interrupt, it is going to use that. You can write things that don't use RAM, but it is highly atypical.

I'm seeing a lot of prose, and astro-turfing, perhaps you can just attach a project and the output files, and why it is failing to load on the F410 might be more apparent, and reproducible. I don't have hours to wade through your issues, condense it to something that can be digested in 5 mins or less. I don't have any F410, not using it in any project, people can send boards.

That something works with everything else, likely means the settings, defaults or assumptions, in this case fall over. If the parts were gravely flawed we'd be seeing a lot more blow-back, and we are not.