cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with flash programming (SWIM) and memory protection

mats2399
Associate II
Posted on November 27, 2016 at 13:53

Hi!

I'm trying to implement a SWIM programmer using only the datasheets, for an STM8S003F3.

I have got the basics working (swim entry, rotf, wotf, srst). An I've been trying to figure out how to actually program the flash.

I can write MASS key to FLASH_PUKR and can verify that PUL is set.

I can verify FLASH_FPR is unset.

As far as I can tell, issuing wotf commands to the flash memory region (0x8000-0x9FFF) should be all that is required, but doing so only sets WR_PG_DIS in FLASH_IASPR, indicating that memory is protected. What am I missing here?

Thanks in advance!

//Mats

#swim-wr_pg_dis-flash-stm8
2 REPLIES 2
mats2399
Associate II
Posted on November 28, 2016 at 07:07

I'll add that the MCU when I got it was preprogrammed, and locked. I've tried disabling ROP by writing 0x00 to OPT0 (ROP) (after MASS on DUKR and setting the OPT bit), and I don't know if that really worked or not, but the unit is not running the supplied program anymore at least.

Even though something happened, I don't seem to be able write new data.  Is there anything else to unlocking/erasing the MCU?

This is really frustrating, as the documentation that I've found thus far (RM0016 - Reference manual STM8S series and STM8AF series 8-bit microcontrollers, UM0470- User manual STM8 SWIM communication protocol and debug module and PM0051 - Programming manual How to program STM8S, STM8A Flash program memory and data EEPROM and the data sheet for STM8S003F3) are not detailed enough.

I've been trying to search the web for clues and even look into the source of the open source SWIM programmer projects I can find, but so far I haven't been able to find the missing piece(s).

Best Regards

Mats
mats2399
Associate II
Posted on November 29, 2016 at 00:17

Ok, so I got this sorted. The issue was that my code for resetting ROP was not entirely correct. The ROP was issued, but I guess didn't finish.

The solution was to poll EOP bit until set after issuing ROP reset. This was actually something I had already implemented, but I had a bug so that it didn't work. I tried inserting delays and suddenly it worked, and that is how I caught on to the bug.

Still, the main reason for frustration was that the documentation really isn't detailed enough... ROP disable, is really just glanced over, EOP is sort of inferred from other parts of documentation, but it is not really clear under which circumstances EOP is set.

I'm glad I got it working though 🙂