CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

#BUILD(ALT_INTERRUPT)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

#BUILD(ALT_INTERRUPT)
PostPosted: Thu Dec 03, 2020 3:00 pm     Reply with quote

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: 9243
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Dec 04, 2020 6:21 am     Reply with quote

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: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Dec 04, 2020 10:35 am     Reply with quote

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: 19540

View user's profile Send private message

PostPosted: Fri Dec 04, 2020 10:43 am     Reply with quote

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: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Dec 04, 2020 11:18 am     Reply with quote

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: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Dec 09, 2020 10:44 am     Reply with quote

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: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Dec 09, 2020 10:48 am     Reply with quote

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: 1354

View user's profile Send private message

PostPosted: Wed Dec 09, 2020 11:44 am     Reply with quote

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: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Dec 09, 2020 12:08 pm     Reply with quote

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 ?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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