Skip programming and debug project

[Antoine Boré]

Hi,

I use the STM32L431 microcontroller and a st-link debugger.

The code that I want to use on the microcontroller is divided in 5 projects.

Each code is flashed on an assigned flash memory area defined on the linker script:

Project 1:

MEMORY

{

 FLASH  (rx)  : ORIGIN = 0x08000000, LENGTH = 0x00000200

 RAM  (xrw)  : ORIGIN = 0x20000000, LENGTH = 0x00010000

}

Project 2:

MEMORY

{

 FLASH  (rx)  : ORIGIN = 0x08000200, LENGTH = 0x00001F00

 RAM  (xrw)  : ORIGIN = 0x20000000, LENGTH = 0x00010000

}

Etc.

In order to flash the microcontroller, I build the 5 project then concatenate the binary output. Then, I program the microcontroller with the STM32 ST-LINK Utility.

I'm able to enter in debug mode in the first project (which is starting at 0x08000000) without erasing the rest of the flash memory by disabling "Download" in Debug configurations -> Startup. However, I am not able to find how to do the same with the 4 others projects. Indeed, when I try to do the same, I enter in debug mode and I can see the disassembly code generated but it doesn't link it with the code. When I pause the program, I have this message:

Break at address "0x8000694" with no debug information available, or outside of program code.

Is there a way to debug some code without erasing the rest of the flash memory that is not located at the start address 0x08000000? Or even better, is it possible to start the 5 projects in debug mode?

[EJOHA]

Hi ABoré.1, I am not sure how you setup the debug configuration for these projects in STM32CubeIDE. 

It shall be possible to configure one debug session and in "Load Image and Symbols" in the Startup tab define all programs which shall be debugged. You say you are using ST-LINK Utility to program the device, and then the "Download" column should be set false and "Load symbols" column must be set true to be able to debug with symbols for all loaded programs. 

Please note, in the startup tab there are Runtime options to set also. The default is that "Default start address" is used. In that case the program counter will be set to the start entry address of the last image (the program on last line in "Load Image and Symbols list") when debugging is started.

Using the described method above it shall be possible to start the 5 projects in debug mode.

You should be able to download (program) all 5 programs by setting download column to true, so I do not see the need to concatenate the binary output and use ST-LINK utility.

However, you will probably not be able to just program some single program of the 5 programs as when programming a complete flash page needs to be erased when programming and that may require some of your other programs to be programmed again. So you can try this method. If it does not work please continue and use ST-LINK utility or STM32CubeProgrammer to program your 5 programs.

It is quite strange to have 5 programs under debug in this way. I do not know why you did not link them together into one or two programs. I have most been working with projects having one, two or three programs. E.g. Bootloader and two applications.

Please let us know how it works.

[Antoine Boré]

Hi Ejoha,

Thank you for your answer, I will try to make it work with the information that you gave.

Here is a small explanation of my workspace:

With these 5 different projects, I tried to increase the robustness of the firmware, and especially the bootloader. Indeed, the micro controller will be used in space and it is really important that the bootloader does not get corrupted.

Here is the architecture:

1. footloader
2. sockloader1
3. sockloader2
4. bootloaderVoter1
5. bootloaderVoter2
6. bootloaderVoter3
7. bootloaderTripleVotingResult
8. Application

The footloader is a small program (tens of instructions) which is non-redundant.

The sockloader is redundant and slightly larger.

The bootloader is bigger and is copied 3 times in the flash memory.

Finally, the user application, which is the largest program, is non-redundant. Indeed, as it can be reprogramed by the bootloader in case of corruption, we don't need any redundancy.

When the MCU start, it starts in the footloader which selects one of the sock loaders. Then the sockloader execute a triple voting algorithm of the 3 copies of the bootloader and branch into the result. Then, we have a classic bootloader/application.

I use the same project for the 3 copies of the bootloaderVoter as they use the same linker script and the program counter never goes inside the flash area. Thus, I have one project for the footloader, one for each sockloader, one for the bootloader copies and one for the application. That is 5 in total.

I am not sure this is the best method to ensure the bootloader robustness but I made multiple tests with different MCUs of another brand and it works fine. Now, I want to migrate to the ST and I have to modify/debug the code as it doesn't use the same driver or ARM processor.

During this bootloader process, I jump between stages of it by updating MSP, the vector table and branch to the reset handler of the next stage. However, it doesn't work as expected for the moment and I would like to enter in debug mode of the sockloader to understand what happens.

Don't hesitate if you have any question about how it works as it is not so simple.

[EJOHA]

Hi ABoré.1, sounds like an interesting project!

Just one comment from me which you probably already are aware of. If you want to debug from first instruction in startup code this can be done by unchecking the Resume checkbox in the startup tab of the debug configuration. This means that "continue" will not be sent by the debug session so you will start from the entry point. It should be from the footloader in your case. From here you will be able to step through the code.

If you have mixed up the programs in the load list it is also possible to set Start Address using "Set program counter" in the startup tab.

[Antoine Boré]

Thank you for the tips. Unfortunately, when I start the debug session without "Download", I got stuck in a loop in the "System memory" area (around 0x1FFF2XXXX). I guess it is the code that load the user application. I am not sure how I should solve this issue. Does it mean that my program is somehow corrupted or something and that I can only start the debug session by downloading it?

[EJOHA]

Some questions.

Does any of your programs enter low power mode? If this is the case can you try to remove entering low power mode when debugging.

In the debugger tab there is an option selecting Reset type. Have you tried "Connect under reset" or "Software system reset"?

Did you try to set program counter to program start in Runtime options and not having "Resume" checkbox enabled?

[Antoine Boré]

No program enters in a low power mode.

I have tried both reset type.

I actually solved this issue by setting the "Use symbol address (hex)" to 0x8000000 instead of letting the box blank.

I am not sure how this field work. Do I need to set the starting address of each project if it is already indicated in the linker script and thus in the elf file ? Should I try to download the binary output instead of the elf ?

[EJOHA]

The debugger will need to have use the elf file. For programming I would recommend to use Motorola srec or Intel hex file instead of binary files which does not have any address information.

You can probably try to program using ST-LINK utility or STM32CubeProgrammer instead of programming when starting the debug session in STM32CubeIDE.

Please use STM32CubeProgrammer or ST-LINK utility and verify that your 8 programs has been programmed correct by investigating the flash data.

Regarding the fields in "Add/Edit" dialog the first offset edit field (for Download) should only have the offset address while the second symbol address filed (for symbols) should have the value where it is located, so seems correct to use 0x8000000 if no offset used.