 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
| #BUILD(ALT_INTERRUPT) |
 Posted: Thu Dec 03, 2020 3:00 pm |
 |
|
Reference - posts by jeremiah:
http://www.ccsinfo.com/forum/viewtopic.php?t=58170&highlight=altivt
On a chip like PIC24FJ64GA004 we have two vector tables available, and a register bit that can toggle which one to use. Jeremiah gave an example:
| Code: | // compiler bug workaround
#BIT ALTIVT = getenv("BIT:ALTIVT")
// Bootloader main
void main(void)
{
// Setup interrupts for bootloader
ALTIVT = TRUE; |
My system splits up the flash into two partitions, A and B. The .hex file for A would be:
IVT
Program A
The .hex file for B would be:
IVT
(nothing until the start of B)
Program B
When running from A and doing a firmware update, it stats writing the B data over the B partition, then as a last step, it updates the IVT.
Today I realized this is the source of some failures I occasionally see, since the vector table is being reprogrammed out from under the running code.
To solve this, I'd like to try this:
A)
IVT (normal)
skip ALTIVT
Program A
B)
skip IVT
ALTIVT
Program B
The idea is for a final step when updating B would be to update the RESET entry of the IVT to point to Program B. The next power cycle will start at B, which uses ALTIVT.
I am trying to maintain compatibility with existing systems, and do this only through generation of a new .hex file and adding a "if I'm B, use ALTIVT" and a "set RESET vector" when programming.
Am I on a path of light, or a path of dark, here?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9108
Location: Greensville,Ontario
|
|
| Posted: Fri Dec 04, 2020 6:21 am |
|
|
I'd like to see THREE IVTs.
1 for the bootloader
1 for program 'A'
1 for program 'B'
While I don't know how it can be done, having a table of IVTs that could be selected,say within the bootloader ? or 'menu selection' ? should allow the PIC to run any program. To me it's 'similar' to having multiple 'users' in Windoze.
Jay |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Dec 04, 2020 10:35 am |
|
|
| temtronic wrote: | I'd like to see THREE IVTs.
1 for the bootloader
1 for program 'A'
1 for program 'B'
While I don't know how it can be done, having a table of IVTs that could be selected,say within the bootloader ? or 'menu selection' ? should allow the PIC to run any program. To me it's 'similar' to having multiple 'users' in Windoze.
Jay |
I've found that two of the PIC24 variants we use don't support ALTIVT, so I'm going to need to redo our firmware update process anyway, so my bootloader code may get used.
It "seemed" that just using that #BUILD keyword took care of everything I needed, but when I am running our A partition code and load in B code, the B code does not run. But it runs if I load directly, so I'm investigating that today.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19222
|
|
| Posted: Fri Dec 04, 2020 10:43 am |
|
|
From what you are descibing, the thing that I think applies, is that the
IVT's would both need to be 'rebuilt' if the subrooutines change at all. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Dec 04, 2020 11:18 am |
|
|
| Ttelmah wrote: | From what you are descibing, the thing that I think applies, is that the
IVT's would both need to be 'rebuilt' if the subrooutines change at all. |
We really just need to move to a bootloader -- solves this issue, and allows recovery if a bad load bricks the board.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Dec 09, 2020 10:44 am |
|
|
I ran in to a snag trying to implement my workaround.
When I do a build using this ALT statement, and load it directly, the board will boot and run.
If I am running and firmware update, it doesn't run after a reset.
It looks like I may still have work to do with reprogramming the vector table (IVT).
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Dec 09, 2020 10:48 am |
|
|
| Ttelmah wrote: | From what you are descibing, the thing that I think applies, is that the
IVT's would both need to be 'rebuilt' if the subrooutines change at all. |
Yeah this would be during a firmware update, and the vector table is part of the HEX file anyway.
From the datasheet, I suspect it would look like this:
| Code: |
----------------------------------------
0 - GOTO
xxx rest of IVT A - pointing to code in A
----------------------------------------
ALT IVT (GOTO not used)
xxx rest of IVT B - pointing to code in B
----------------------------------------
xxxx A partition code.
----------------------------------------
yyyy B partition code.
----------------------------------------
|
When running A, and loading in the B firmware, we first write all the B data, then write the vector table range so it updates the 0 GOTO to point to B, and the IVT ALT vector tables to point to B.
But, after a restart, it does not run. If I load the "B" .hex file directly using CCSLOAD, it does run.
I suspect there is something in our vector table programming that needs to be updated. Or maybe this can't be done at all.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1317
|
|
| Posted: Wed Dec 09, 2020 11:44 am |
|
|
Is your alt IVT and IVT on the same erase page? If so you won't be able to do it without wiping the current IVT first. If they are on separate pages, then I feel like you can do that. They are on the same erase page for my chip I think though, so I am guessing they will be for you as well.
Basically if they are on the same page, you'll have:
Initial programming (Program A with primary IVT)...check!
Load Program B (overwrites the ALT IVT)....still good, it wasn't written before
Load Program A (overwrites the primary IVT)....hmmm...already written to before so we must erase before writing, but it erases the alt IVT too.
You can work around it by disabling interrupts during the IVT update, cache the "current" IVT in RAM, erase the page, then write both the cached IVT and the new one together and re-enable interrupts. Whether that works for you though is dependent on your program needs. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Dec 09, 2020 12:08 pm |
|
|
Great observation. I’ll check the size, as that would explain it. Updating IVT would erase IVT ALT. Makes sense.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
