- This topic has 9 replies, 3 voices, and was last updated 8 years, 1 month ago by
.
-
Posts
-
Hi,
I’m trying to adapt one of my company’s big projects to use VisualGDB for debugging purposes. I was able to put together a project that compiled but failed to debug. The project has a pre-bootloader, bootloader, and then an application. The pre-bootloader is located in flash starting at offset 0kb to 4kb, bootloader starts at 5kb to 64kb, and application starts at 65kb to end of flash. The pre-bootloader, bootloader, and application are separated into its own project (each project producing its own .bin/.elf file).The project that I tried to debug was the application project that resides in flash starting at offset 65kb. When I press F5 to debug the project, I want to upload the firmware to flash starting at offset 65kb instead of 0kb (then do a reset after the programming forcing the MCU to run the preboot -> bootloader -> and then the application). I searched all of the options provided by VisualGDB but did not find any option to specify an offset where to start flashing at. Does VisualGDB support this kind of project structure? Thanks in advance.
Yes, it is possible to configure VisualGDB to place your code starting at a different address. Please see this thread for an example: viewtopic.php?f=5&t=2777
Note that if you are using Freescale Kinetis, the FLASH region at addresses 0x400-0x410 should contain FLASH security bits. If you change your linker script, ensure that the security bits end up in the same place.
Please also note that if you program your project starting at 64KB using VisualGDB, it will fill the first 64KB with zeroes and not just keep them unchanged.@bazis wrote:
Please also note that if you program your project starting at 64KB using VisualGDB, it will fill the first 64KB with zeroes and not just keep them unchanged.
Hi Bazis,
Thank you for responding. So basically it does a full chip erase before programming? If that is the case, it won’t work with my situation. In my case, a complete firmware consists of 3 different firmwares that reside in different area in flash that works together: pre-bootloader, bootloader, and application. When the device starts, it runs the pre-bootloader that decides whether to jump to the application or the bootloader depending on some physical switch buttons configuration. With that said, when I debug the application project (using the application .elf file), I want to erase just the sectors after 64kb from 0x08000000 (yes, i am using stm32f407) leaving the pre-bootloader and bootloader in place, program the application into flash, then start debugging.
Right now we are using Insight Debugger/Eclipse CDT and we can do what I just described without any issue. But it’s just not convenient to use multiple tools for programming, compiling, and debugging. Let me know if there is any way around this issue with VisualGDB. Thanks!!!
Hi,
Yes, you can make a workaround. First of all, if you are flashing your program using the bootloader (or any other way that ensures correct FLASH layout), you can simply disable “program FLASH memory” checkbox in VisualGDB Project Properties and VisualGDB won’t touch the contents of your FLASH memory.
Alternatively you can get your bootloader code included into the resulting ELF file during build. This can be accomplished by declaring an array containing your bootloader code, placing it into a separate section and modifying the linker script to put this section at the beginning of the FLASH. I.e. you will first need to generate a file like this from your bootloader image (.bin file, not the .elf file):
__attribute__((section(".bootloader"))) char test[] = {0x01, 0x02, ...};Then you need to change the linker script to put the .bootloader section before anything else:
SECTIONS { .bootloader : { . = ALIGN(4); KEEP(*(.bootloader)) FILL(0xff) . = 65K; } > FLASH
...
}Please double-check everything by reading the .map file (or looking at the generated .bin file).
P.S. The FLASH Security bits mentioned in the previous post are used by Freescale Kinetis devices, so you don’t need to worry about them if you are using STM32.
Hi,
this thread would benefit from clarification what’s a valid ISR vector placement.
The two methods mentioned here are simple loader script MEMORY FLASH ORIGIN editing or placing your function in a specific section.
How does that interplay with custom bootloaders (stmduino, etc…) which locate themselves at 0x8000000 and jump to e.g. 0x8005000 for non-bootloader mode?
Hi,
If the bootloader expects the non-bootloader code to be placed at a specific address (e.g. 0x8005000), the easiest way to achieve this is to add a line like this before the corresponding section in your linker script:
. = <offset to place subsequent code/data>
You can double-check the addresses of the code and variables by enabling the map file generation and looking through the map file once the build is done.
Thanks, I’ll have to look more into linker scripting.
First it seemed odd there’s no simple way to selectively write memory regions but I guess that’s to do with the flash block-size grain limitation.
Other debuggers probably have a copy-modify-writeback function? Feature Request?
Hi,
No problem. Could you provide an example of the copy-modify-writeback function you mentioned? Do you mean software breakpoints in FLASH memory?
Sorry, I was still referring to flashing (http://stackoverflow.com/questions/23895253/how-to-erase-just-some-bytes-of-flash-memory).
If a device has a block size of, say, 1 KB, that would still permit flash editing at that granularity, so I’m not sure if that’s the problem.
Hi,
Thanks for clarifying this. Normally the FLASH programming is handled by OpenOCD, so supporting special programming modes would involve creating an OpenOCD patch.
As this feature looks like something very specific to certain bootloader types, we would not be able to give it enough priority to push it into one of the next releases. Sorry about that.
Our best advice would be to submit a feature request to the OpenOCD community.
- You must be logged in to reply to this topic.