Forum : ST7/STM8
| Post Information | Post |
|---|---|
|
February 10, 2010 - 1:54am
|
Hi, I've manage to implement a user boot-loader on the STM8A located at address 0x8000. This boot-loader allow me to upload a binary file (application) at location 0x9000. I was able to relocate my interrupt vector using INT_VECTOR(0x9008) and code example provided by Bruno posted on this forum that redirect the primary interrupt vector to 0x9000. Now that the boot-loader is working fine I can't figure out how to change my application startup code. I assume that this is somewhere in the linker option but I didn't find anything ! Can somebody help me ? Also I notice that since my boot-loader copy the new binary file over the address 0x9000 my last 128 byte that I should be writing is that specific one (0x9000) right ? As I still need interrupt while uploading new code and that my bootloader secondary interrupt table is at 0x9000. Thanks again in advance for you help and please don't refer me to a application not as I read pretty much all of them and I didn't find anything to fix my problem. Alexandre April |
Hi Alexandre,
Concerning the startup code, the linker requires some specific "STARTUP" symbol to be found in the list of the object files of the linked project. If it does find one, the external is resolved, that's it. If it does not find one, it will take the default one from the C library.
So if you need a specific startup code, the simplest is probably to take the "C:\Program Files\Raisonance\Ride\inc\Sources\ST7-STM8\startup\startup.asm" (directory may be different on your machine depending on your Ride7 installation path) and modify it appropriately.
Some tips:
It would be easier to place the startup entry point at a specific address (say 0x9080 in your case).
Then in your bootloader code, you can call your "secondary" entry point using:
Or you can use a Raisonance-specific code:
I am not sure to correctly understand your last question, but you should be writing addresses 0x9000-0xFFFF (depends on the size) when uploading new code.
Regards,
Bruno
Hi Bruno,
Thanks again for your quick reply.
Ok let me try to explain a little bit moremy problem.
First the bootloader side. As stated in one of your previous post the user bootloader interrupt vector is at location 0x8000 and is most likely to be write protect. So a redirect interrupt vector need to be implemented in the Bootloader that will rediect all vector to example 0x9000. You wrote a code example doing all this. After that you have to use the compile directive INTVECTOR(0x9000) to inform the compiler where to put the new interrupt vector table for the bootloader. So now the bootloader interrupt vector is at ox9000. I tested that and it's working. My question regarding the bootloader is since my new interrupt vector is at 0x9000, when my bootloader starts updating the flash with the new application at location 0x9000. The last page it should be updating is the one with the application interrupt vector (0x9000 - 0x907F) that will overwrite the bootloader interrupt vector because this location is still used by my bootloader ? Am i right ?
Second question regarding my application. I'm not quite sure I understand your answer. Since my new application is copied in flash at 0x9000 and that all function call and varibales within that application are absolute not relative. How can I inform the linker to generate the ouput file to that location. I tryed using the linker directive "CODE(0x9000)" but the ouput binary file got 4K bigger and he put the reset vector in the first bytes of the file and the rest of the application at an offset of 4K. Is there any other ways to do that ? I must not be the only one doing that as all the poeple using custon bootloader at 0x8000 location as to build their application and make them run at a certain offset from that default adress "in my case 0x1000 = 0x9000". Should I be using a tool to convert from my hex file to my binary file with and offset ?
One last question, is there anything I should be doing prior to jump into my new application code (disable interrupt, etc..) ?
Thanks again for all your help.
Alexandre April
Alexandre,
The interrupt vectors are used by the processor at the moment the IRQ fires. This means that when you are in your bootloader, the vector is not used anymore (I guess interrupts must be disabled during bootloading/flashing process). So you can erase the vector table whenever your want in your flash process.
However, if your flash process requires some interrupts (I hope not!), then you will have to write your vector table last, after the last interrupt required for the flashing process has occurred.
Concerning your second point, you can use the linker directive "RESERVE(CODE,0x8000-0x9000)", which will not use this flash area during the link.
Regards,
Bruno
Hi,
Again thanks for the quick reply.
I do need interrupt to receive the new binary file cause It programmed in flash in a page basis (128bytes) but when i do write in flash there's no interrupt required.
As for the "RESERVE(CODE,0x8000-0x9000)" is it gonna generate an binary file with a 4K filled with 0xFF at the beginning or the binary file will hold only application code ? My question is, does the reserved memory is gonna be part of the binary file or not ?
As for my last question regarding the jump preparation. Do I need to disable interrupt or do anything special before my bootloader jumps into the user application ?
Alex
Hi Alex,
Once you receive the last page of your binary file (which should be the 9000-90FF page) you can just disable interrupts.
Once written, you can reenable interrupts (if they are already properly setup) then jump to your application.
The AOF file generated by the linker will not consume any reserved space This should be OK. Same for HEX files if you want these. Concerning the BIN files I do not recommend that you use them, as they will be error-prone (they inherently contain the offset).
Regards,
Bruno
Hi,
How can I use that file ? Where can I get the specification for the file format ?
I looked around and AOF have many meaning ARM-Obejct-File, Absolute-Object-File, ACorn-Object-File. Which one is it ?
Can you provide any usefull information so that I can use that file instead of the biary one ?
Alex
Hi Bruno,
I just tried the RESERVED linker directive and there's still the reset vector at the beginning of the file (offset 0). and I get the rest of the interrupt vector at offset 0x1000 (0x9000 in the device memory).
Is there any other linker directive that would solve my problem.Because i dont think that using the hex file or the AOF file will solve my problem as my binary come from both of them.
Anyone as done this before ??? Build a user bootloader to update a user application at speciic address ??
Alex
Hi Alex,
Keep cool, you're in a safe place. Yes other people are doing this! ;)
In such cases looking at your .map file is the most helpful reaction. Reset vector is mapped? Let me guess: The solution is in your startup: You need a startup *without* any reset handler (as the application has its entry point at the absolute 0x9080 address).
Just remove the reset vector from the startup file and it should be ok.
Regards,
Bruno
Hey,
Sorry not enough sleep ;o)
Can I copy that startup file over my project ? Or it as to be modify there and used for every project ?
As for the AOF file how can I use that to update my application in flash! Do you have any specicification ?
Again... you're beeing very helpfull and i appreciate it! Thanks
Alex
Hi Alex,
The startup sources are provided for your information, you can do whatever you please with the sources, it won't bother the compiler or linker. The best however is to copy the file in your application's directory and add it to your project from there.
Concerning the AOF format, it is an Intel specification, but you should not use it as it is very complex. Just select the "Generate a binary file" or "Generate an hex file" in the Ride7 linker output options. The output file will then be easy to handle in your bootloader process.
I'm glad you appreciate our help :cool:
Regards,
Bruno