Custom Bootloader, Debugging and the Cosmic Compiler

Aaron Derbyshire · ‎2017-11-09

Posted on November 09, 2017 at 15:33

Hi,

I am currently working with the STM8S003K3 and I am attempting to write a bootloader function which will take an S-Record line by line and write the contained data to Flash. I have seen that is common practice to store the bootloader function in the UBC to provide it protection, however, I am currently prototyping and don't require this level of protection just yet.

I am instead storing the bootloader function in the standard program memory area, the location of which is determined by the Cosmic Compiler and Linker. I am utilising the linker command specified under the moveable code section and I can see that this is working correctly from the map file.

There are two main issues which I am struggling with:

1. The first issue is in attempting to use the _fctcpy() function provided in the machine library by Cosmic. Whenever I call the function to copy my bootloader to the RAM space the SWIM Debugger experiences a Comm Timeout.

2. Whenever I flash the MCU and communicate with the device via the UART the device resets upon calling the function.

Are the problems I am experiencing a by-product of the method I am trying to use (i.e the _fctcpy() function operates as thought the bootloader function resides in the UBC and so performs the necessary checks on the option bytes prior to executing the copy function?).

Any help would be greatly appreciated.

Thanks,

Aaron

#stm8-uart-bootloader #stm8-debug-problem #stm8 #usart-bootloader #cosmic-compiler

luca239955_stm1_st · ‎2017-11-10

Posted on November 10, 2017 at 10:15

Hello,

from what you write it looks like the fctcpy() function does not execute correctly (by the way it just copies the memory area without checking any option byte). Maybe you can execute it step by step and see what is wrong?

If you can't work it out quickly send us the map file and the linker file (

mailto:support.stm8.free@cosmic.fr

) and we'll see if that's enough to understand where the problem is.

Regards,

Luca (Cosmic)

Aaron Derbyshire · ‎2017-11-10

Posted on November 10, 2017 at 12:04

Hi Luca,

Unfortunately I cannot step through the _fctcpy() function as the SWIM Interface experiences a communication timeout when I attempt to call it.

One thing which I have noticed is that in the AN2659 and supporting firmware project, the _fctcpy() function is prototyped in the main program. I have also tried this with no success as it's already predefined in the library, although the supporting firmware example also includes the library etc which I already have in my project.

When using the approach highlighted in the moveable code section of the Cosmic Compiler documentation, is the handling of the stack pointer (loaded to the appropriate address in RAM) implicitly handled or is this down to the user?

Thanks,

Aaron