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.

[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

[AA1]

Maybe this helps: STM8 bootloader frequently asked questions.

 

[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!

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

[papadeltasierra]

The very cheap and readily available HC-12 boards use an stm8s003f3 and a SiliconLabs 4463 to do wireless TX/RX.  In standard HC-12 guise they are pretty boring but I believe they can be "freed" using custom firmware to do more exciting stuff like at work as receiver of W-MBUS data etc.  My plan is:

- Use sample code wherever possible so...

- Use the ST sample bootloader

- Use the SiLabs sample transmit/receive app

- Split the 4463 config between fixed and "worth making configurable" where the configuration will live in the 128 bytes of EEPROM.

So an HC-12 would end up being a specialised "one frequency, one wireless set-up" board for custom uses.  To change from say OOK to FSK or 4-FSK would be an EEPROM change and then these boards become ever more useful.  Initial investigation is that 8kB is enough for the sample bootloader and the transmit/receive application with no bells-or-whistles.

I started because I happen to want a W-MBUS receiver and have an HC-12 and it has been a long time since I did any programming in such a restricted environment.  It's purely a "fun home project" so I definitely will not be designing circuit boards or making this a commercial project.  It will be open-sourced though.