Reprogramming a uC FLASH while running code - STM32F

I have used a variety of different micros (Z80 onwards) since about

1980 but all the PROM or FLASH based ones (e.g. H8/300 or Atmel 90S1200) were programmed externally, via a spring-contact adaptor.

We have one product using an H8/300 with an external 28C256 32kbyte parallel EEPROM for extra code, and we quickly found this could not be written with code running in it! No sh*t Sherlock, as they say here in the UK, but it took a good hour or two to realise why... The reason of course is what while the EEPROM is executing its programming cycle, it isn't readable for code and data fetching.

I am now looking at a new uP for another project and it is the ST ARM STM32F range. For about a tenner you can get 1MB of on-chip FLASH which is loads.

But how can one program this in situ?

Either there is a separate FLASH segment which remains available all the time (how is that programmed?) or one has to load a loader into the SRAM and execute it from there.

How do people typically do this?

I don't think the chip needs an elevated Vpp for programming - that would really complicate things. I think some of the old Atmels needed that.

Could anyone suggest the best developer kit for the 32F, for assembler and C programming?

Reply to
John-Smith
Loading thread data ...

Put the innermost code into RAM for the time of programming. Of course, you need also have the block of data to program in the same RAM. Only the code to do the programming and polling for ready needs to be in RAM (while the Flash is not accessible), other code can be in the Flash.

At least those I have used can be programmed with the normal supply voltages.

I have used the GNU tool set, for Cortex-M. My selection for an IDE is Eclipse.

Get a ST dev board for the processor (or some similar enough). The simple boards are cheap, and they can double as USB-to-JTAG adapters.

For JTAG, I'm using OpenOCD.

--

Tauno Voipio
Reply to
Tauno Voipio

This is normal behavior for all controller I know, and I know many. :-)

Both is possible. When you read the data sheet of your controller you will find that the flash is segmented in parts. It is very common to use one segment for a bootloader that is written by yourself to programm all the other segment.

And it is very common that there is another segment with a bootloader that can only programmed by the manfuacturer with there own bootloader.

Of course it is also possible to copy a program from flash to ram and start the program in ram. Than this program can delete and program the flash. But it is dangerous, because you should not switch it of at this point.

That depends on the application. A good application from a good company never need to flash in the field because it is well tested and without errors. :-)

The chip needs a higher voltage, but it has an internal boostconverter. So it means if you flash a new program by bootloader it need more power for a short time.

Buy one of the application kits from ST. They are cheap and the debugger you will need to develope is for free, too. There is also a free enviroment for developement from IAR, but it is codesize limited and the look and feel is a pain in the ass. You can use the gcc too. In this case most people using Eclipse. The look and feel for Eclipse is nice, but it needs a fast computer, because it is java-crap and it is very complicate, without logic and behind humans brains, what happens inside Eclipse.

Perhaps Assembler is possible, too. But nobody use it anymore. (with a very few exceptions)

Olaf

Reply to
Olaf Kaluza

Tauno Voipio wrote

Many thanks (both of you).

All my embedded devt was done with a makefile (lately a batch file because PCs are so fast that a makefile is pointless) and no IDE.

I used Brief as the editor :)

Am I right that an IDE basically gives you an intelligent editor e.g. one that knows where a function starts and ends, etc? And maybe syntac checking?

Re assembler, I would think one still needs it for the C startup code, setting up initial register values, etc.

This product will need to do bluetooth, for which we will buy a module of some sort. If it can support USB for factory programming etc that would be good too.

What is the Jtag interface used for? Is it for programming the FLASH?

I know I need to read the data sheet but I was after a few quick pointers...

The other uC we looked at was the AT Mega 128 but the 32F seems about

5x faster, and a similar cost.
Reply to
John-Smith

You could call it an intelligent editor, you build with the push of button within the IDE, it "knows" the code so you can just jump to definitions, sh ow when a function is called, jump to error line when building etc. etc.

I've recently tried

formatting link
looks like a version of eclipse tailored to cortex-m so everything is setup out of the box, getting a standard eclipse setup takes a bit more tweaking

with cortex very little is needed, basically one file zeroing and initializ ing variables the rest can be in C

many of the STM32Fs can boot from usb

it can be used for that, it is a debug interface that can read/write, start/stop single step the cpu etc.

I wouldn't bother with an 8bit mcu

-Lasse

Reply to
Lasse Langwadt Christensen

Most of my projects in Eclipse are Makefile projects. Eclipse

So did I years ago ...

Yes. The Eclipse CDT checks plenty of C semantics, too, and it speeds up markedly getting rid of simple blunders.

The Eclipse suite is a CPU hog, but with the current hardware, it is a no issue anymore. It is written in Java, and I have pretty similar set-ups running on Mac OS X, Linux and Windows, with Linux as the main O/S for embedded development. Eclipse supports a bewildering assortment of other target languages / systems besides C. At least in my use, it is pretty much all I need (for e.g. C, Doxygen, LaTeX, HTML, XML).

The Web is full of examples how Eclipse and CDT work, have a look at them.

--

-TV
Reply to
Tauno Voipio

