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 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.

[Radosław]

Posted on April 05, 2016 at 18:41

>>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.

Any function is enough to use stack

[Tesla DeLorean]

Posted on April 05, 2016 at 19:03

Any function is enough to use stack

Single depth call does not.

[nickcupery]

Posted on April 06, 2016 at 13:19

>the processor still expects you to set a valid stack address,

>and when things fault or interrupt, it is going to use that.   My test program has a pefectly valid stack address at the beginning of the interrupt vector table, right where it belongs. I have an LED that gets lit up by the default interrupt handler if ANY interrupt or fault occurs.  None occurs. >You can write things that don't use RAM, but it is highly atypical   Atypical and then some!  This is a test program, Clive. :) It is carefully contrived to NOT use any SRAM.  No stack.  No functions.  Code only, and little of it, in flash.   If I could figure out how to attach code and screen snapshots using this demented forum software, I would do so and also award myself a PhD in foreign languages.     Please remember that I have moved beyond asking ''why doesn't my test program work'', to asking ''why doesn't ST-Link Utility correctly load my program''.  The problem doesn't really have anything to do with my program itself.  When I *FORCE* STLU to load my program (by terminating/restarting STLU, as stated in my previous message) my program works just fine.   I don't really expect to find that there is some fundamental ''show stopper'' of a problem with the F410.  Rather, I expect that it will turn out that there is ''something about the chip'' that requires a modification to VisualGDB/OpenOCD and also to the ST-Link Utility.  (BTW, according to STM Support, the latest version of STLU exists BECAUSE of a required modification for the F410.  I think STLU requires an ADDITIONAL modification, which will need to be propagated to VisualGDB/OpenOCD.)   Apparently, I am the ONLY guy on Earth who has tried to use the F410.  The only one who is willing to talk about it, anyway. There are probably a few who have discovered the required workaround and just kept quiet about it.   I should mention that I am very pleased with the STM Tech Support folks.  They respond to my problem report ''tickets'' quickly and in reasonable depth.  They are looking at this problem right now.  The only thing about STM tech support that bothers me is that THEIR (apparently separate) forum software is FAR MORE DEMENTED than what we are dealing with here.  I have very little confidence that they are seeing all the stuff I send them.  All efforts to have them simply call me on the phone have so far failed.  Still, compared to Atmel, ST Micro is Tech Support Heaven.  - eNick