[SOLVED] Flasher STM8 programming speed

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Flasher STM8 programming speed

    Hello,

    I am using Flasher STM8 in production and it is working quite well. Biggest mcu is STM8L151C8 with 64kb and it takes about 6.4s for program & verify without erase (USB) which is quite close to 11.3kB as it says online.
    As I program >100k mcus/year I would like to improve this speed. I think with checking my setup I could increase the speed to the 11.3kB but my wish would of course be to make it even faster.
    After analysing the SWIM flashing algorithm I wonder where the bottleneck is.
    According to datasheet programming a page size of 128 bytes will be typ. 3ms -> so 512 pages for 64kb-> 1.536 seconds for programming (no erase).
    Transfer via SWIM in high speed mode could be aproximately 130kb/sec (16Mhz HSI, 10 Clocks/bit, aproximatly 12bits per Byte for writing a page on the fly -> 16meg/10/12=~133kbyte) -> ~0,5 seconds for a full memory transfer + another 0,5 for verify = 1 second.
    So overall programming time for 64kb could - in theory be - ~1.5s + 1s = ~2.5 seconds. USB-transfer time to Flasher STM8 will add to this value but it is quite still a gap to my measured 6.4seconds.
    Where is this difference coming from? If I remember right, there was quite a delay necessary between the SWIM commands or is it something else?

    Best regards & thanks in advance,
    Alexander T.

  • Hello Alexander,

    Sorry about the late response.

    The problem here is actually the real programming speed that the Flash gets programmed internally.

    In the beginning of the product we experimented with other features like RAM code programming
    where we put a multiple of a page into the RAM and then program it via a code that we also download
    into RAM for direct CPU->Flash programming.

    However this turned out to still result in very slow programming speeds with almost no advantage
    over the actual SWIM->Flash programming.

    The bottleneck here seems to be a delay between programming pages (until the status register reports success for the page programmed).
    From here on we have not put more effort into this as it only adds more complexity without a big benefit. We are actually always waiting
    for the STM8 side, basically sitting idle all the time. The actual programming end of the SWIM on our side is a dedicated MCU that runs
    entirely from RAM for the fastest reaction time possible to the STM8 end.

    The STM8 history of facts is kind of flawed as well. In the beginning ST stated that Flash could be programmed
    at around 64kBytes/s but it turned out that this is roughly the transfer speed into RAM that you can achieve
    via SWIM, with the actual top speed for actual flash programming is only around 15kBytes/s .

    Please also note that although an internal HSI of 16MHz might be used, SWIM only comes at 8MHz.
    I might be mistaken but I think this was initially also stated as 16MHz SWIM speed which is not true at all.

    Therefore I doubt that you can achieve much higher speeds with STM8 devices at all.

    Do you know of any other vendor who states (much) faster programming times for STM8 than we do ?

    Best regards,
    Oliver
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Oliver,

    Thanks for the answer.

    You are right with the SWIM-Speed which is only at 8 Mhz. This would then match ST's 64kb/sec SWIM-Speed (8Mhz SWIM Clock, 10 Clocks/bit, aproximatly 12bits per Byte for writing a page on the fly -> 8meg/10/12=~67kbyte).
    So for programming, transfer & verify this would be ~3.5s (~1.5s + 2s = ~3.5).
    Comparing this again with the real programming speed I still see a big difference.
    My calculation is assuming the "fast block programming mode" which needs 3ms per page. If I assume the "standard programming mode" with 6ms I would calculate ~3s + 2s = ~5s which is quite close to the actual FlasherSTM8 speed.
    Could you please check if FlasherSTM8 is using "standard block programming mode" for -programverify instead of "fast block programming mode" for which could be used for blank devices? This would be an explanation and could easily be improved.
    I did not have the time to make sample programs now but from earlier tests I remember that the typical programming time in the datasheet was correct. With checking of the status bits it took ~3ms for fast and 6ms for standard programming.

    RAM code programming was also an idea I wanted to talk about. Nice to hear you already had thoughts in this direction. If you say it did not improve speed then I assume you do it sequentially. My suggestion would be to do it in a multithreaded way. Instead of beeing idle during programming time, the swim interface could be used to load the next page into ram:
    - a RAM program would always be running and checking flags of two alternating buffers
    - each of two buffers contains content for one page
    - flags in RAM are be used for signal-exchange between swim and ram-program
    - one buffer will be used by the RAM-program to write into flash
    - the other buffer will be used by SWIM-Interface and written on the fly while the RAM-program is waiting for the flash-flag. After SWIM filled the buffer a flag in ram will be set to signal the RAM-program the state of the buffer.
    After the ram-program finished programming it can instantaneously program the next buffer and SWIM fills the other.

    This would reduce the programming time to the bottleneck of flashing OR communication. I think in this way it should be possible to program a 64kb controller in ~2 seconds including verify. The only thing I am not 110% sure about is, if the RAM is fully accessible by swim during programming of the flash?

    With >100k controllers per year, every second counts!

    I did not check the speed of other vendors production flashing devices yet as FlasherSTM8 claimed to "allow downloading to the target as fast as the target can receive and program flash".

    Best regards,
    Alex

    The post was edited 1 time, last by AlexT ().

  • Hello Alex,

    Sorry for the late reply.
    I have discussed your request internally.

    You are right that we do not use the fast block programming mode (without self erase of the block). If I remember correctly this was an intentional decision.
    As simple as STM8 devices might be, there are different variations about how the program memory behaves and in early tests we had way less problems
    with the standard block programming (with auto-erase) than with the fast mode.

    In addition to this we experienced that some of our customers who expected to be using blank chips in production, some of these were not actually empty (not talking about ROP active with 0x00).
    In this case the self-erase of blocks still provided the best outcome via full erase + program time.

    The Flasher STM8 has been introduced back in 2009 and has since then been superseded by our newer models Flasher Portable Plus and Flasher PRO that
    come with a more flexible way of extending features and are general more feature rich for some purposes.

    At this time it is not planned to add more (complex) features like RAMcode programming to the Flasher STM8 as the software is not entirely ready for it.
    Optimizations that involve adding more configuration to support and guarantee backwards compatibility and stability are not on our ToDo for this older model in general.

    We will contact you via mail regarding an option/workaround about using the fast block programming with Flasher STM8 as this might include sales
    related topics that are not subject of this forum.

    Best regards,
    Oliver

    Closed and moved to mail
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.