I'm interested in getting the layout of the flash program memory for the STM32 F411RE microcontroller. I gather that an mbed compile and load does no more than generate a binary file and copy it to the ST board. I've done a bit of poking around the binary file produced by the Mbed compiler, and I also note that the binary file seems to be loaded verbatim into the flash memory code space.

My end game is to program in Pascal using MikroE tools. I have a program that compiles and produces a binary file, but it doesn't successfully run after loading into the ST board. I can see that the binary file is different in the first few bytes, and I think that the fifth byte is some sort of configuration byte for the particular micro variant. The next 380 bytes or so are some sort of vector table and then the code proper starts.

But these are all guesses. Is it documented somewhere?

I realise that what I'm asking is partly ST stuff, but their memory map for the device doesn't break it down any further than "512k bytes of code memory". I figure more people who are likely to know are looking at this forum.

(Migrated from the "Questions" section)

The reference manual of the F411 will have some information, together with ARM site. I know for Freescale devices the interrupt vectors (including reset vector) is at the beginning of the flash.

All ARM architecture will have the same reset startup. You need to take a look at the ARM manuals as well as the programming manuals available off the ST website. You can replace the online mbed lib with mbed-src and examine the actual code that is linked in for the specific platform. Post back if you are still having trouble with this.

Thanks for the reply, Bill. I found the mbed-src library and imported it. I assume that the compiler will use these sources instead of the "official" ones . However, when I make a trivial change to the library sources just to trigger a build it fails when compiling mbed-src:

Error: Undefined symbol $Super$$main (referred from retarget.cpp.NUCLEO_F411RE.o).

Worse, even though I undid the changes, it still left the sources as modified. I finally figured out how to revert my import however and it seems happy.

Two questions therefore:

- I would like to be able to successfully compile the library sources. Would the code routinely be broken, or do I need some #defines somewhere?

- Is it possible to get a mixed listing (C source/assembler) from the mbed compilation?

Ok, it sounds like you might have not deleted the "mbed" source. When you import mbed-src you have to right-click on the mbed "wheel" in the project and select delete otherwise the two libs will compete in compiler/linker.

You don't need to do the defines if I understand the problem correctly the defines used are passed in by the the target that you selected.

If you want to start getting more detailed info during compile then you need to switch to local build mbed. You would then need to download GCC and set up the build environment on your pc. A good resource for that is "gcc4mbed"

I suspect you had both mbed libs presented to the compiler and you just need to delete the "mbed" lib and it'll work. If not, can you post up some simple code and let one of us have a go at it? This sounds fairly simple to solve.

OK, Here's what I have done so far:

- I deleted mbed-src to hopefully get me back to where I was. I seem to be able to compile things OK still.

I'm now presented with varying versions of how the mbed library is depicted with each of my programs. On some the gear icon (or biscuit-with-a-hole-in-it icon) expands to one or two entries, on some I get everything:

Are these the mbed library thingamajigs I should delete?

What's the difference between the plain biscuit and the one with the green arrow on it?

I realise that this is turning into a random and unrelated question session on my part and I apologise. I should really explain where I'm coming from.

I have a Nucleo STM32 F411RE board I'm wanting to develop with. My language of choice is Pascal, and for that reason we got the MikroE ARM Pascal compiler. Having played with the mbed environment, it has made me more interested in the possibility of coding in C/C++ than I ever was however, particularly as I found out pretty quickly that the MikroE compiler doesn't support enumerated types, which pretty much renders the idea of directly reusing any of the code I have written over the last 40-odd years a no-show. I'm not sure they should be calling it a Pascal compiler when they don't fully adhere to the language spec.

Whatever. The combination of the MikroE compiler IDE and Nucleo board should still be a useful debugging environment if I can get it to work.

So I figure the first step is to get the embedded version of "Hello World" - the flashing LED - working. My first attempt was unsuccessful, and that would likely be for a variety of reasons, so I thought I would compare the assembler output generated by both approaches to see if I can spot where the differences lie, and whether I need to tweak some setting.

The MikroE compiler provides a mixed source/assembler/hex output file and (although the format is *appalling* for a file that is supposed to be human-readable!) it tells me what the setup and initialisation code does. I was hoping to see the same thing for the mbed compilation of Nucleo_blink_led.

I don't really want to go down the road of setting up a local build of the mbed tool chain - I just want to be able to generate Nucleo_blink_led.lst. I'll probably fall back on hand-disassembly of the binary file.

I appreciate your input, and thanks for reading this far. Any comments you have are welcomed.

Cheers, Ross

After you import mbed-src, you should delete the mbed library which was in the same program, don't touch your other programs :). Reason some expand and some don't is that they are different versions, and mbed staff seems to be breaking stuff instead of fixing stuff.

Regarding your issue: Is now the issue your Pascall thingie doesn't work, or the mbed generated binary does not blink your LED?

In general for what you want, I would consider exporting it to an offline compiler (I don't know which ones are supported for the F411), so you have the full capabilities of that compiler.

Hi Erik. So when I import mbed-src, that only applies to the program I have loaded at the time? If I wanted to tweak the mbed-src sources in two of my programs I would need to import it twice and therefore have two copies?

No, the mbed binary works fine, I'm just wanting to get the version I ported to Pascal working.

Yes, it is only for that specific program. And when you say it like that it seems bad, however in general you don't want to have changes to one program affect the other.

Thanks Eric. mbed-src all imported and compiling now.

R

One advantage to doing local builds is that you can generate a single mbed lib source that is tweaked across all of your projects. With the online builder the projects are siloed so you have to reimport mbed-src or copy it to the new project (which is probably your case).

Glad to see you're up and running with the feedback.