|
September 18, 2012 - 1:20pm
Guest |
Hi,
I am working on the low density STM8.
I understood the following:
- By default there is only the reset interrupt defined at first address of flash memory i.e 0x8000, which directs the control to the main() routine. At this time I did not create define any interrupt functions, and I found the main located 0x8004.
- After I defined all the remaining 31 interrupt functions, Raisonance automatically has build the interrupt vector table spanning 0x8004 to 0x807C
- The main entry function is seen to be located at 0x8080.
All this seems to be good.
Now I want to define the UBC region.
In order to make the interrupt vector table available outside the UBC region, I have read that I should redirect the table to region outside UBC, where the memory is writable.
Now my question is, what if I directly use the directive INTVECTOR and force Raisonance to build the interrupt vector table at say 0x9000.
Why should one build the interrupt vector first in UBC region and redirect them.
Why not build them directly outside the UBC using INTVECTOR?
What am I missing here?
Thank you,
Pradeep
|
May be I understand it.
If the bootloader and application firmware are in separate projects, and the bootloader has the interrupt vector table, then the vector table will be programmed into the UBC.
The application firmware has to redirect it outside UBC, to make any changes.
I was confused because I was thinking of having the bootloader and application firmware all in one single project.
-------------------------
As part of this understanding, I have one other question:
Is it possible to program only part of the flash memory using ICP?
I have programmed the flash with bootloader using ICP, where UBC is protected from 0x8000 to 0x8fff.
Next, when I try to program the flash with application firmware separately using ICP with CODE settings 0x9000 to 0x9fff, I am encountering an error that UBC is enabled. Why does the programmer care about UBC, when CODE settings are outside the UBC enabled region?
Just to try, I disabled the UBC. But then everything in the flash is reprogrammed i.e the UBC region is erased. The MAP file is shown below, and it has no code segments in the UBC region.
LINK MAP OF MODULE: DEBUG\STM8_SOFTWARE.AOF (MAIN)
TYPE BASE LENGTH RELOCATION SEGMENT NAME
---- ---- ------ ---------- ------------
* * * * * * * * C O D E M E M O R Y * * * * * * * *
009000H 000080H *** GAP ***
CODE 009080H 000006H AT ?PR??APPLICATION_MAIN?MAIN
009086H 00037AH *** GAP ***
CODE 009400H 000003H AT ?PR??TASK_CHECK_SOFTWARE_UPDATE?TASKS_ALL
Thank you for helping me out.
Hi,
By design the STM8 hardware will always use the vectors located at 0x8000. You cannot tell it to get the vectors at x9000 instead.
So you need to add a redirection table @x8000 in your nonwritable zone and then your system will use your new (writable) vectors @x9000.
The INTVECTOR directive will tell the compiler to place the pointer to the ISRs at x9000 instead of x8000, but it will not create the table because there is no universal way of doing it. Some bootloaders will redirect only some vectors but not others, and the compiler cannot guess that. So you have to do it yourself.
I hope it helps.
Best Regards,
Vincent
Hi,
My previous post was an answer to your first post, and it crossed your second post... Now about your second post...
When writing bootloaders and/or bootloaded applications, you need to create one Application (in the way Ride means it, which is different from a Project. see the Getting Started doc. The distinction is important for what you do) for the bootloader and another Application for the bootloaded application. This will create two output files. (.aof/.hex for STM8) We usually do this by reating two Applications in the same Project. (again, see Getting Started doc. Be sure you are clear with all these terms)
Then, to program and debug the bootloader, just do it as if it was a simple single-application project.
To program a bootloaded application without debugging it, use the bootloader itself. Or you can program both the bootloader and the application in one time using ICP.
To debug a bootloaded application, you'll need to add the output file (aof or hex) of the bootloader in the list of input files of the bootloaded application, exactly as if it was a source file. Use the aof if you plan to debug both the bootloader and the bootloaded application. Use the hex is you just want to debug the app.
In any case, for debugging you must remove all protections, including UBC. (as example, for setting breakpoints the debugger needs to modify the memory)
I hope it helps.
Vincent
Hi Vincent,
Thanks for the clear explanation.
I have my project setup and I am now clear about software update concept.
I still have a question about my linker settings.
- I have the bootloader starting at 0x8080.
- I restricted functions related to application using the relocation directive:
CODE(?PR??APP_MAIN?APP_MAIN(0x09080), ?PR??TASK_CHECK_SOFTWARE_UPDATE?APP_MAIN)
- I have UBC to be 1024 bytes.
Since I did not restrict the bootloader region, I noticed that the bootloader functions starting at 0x8080, also occupied region beyond 1024 bytes.
I would like to restrict the bootloader to 1024 bytes.
I want to see something like Code overflow if bootloader is bigger than 1024 bytes.
With the help of relocation directive, I am only able to specify the start address.
I think what I want to do is, restrict some functions to a specified region in memory.
i.e
restrict the bootloader functions to 0x8000 to 0x83ff
restrict the application functions to 0x8400 to 0x9fff
I could not make out how to do this from the documentation on linker.
Can you please let me know.
Thank you,
Pradeep