Electronic – How to flash protected STM8 MCU

firmwarestm8

I would like to flash a new firmware on my STM8L15xC8. I have ST Visual Programmer (STVP) installed and can successfully flash the MCU of the STM8 Discovery board. Now, I setup the STM8 Discovery board to flash external applications. However, when I want to write to the MCU my hex file, I get the error The device is protected. What should I do?

Best Answer

Make sure that the Read Out Protection (ROP) byte is set to off. Open STVP, go to the OPTION BYTE tab, set ROP to off and write out (Ctrl + P). Then, go to the PROGRAM MEMORY tab again and you should be able to write your hex file.

Related Solutions

Electronic – Why is this hex file different than the code programmed onto the device

Perhaps Eclipse uses gcc to create the hex, and then modifies it en route to the device?

No, it's the other way round. When you compile a project in Eclipse,

individual files are compiled into .o object files
object files and libraries are linked into an .elf file
objcopy generates a .hex file from .elf
and finally the size is printed by size, but this last step is purely informational.

The debugger however works with the .elf from step 2, because it has symbols and other debugging aids in it, which are lost when converting to .hex. Therefore, I'd take a very close look at step 3, and perhaps at the .elf file too.

This is how step 3 should look like in the eclipse build console window

Finished building target: app.elf

Invoking: Cross ARM GNU Create Flash Image
arm-none-eabi-objcopy -O ihex "app.elf"  "app.hex"
Finished building: app.hex

Invoking: Cross ARM GNU Print Size

First, check if there are any warnings or other suspicious signs. Is it regenerated when you remove it, and build the project? And when you remove the .elf? Are the file timestamps correct? Try to repeat it from the command line. For that to work, you'll have to specify the full path to arm-none-eabi-objcopy in your toolchain, or include it in your PATH. Make sure that the toolchain path is properly set in eclipse, and there are no other versions of objcopy lying around, especially in your PATH.

You can examine the .elf with arm-none-eabi-objdump. List the "directory" with -h, it looks like this

app.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   0000013c  08008000  08008000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         0000b4cc  08008140  08008140  00008140  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       0000b1c0  08013610  08013610  00013610  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .ARM          00000008  0801e7d0  0801e7d0  0001e7d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .init_array   00000008  0801e7d8  0801e7d8  0001e7d8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .fini_array   00000004  0801e7e0  0801e7e0  0001e7e0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .data         00000a60  20000000  0801e7e4  00020000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  7 .noinit       00000004  20000a60  0801f244  00020a60  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .bss          0000cbf8  20000a68  0801f248  00020a68  2**3
                  ALLOC

Check the LMA and Size fields for each section. Is there an overlap? Dump the contents with -s and examine it around the problem address.

Electronic – How does factory reset work

Generally speaking the factory reset function you mention will restore any saved variable data information back to default values. It is not true that all embedded devices have this capability. Some do but not all.

If you want your device to support a return to factory default firmware itself then your design has to incorporate a memory into the circuit to store that image. A common component for this is a SPI flash chip. Then your boot loader also needs to be changed to support a mode of getting a firmware image from the SPI flash chip instead of getting the image in through the serial port. If your device does not support user replaceable firmware then it is usually not necessary to provide a means to restore to factory default firmware.