STMFlashLoader/STMFlashLoader Demo not quite working - suggestions?

[papadeltasierra]

I have followed AN2959 and have a bootloader running on an STM8S Discovery board but I cannot make either the command line or GUI based STMFlashLoader programs upload a program - can anyone help?

- The command line version always says `No response from the target, the Boot loader can not be started.` and from running the bootloader under debug, I cannot see any attempt to talk to the bootloader

- The GUI version does connect but will not upload an `s19` image saying `Cannot find the E_W_ROUTINEs file.  Please make sure you selected the right device...` except that on the previous page, no devices were listed.

FWIW, the command-line set-up is port 9 (Windows COM9), 9600, 8, E, 1 but as I say, there is is no indication that the program is trying to send anything!

Thanks for any suggestions, even if just debugging tips to try!

[Tesla DeLorean]

AN2959? You sure or dyslexic? Please provide a link / cite

https://www.st.com/resource/en/application_note/an2659-stm8-inapplication-programming-iap-using-a-customized-userbootloader-stmicroelectronics.pdf

This is about IAP methods, software *you* put on the STM8

Sure you're not talking about the STM32 tools?

https://www.st.com/en/development-tools/flasher-stm8.html

[papadeltasierra]

Not dyslexic, just a poor typist ;-).  `an2659-stm8-inapplication-programming-iap-using-a-customized-userbootloader-stmicroelectronics.pdf` is the document I meant.

At present I am on the "customized userbootloader" part of that document.  There is some accompanying software for those chips that don't have their own built-in bootloader and I have that compiled and loaded onto the STM8S Discovery board.  Ultimately it will go onto the actual target which is an stm8s003 (recompiled of course since the Discovery uses UART2 and the stm8s003 uses UART1).

The link you provided for flasher-stm8 is precisely what I am trying to use.  My understanding is that it should talk to the sample bootloader code, but currently it "sort of" does for the GUI but doesn't at all for the command line.

I'm going to do some more reading this morning in case I missed something because there are a lot of config items as well as "map" files so perhaps I'm just using it wrongly.  However the fact that when using the GUI and running the bootloader under the STVD debugger, I can see that the two at least start to talk, make me think I'm heading in the right general direction.

[AA1]

Maybe this helps: STM8 bootloader frequently asked questions.

[Tesla DeLorean]

Not a follower of the STM8, been in the 32-bit camp since the mid-1980's

Wonder if the other chips has sufficient code space to accommodate a loader

https://www.st.com/resource/en/user_manual/um0560-stm8-bootloader-stmicroelectronics.pdf

https://www.st.com/en/embedded-software/stsw-stm8068.html

Examples of the STM32 AN3155 protocol can be found in stm32ldr and Arduino MRK WAN1300 firmware updater tool.

The EVEN parity and 0x7F test pattern there is designed for a TIM to measure the pattern, and set a baud rate.

For IAP the use of X-MODEM is strongly suggested given the availability of existing terminal app / tools on many platforms to send over a .BIN

[papadeltasierra]

Thanks, those look like useful info, especially the "only waits for 1second" note.

FYI although the chips listed come with a bootloader "built in", ST provides source to add a bootloader to chips that do not have one built in.  Having built the bootloader, it appears to take about 3kB of the Flash, leaving 5kB for your application, ad this is what I am trying to do with my Discovery board and then stm8s003.

There is the "fun" of having a secondary vector table and having to direct both reset and any interrupts through to to application but that's explained reasonably well in AN2659.

[papadeltasierra]

Aha, some progress.  Firstly, the sample code for chips without a built-in bootloader doesn't have a timeout, but it only works "first time" so if you have trouble connecting, you need to close the flasher program, power-cycle the board and try again.

Secondly the GUI flasher has a set of configuration in a `conf` sub-directory, but it doesn't read it unless you are in that directory when you start the GUI!  Once you do that, targets appear and things start to try and work.

But now the flasher says that the chip is write protected and it cannot flash.  I will have to investigate this because it was certainly not something I wanted or set deliberately.

So progress and if I can get the GUI to work, hopefully the command-line will too.

P.S. Having lovingly set up the primary and secondary vector tables, I managed to flash the bootloader and my sample application using the "ST Visual Programmer" by creating an S19 file as follows:

1. Concatenate the bootloader and sample S19 files

2. Find the first (terminating) S9 record and remove it

3. flash the combined image.

The bootloader is triggered by holding down a pull-up line and I've proved that without the pull-down, my sample application works but with the pull-down, the bootloader is active so progress :-).  Now to get the bootloader to actually load something!

[papadeltasierra]

Well I see the problem now but don't know if there is a simple way to fix it.  The stm8s003 specs say that a block size is 64 bytes but the flasher always tries to send a block of 128 bytes and neither the GUI or command line versions seem to have a setting for this.

There is a conf file for the GUI but no obvious field to change and there is just not apparent option for the command line at all.

The sample bootloader polices the block size and rejects any erase or write for greater than the block size, and that is why my attempts to flash my application are failing.

[papadeltasierra]

Success.  The command-line flasher app reads config from "map" files via the `-i device_name` argument.  These map files contain a field `PacketSize=80` which is the amount of data that gets sent at a time i.e. the "sector size".  80 is hex so 0x80 = 128.  Set this to 0x40 (64) and the flasher then sends just 64 bytes which is what the smaller devices like the stm8s003 required.

Don't know how to do this with the GUI application though.

[Tesla DeLorean]

Any strong reason to chose the STM8 over some of the newer/smaller STM32 Cortex-M0 parts? Say in the STM32C0 or G0 families.

The STM8 is a bit of a Dead Horse Walking.. coasting along with little support, staff and excitement.