Forum : ARM
| Post Information | Post |
|---|---|
|
August 2, 2011 - 9:12am
|
I'm taking baby steps toward writing a bootloader for the STM32 connectivity-line parts. My first step is to try and get a binary that I can run from a non-default flash address. I've been using ST AN2557 as a template. To that end, I modified the default linker script to put the flash base address +0x3000 from its original location. I also shrank the flash size by the same amount. Following the directions in the AN2557 PDF. Looking at the memory view window (and the map file in the listings directory), it seems as if my code has indeed moved to 0x08003000 as expected. The problem is that I get an error when I try to debug the program (in-circuit). I get a message that pops up: When I try to compile the example IAP/binary/RIDE project provided with AN2557, I also get a debugging limitation error. For reference, here's the line in system_stm32f10x.c which sets the vector offset: ...and here's what I've done to my linker script: Any insight in to how to pursue this problem would be much appreciated. Thanks! |
Hi,
Just include the hex or elf file containing your bootloader in your project as if it was a source file.
For debugging the IDE must be aware of the complete content of the memory. This implies that when debugging a "bootloaded application", you must provide the debugger with the code (hex or elf) of the bootloader. Otherwise there is no way the execution will reach the start of your application, SP is not initialized and you can expect the IRQs to go wild.
More information here:
http://forum.raisonance.com/viewtopic.php?id=3676
And look at the CircleOS applications as examples.
Best Regards,
Vincent
Thanks for the help! As a test I wrote another program with a jump to a fixed memory address to test to see if my code would execute from the nonstandard location in flash, even though I couldn't debug it. Turns out that it works - I created the hybrid file by dumping both projects to .bin files and manually merging them with the correct offset using a hex editor. Execution of the first program works as expected and so does the jump to the second program.
It's pretty cool that you can add an elf file to a Ride project, but I'm not sure what to expect - right now I'm away from my hardware and am working with my laptop only. When I include the bootloader elf file, compile the project, and look at the resulting bin file (again using objcopy), I don't see code at 0x0 and at 0x1000 - it's all one contiguous block. Is there something different I need to do to make a .bin file that includes both programs?
I really appreciate your input!
Cheers,
Sasha
Hi,
When you add an hex or elf file in a project, it is not included in the link, but only in the programming and debugging.
If you want to have the two parts in a single hex file, you have to merge the two hex files. There are free utilities on the internet for doing this, or you could do it using RFlasher, or simply read-back the content of a device that you programmed with both parts.
Of course you could include the bootloader directly in the link of your application. For that you'd have to add the source or .o files (or .lib) of the bootloader, and then meddle with the ld file a little more. Once again the CircleOS and its applications are good examples. Look at the project that is used to debug the CircleOS itself.
Finally, I strongly recommend against using bin files in any situation. hex files are always preferable and bin files are often source of mistakes, especially when dealing with offsets, merges, etc. like you are doing.
Best Regards,
Vincent
You've been incredibly informative and I feel I have a much better grasp of how the tools work.
Edit: I should be more clear - everything works now!
Thank you very much!
-Sasha
This thread has provided a lot of useful info, but I am hitting a very similar problem to what Sasha did and haven't figured out an answer yet. Here's what I've done:[=*]
And I changed the LD Linker Scripts entry in the IDE to not use the default scripts and instead point to my (now RO) copy of STM32F103_512K_64K_FLASH.ld, which includes the STM32F103_512K_64K_DEF.ld file.[/*]
Each of the above is in separate .rprj and .rapp, and both work fine separately. I can flash the DFU firmware (using the IDE), boot the part, DFU down the app, reboot, and have the app run. The app can successfully initiate DFU operation to download a new version of the app. So far, so good.
Now what I would like to do is be able to do is use the Ride7 IDE to build, flash, and debug the app, rather than DFU it down. I added the DFU.hex file to the top level Project container, and when I use the "Start Debugging" button I do see it flashing address 0x08007000 onwards. However, the debug output window shows that the PC is FFFFFFFE and the description is "Out of code". I tried changing Advanced ARM Options/Debug environment to put Code Offset at 0x7000, but this did not help - same "Out of code" issue. The part is bricked after this, and has to be re-flashed directly using the DFU project to even run the DFU.
Any help would be most appreciated!