RTFM -- typically one copies to SRAM as mentioned (if this is available; obviously, that doesn't work on Harvard architectures), or uses a special "bootloader" segment which has different R/W settings. Flash is EEPROM more or less, but written a page at a time, usually 64-512 bytes. The rest of the memory remains available for access, usually with some restrictions. The bootloader area is special, I think, by usually being unrestricted during writes to the rest of memory. It can also be written to, in which case the CPU may stall until access is freed up again.

Vpp is not required; Flash devices always have an onboard charge pump to do this. Which is one reason Flash writes can be so slow.

Tim

--
Seven Transistor Labs 
Electrical Engineering Consultation 
 Click to see the full signature
Reply to
Tim Williams

The STM32 Flash controller is done in such a way that you can program the Flash from code in Flash. What you cannot do, of course, is reprogram the sector containg any code you use while programming. If you want to reprogram the whole Flash, then you have to put the code in RAM. For (say) an XModem downloader over serial and program code, there's plenty of RAM on all but the very smallest STM32 devices.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

Nothing is wrong with a makefile. Even in modern times with Eclipse it is a good idea to use it for professional work.

And I use Emacs at home and Eclipe+Emacsmode at work. It is always funny if a coworker tries to type something at my computer. :-D

Yes, and much more. For example spell checking and the Ide is checking all other files of your project if you like to finde a declaration of a variable or function. But sometimes it is bothersome.

For example Eclipse did not like this by default:

switch(blabla) { case 1: foo1(); break; case 2: case 3: foo2(); break;

}

It is also possible to use git inside.

That is possible, but it is also possible to do this in C.

Some of the bigger controller can do. For example I think the ST32F407 should do. But using USB for factory programming is a bad idea. Not reliable enought. For this reason use the JTAG interface.

A good quality programmer is about 600-1000Euro. It has network connection and can program out of the factory database.

BTW: There is a cheap J-Link/JTAG for non professional use:

formatting link

The JTAG is for programming, debugging and also for factory hardwaretest. It is good, reliable and fast. But it need some wires and a bigger connector The ST32 has JTAG, but also a second interface with two wires. That one is okay too. It is used at the development board from ST. The development board, for example this one:

formatting link

had the microcontroller and also the debug interface for development and programming. It is also possible open the wire by jumper and use the debug interface with your own board.

Olaf

Reply to
Olaf Kaluza

I just found this:

formatting link

It explains almost everything at beginner/student level. :-)

Olaf

Reply to
Olaf Kaluza

I don't know typical, but like Tauno, I put the minimal amount of code in RAM. Usually that's a procedure that turns off interrupts, programs some words into flash, waits for flash to come alive, turns on interrupts, and returns.

Yes, you do need to read the manual. No, it does not need elevated Vpp.

I prefer Eclipse, but that's more because I acquiesced to what the market does than because it's necessarily the best all-around tool. It's usually easy to set it up for a makefile build and whatever hardware debugger you're using.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

If you are careful and know what the C compiler is doing, the Arm Cortex processors allow you to write C code from the git-go.

You don't start with a full C environment (you don't have any memory initialized, mostly), but you do start right off the bat at a location that you choose, with a stack pointer that's got a value that you choose. No memory is initialized, but that can be done in your initial C routine (be careful of what you do with the stack, though -- it's probably best if you can coerce the compiler to put all your variables in registers).

This may be less true if you've got a chip with an MMU.

Personally I'm using startup code written in assembly, but that's because I said "this is startup code, therefor it must be written in assembly!". Then I saw some comment here, went back and looked and thought, and then thought "damn. I could have made my life simpler".

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

Most people just use the startup code that comes with their toolchain, either as part of the library or as files copied over at "project creation". And in most cases, such startup code is okay, but suboptimal.

I started writing my own startup code when working with a Coldfire processor, IIRC. I realised that instead of using the mess of incomprehensible assembly that the toolchain had evolved over multiple generations and multiple different targets, I could write far smaller, far clearer, and far faster startup code in C. I only needed a couple of lines of assembly (embedded within the C file) to set up the stack, and then it was C code.

There are a few things you need to remember about pre-main C. You might not have access to a stack yet, so be careful about any data that can't stay in registers (and make sure you enable optimisation!). You can't use initialised data before the initialisation pass, and you can't assume that uninitialised data is zero before you've cleared the bss. And if you use C++, you can't assume static objects are constructed. And of course, the same applies to any functions you call (assuming you have a stack, otherwise you can't call any non-inlined functions).

Reply to
David Brown

x
C

in

se

.
n

yeh often the start is just a copy loop and and a zero loop, maybe a call to some init in C and then main

much like the scatter file it isn't something you mess around with all the time so I don't see much gained from c vs. asm

-Lasse

Reply to
Lasse Langwadt Christensen

AFAIK those uP have a build in boot loader for this purpose. This allows for programming via the uP's UART.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de 
HTML mails will be forwarded to /dev/null.
Reply to
Peter Heitzer

until the customer decides that he wants a new (very urgent) feature...

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
Reply to
Jack

How sad for your customers that you never add features to or improve the performance of your products.

--
Grant Edwards               grant.b.edwards        Yow! If Robert Di Niro 
                                  at               assassinates Walter Slezak, 
 Click to see the full signature
Reply to
Grant Edwards

Nope, our customers are very lucky because we can print SIL2, Atex and EX(i) on our product. They dont care so much about improved performance, they enjoy the quality and reliability.

Olaf

Reply to
Olaf Kaluza

From a customer's perspective, do those printed acronyms exclude the possibility of a bug?

The alternative, of course, is to have items updated by return to manufacturer. But the idea of being able to update software in any product via say a USB port is very attractive, to both the manufacturer and the customer.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Or until you decide that there's money to be made selling the new feature to existing customers.

Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.