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

[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

[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