All, We are designing a "loader" for field firmware updates. Unfortunately we do not have the code space (P89C668) to have two sets of code in on-chip flash. Therefore we will use a scheme where we have the loader code located in sector one and all the ISRs in sector zero as the loader will use interrupts. The rest of the application will be in sectors 2 and up. The loader will erase the upper sectors and program the new code there. It will then erase sector zero and reprogram the vector table and the ISRs. Block one, the loader, will remain unchanged. Questions: I think I can locate the code in sector one and the ISRs in sector zero using user classes. I have done this with some ARM code in uVision. How can I be sure that the loader will have all the run-time modules it needs in sector zero? In other words, I cannot have the loader calling code in sectors that have been erased. It will have to be completely self contained except for the ISRs. Is this a reasonable plan? Anyone have a better way to do this? Rich
DO visualize wha will happen with your scheme if power fail at any time during the process. I have seen more dead chips due to this than anything else. If you decide to go ahead with a scheme where such can happen, at least socket your processor. Erik
Without the space to duplcate the code there is not much option.
When installed, the units are not accessible.
But the connectot I suggest will be
But the connector I suggest will be
Erik, are you helping? ;-) Actually I appreciate the replies. The plan du jour is to have the loader in one sector which does not use interrupts or libaries. When the loader starts the BV is changed to the loader entry, that way, if power should fail etc, we end up back in the loader. Once the loader has downloaded and verified all code we reprogram the BV to FC in case we need ISP in the future. Then we let the WDT timeout. The units are not acessible at all, only the network is. Rich
We have the same problem in a number of products. Our solution is to put the boot loader and the interrupt vectors in the first part of memory ... in our case the first 4k. We have the application start at 0x1000, while the Boot starts at 0x100, the interrupt vector processing is the only code at 0. Do this by relocating the interrupt vectors (see C51 TAB in uVision) and changing the StartUp.A51. We reserve an unused interrupt vector block in the application to keep a checksum that is generated by the Boot after successful download. The actual interrupt code uses the same scheme that RTX uses ... ie. we set a bit (RTX uses F0) to indicate that we are in the boot. If an interrupt occurs while in the boot, we use an AJMP to 0x103 + (8*Int#). If an application interrupt occurs we do a LJMP to 0x1003 + (8*Int#). The two jumps and the JNB InBootBit all fit in the standard 8 byte interrupt vector slot. When the processor is reset, the Boot executes first and jumps to 0x1000 if the application checksum is valid. If not it simply waits for download. In this manner, the boot is really simple and handles the TxEnable and any other special stuff.
that way, if power should fail etc, we end up back in the loader As long as you have that the rest should be easy. This is THE most important loader feature. Erik
Do this by relocating the interrupt vectors (see C51 TAB in uVision) and changing the StartUp.A51. A "window" for failure. The "relocating" consist of storing LJMPs in the page zero slots and if power fail during that process, you are screwed. Erik
No it doesn't. The vectors are constants that are never overwritten. Only the application code is erased ... thus invalidating the application checksum.
Do this by relocating the interrupt vectors .... A "window" for failure. "relocating" consist of storing LJMPs in the page zero slots and if power fail during that process, you are screwed. .... No it doesn't. The vectors are constants that are never overwritten. In order to have a "different interrupt vector" or "ISR location" you MUST write to e.g. address 3 or somewhere that is addressed by whatever it vectors to. There is NO WAY you can change the processing of an interrupt from "loader" to "application" without writing something affecting the interrupt path to code memory. And even the best engineered such change can fail with power loss. You can not change interrupts between the loader and the app without risking access loss. Erik
Sometimes code is worth a thousand words. We use three modules: 1) FakeInts ... shown below 2) The boot loader 3) The application The boot loader has it's interrupt vectors starting at 0x100. The application has it's starting at 0x1000. After initial programming of FakeInts and BootLoad, they are "never" changed. The FakeInts source is shown below:
;------------------------------------------------------------------------------ ; FakeInts.a - Dummy Interrupt vectors for the Universal DownLoad Program ;------------------------------------------------------------------------------ ; To translate this file use A51 with the following invocation: ; ; A51 FakeInts.A DnlBase Equ 0100H ; DownLoader base address AppBase Equ 1000H ; Application base address CSEG AT 0 Ljmp DnlBase ; Start application IntVect Macro Num CSEG AT 8*Num+3 Jnb F0,$+5 Ajmp DnlBase+(8*Num+3) Ljmp AppBase+(8*Num+3) Endm IntVect 0 ; INT0 - External Interrupt IntVect 1 ; T0 - Timer 0 Interrupt IntVect 2 ; INT1 - External Interrupt IntVect 3 ; T1 - Timer 1 Interrupt IntVect 4 ; SP - Serial Port Interrupt IntVect 5 ; T2 - Timer 2 Interrupt ; Modify from here on as needed for your microprocessor specific interrupts IntVect 6 ; PCA - Programmable Capture Array Interrupt End
what (re)set F0? Erik
DUH! If it is a InBootLoad bit, the BootLoader must have to set it, right? Since Keil uses this bit for their own internal uses ... much like I did ... and the compiler never generates code for it, it seemed to be a good choice for this example. Jon made a comment one time that stated that you and Andy are two of only a handful of people who really understand this micro. If that is so, and you are a frequent supplier of info in this forum ... it would be nice if you would share your wisdom rather than scorn. I was just trying to help out.
"Jon made a comment one time that stated that you and Andy are two of only a handful of people who really understand this micro." I think he actually said: "There are only 4 developers in the world who understand and get benefit from PDATA (Andrew, Graham, Drew, and Eric) :-)" http://www.keil.com/forum/docs/thread3882.asp
All, I know this thread is several months old, but it has recently provided me a technique for our BootLoader to use, but there is an issue to be considered. First, Bob, thank you very much, this is a cleaver techique and to the best I can invision so far, it appears to be solid. This will allow us to have ISR's in the BootLoader. We will be loading this FakeInt into sector 0 during manufacturing setup and it will never change. The extra 256 bytes in sector 0 will also store some constant board information (serial number, ...). The issue: We found that when you perform a type cast of a float, the F0 bit will get reset back to 0. I contacted Keil support on this issue and they confirmed that F0 is used by their libraries. They referred me to this support page http://www.keil.com/support/docs/2893.htm , which references using UD:F1 as a bit for users to safely use. Danny
"it would be nice if you would share your wisdom rather than scorn." The problem is that you have achieved the impossible. If you had admitted earlier in the thread that it couldn't be done everything would have been fine, but instead you've had the temerity to post a solution. Shame on you!
>i>Q: what (re)set F0? A:DUH! If it is a InBootLoad bit, the BootLoader must have to set it, right? .... it would be nice if you would share your wisdom rather than scorn." Now, Stefan I challenge you to find ANYWHERE in this thread before my question whare it is stated that F0 is "a InBootLoad bit". I suggest you save your bile for those that get p***ed off when the one that try to help does not have ESP to percieve what is not stated in the question. Erik
Note This message was edited because of rude or abusive language.
"Now, Stefan I challenge you to find ANYWHERE in this thread before my question whare it is stated that F0 is "a InBootLoad bit"." Uh, ok - from Bob's first post: "The actual interrupt code uses the same scheme that RTX uses ... ie. we set a bit (RTX uses F0) to indicate that we are in the boot."
scheme that RTX uses ... ie. we set a bit (RTX uses F0) this states that "we" use "a bit" and it states that RTX uses F0 WHERE does it state which bit "we" use? Erik I have no problem asking, I just have a problem when the one that ask for help get p***ed at me because he can not express himself clearly. The fact that you, Stefan, immediately jump on the wagon does not make it any better.
"WHERE does it state which bit "we" use?" Well, taking the quote as a whole I think it's pretty clear. Chopping the quote up into little bits is bound to suck out all the meaning, a favourite technique for trying to find non-existent support for one's argument. Anyway, this is all an irrelevant smokescreen. What Bob was complaining about was not your failure to understand what he said, but your insistance in your previous posts that what he has done could not be achieved. "The fact that you, Stefan, immediately jump on the wagon does not make it any better." I waited nearly ten months. "I have no problem asking, I just have a problem when the one that ask for help get p***ed at me because he can not express himself clearly." Oh dear, you're all confused again. The one who 'got p***ed' at you was not the person asking for help, it was the one who offered a solution but was treated with scorn.
"WHERE does it state which bit "we" use?" Well, taking the quote as a whole I think it's pretty clear I use soap, and so does joe who uses Dial. Does that tell you which soap I use. Erik
"I use soap, and so does joe who uses Dial. Does that tell you which soap I use." Is this supposed to be an analogy? I don't really know why you're obsessing about this F0 thing, I've never had any issue with it. However, as you seem determined to flog it to death: This is what the chap said: "The actual interrupt code uses the same scheme that RTX uses ... ie. we set a bit (RTX uses F0) to indicate that we are in the boot." He then gave a code snippet with the following line: "Jnb F0,$+5" Frankly I cannot see what you difficulty is in understanding this, and was quite surprised when you challenged me out of the blue to quote it.
I don't really know why you're obsessing about this F0 thing, I've never had any issue with it. However, as you seem determined to flog it to death: I am not "obsessing about this F0 thing", I am referring to the fact that the posters inability to post clearly and his reaction to my lack of ESP made him post: DUH! If it is a InBootLoad bit, the BootLoader must have to set it, right? ..... If that is so, and you are a frequent supplier of info in this forum ... it would be nice if you would share your wisdom rather than scorn. which you decided to repeat for no other purpose than to find another way to show how "humane" or whatever you are compared to me. Anyhow, I suggested in another thread that you stop challenging me on non-trechnical issues so i can stop responding to your crap ("your crap" does NOT refer to your technical contributions which, generally, seem quite qualified) Erik
"Anyhow, I suggested in another thread that you stop challenging me on non-trechnical issues so i can stop responding to your crap" In the threads you are referring to I responded to posts by people other than yourself. In neither response did I make any reference to you. You are the one who has initiated our exchange of posts in both these threads, the topic of which has been dictated by you, and which, I might add, has not exactly been technical. You are the one with the power to decide whether you want to post or not. Use it!
Gentlemen, While this is soooooo entertaining, perhaps, at this point in the conversation, it should be taken offline. Rich
richard, see my post in other thread Erik
But, of course, if Stefan, as suggesated before and now again, used e-mail you goys would not see how great he was. Erik
"But, of course, if Stefan, as suggesated before and now again, used e-mail you goys would not see how great he was." Erik, this sort of comment only serves to make you look foolish. Aside from anything else, how could I email you without knowing your email address?
Aside from anything else, how could I email you without knowing your email address? since you evidently do not know how to google, here it is: erikm@digrec.com
since you evidently do not know how to google Oh, I am sorry. That should have been: since you ask I will save you the trouble of looking it up, here it is: erikm@digrec.com Coddly enough? As you see, in the above there is no help for next time, just a tide you over. In the above post a method to save the waiting for a response next time such came up was included. as I say "you do it your way, I do it mine, jusr stop telling me that your way is the only way" Erik
"since you evidently do not know how to google, here it is: erikm@digrec.com" Try googling for my email address and let us know how you get on.
View all questions in Keil forum