Reprogramming a uC FLASH while running code - STM32F

On Sat, 10 May 2014 13:32:36 +0100, John-Smith wrote:

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

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
www.wescottdesign.com

On 10/05/14 20:51, Tim Wescott wrote:
> On Sat, 10 May 2014 13:32:36 +0100, John-Smith wrote:
>
>> Re assembler, I would think one still needs it for the C startup code,
>> setting up initial register values, etc.
>
> 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".
>

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

In sci.electronics.design John-Smith <noospam@noospam.com> wrote:
>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?
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.

Olaf Kaluza <olaf@criseis.ruhr.de> wrote:

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

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?

On 2014-05-10, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:

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

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,
                              gmail.com            will Jodie Foster marry
                                                   Bonzo??

Grant Edwards <invalid@invalid.invalid> wrote:

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

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

On 13/05/2014 16:19, Olaf Kaluza wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>
>   >How sad for your customers that you never add features to or improve
>   >the performance of your products.
>
> 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.

 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
www.videosolutions.ltd.uk

On Tue, 13 May 2014 08:18:49 +0200, pippo2@disney.com (Jack) wrote:

>Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
>
>> 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. :-)
>
>until the customer decides that he wants a new (very urgent) feature...

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

On 2014-05-13, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>
> >How sad for your customers that you never add features to or improve
> >the performance of your products.
>
> 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.  

It must be nice to work in such a static industry where nothing ever
changes.  Our customers' needs seem to change over the years.

-- 
Grant Edwards               grant.b.edwards        Yow! I am deeply CONCERNED
                                  at               and I want something GOOD
                              gmail.com            for BREAKFAST!

In article <lktmh6$sj6$1@reader1.panix.com>, invalid@invalid.invalid 
says...
> 
> On 2014-05-13, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
> > Grant Edwards <invalid@invalid.invalid> wrote:
> >
> > >How sad for your customers that you never add features to or improve
> > >the performance of your products.
> >
> > 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.  
> 
> It must be nice to work in such a static industry where nothing ever
> changes.  Our customers' needs seem to change over the years.

In some industries it can be a pain because you cannot change it for 30 
years or mroe.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate