How to debug a project with custom bootloader in STVD?

[Pavel A.]

Posted on October 16, 2017 at 20:09

Hi again.

I'm still stuck with the same problem as

https://community.st.com/0D50X00009XkXJDSA3

before.

The microcontroller model is STM8L101G3U.

The debugger interface is ST-Link USB.

I have a project with a custom bootloader, done as described in the app note

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm8-embedded-software/stsw-stm8006.html

, with Cosmic compiler (sorry to these who prefers other tools).

Cannot figure out how to debug the main firmware and keep the bootloader programmed on the device.

When the bootloader is programmed and protected using the option byte:

Debugger refuses to start the main app. It pops up the following error:

GDI Error: For better debugging performance, the user bootcode size must be reduced.

You need to change the UBC option

The bootloader size is 0x23 pages (0x23 * 0x40 = 0x8c0). Is it really too much??

When I remove all code protection bits in OPT2, starting debugger on the main firmware ERASES the bootloader.

The debugger breaks nicely at the start address 0x8000 - but there's no any program there. All zeroes.

In Tools->Programmer settings, erasing of the flash is NOT checked.

Is this supposed to work at all with the STVD 4.3.1.1? If yes, what I am doing wrong?

#debugging #stm8l-cosmic #stvd

[Tesla DeLorean]

Posted on October 16, 2017 at 22:54

Perhaps if you use a .HEX you can merge the loader and app images before starting the debugger so both images co-exist.

Alternatively debug the loader as much as you can, add functionality so you can stream in and write the app image to FLASH using X-MODEM over the USART, and step into it.

[Pavel A.]

Posted on October 20, 2017 at 22:38

This is what's working for me finally:

I've removed protection of the bootloader and after more fiddling with the Programmer tool of the IDE (a GUI widget available in Tools menu of the STVD), it now loads both parts.

One of these fiddling was rewriting the bootloader by the Programmer with erase and unlock options set.

STVD either ceased erasing the whole flash, or it prepends the bootloader image to the main firmware, or maybe it is smart enough to detect that the bootloader did not change.

(Note: the bootloader does not load the main part yet, it only does some hardware setup and validates the main part).

But another developer on this project, with same hardware, manages to load the main firmware with protection set on the bootloader - and STVD won't complain. 

I cannot understand what is different for him, but with the above workaround, at least I can keep working on both parts.

Regards,

-- pa