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 support@ccsinfo.com
Bootloader for dsPic33

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



Joined: 28 Jun 2018
Posts: 10

View user's profile Send private message

Bootloader for dsPic33
PostPosted: Wed Sep 12, 2018 4:43 pm     Reply with quote
Greetings all!

I'm currently working through an issue with a bootloader I'm building, and am hoping for some insight.

Currently I'm targeting the dsPIC33EP512MU810, and one of the details with this chip is that the first page of ROM cannot be erased by the program when code protect is turned on.

The issue this causes, is the application's interrupt vector would change location if/when the bootloader changes in size during a specialized update. The solution I'm trying for is to relocate the application's interrupt vector to the end of ROM instead at the start of the application image. However, the compiler I'm using (5.080) seems to stick any variables declared with the 'rom' modifier at the end of available space, regardless of the order of declaration. I also don't seem to be able to declare an org that can limit code placement to the remaining application area.

Here's some code demonstrating my issue.

Code:

#include <33EP512MU810.h>
#device ICSP=1
#use delay(crystal=20000000)


#build(interrupt=0x55200)

#int_default
void int_default() {

}

rom int bigrom[1024] = {0};


void main()
{
   while(TRUE)
   {
      //TODO: User Code
   }
}


And the resulting output of the compiler

    Compiling C:\Code\bug-tests\interrupt-rom\main on 12-Sep-18 at 16:24
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 00000-00002 (0004 used) Priv
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 00004-0FFFE (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 10000-1FFFE (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 20000-2FFFE (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 30000-3FFFE (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 40000-4FFFE (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 50000-552A8 (0000 used)
    --- Info 300 "main.c" Line 26(1,2): More info: Segment at 552AA-557FE (0556 used) Priv
    --- Info 300 "main.c" Line 26(1,2): More info: Attempted to create: 55200-555F6 for ISR
    >>> Warning 202 "main.c" Line 13(9,15): Variable never used: bigrom
    *** Error 126 "main.c" Line 26(1,2): Invalid ORG range
    1 Errors, 1 Warnings.
    Build Failed.


Any thoughts or help would be greatly appreciated.

Cheers!
jdean



Joined: 28 Jun 2018
Posts: 10

View user's profile Send private message

PostPosted: Thu Sep 13, 2018 4:13 pm     Reply with quote
Just an update on my progress working through this...

It is indeed the interrupt vector, as defined by the #build line which is colliding with the rom modifier array. The same error appears even if the default interrupt handler is not defined.

I have found a workaround by using the const modifier instead, in combination with the #device const=rom declaration. This instead places rom constants in low memory, which sidesteps the issue.

There are however two reasons I've avoided using #device const=rom up to this point.
    1 - const is used pretty liberally in the CCS driver code, and I'm leery of the added runtime overhead of doing table reads in code that I'm not actively maintaining.
    2 - const variables are permitted to be optimized away by the compiler, and we have some cases where it would be better to have the full data array in rom regardless of whether or not it's referenced by code in the current module

I'm up and running with what I've found, but now I'm wondering, is this a legit issue I should report to CCS?

Many thanks!
jeremiah



Joined: 20 Jul 2010
Posts: 1315

View user's profile Send private message

PostPosted: Sat Sep 15, 2018 9:31 pm     Reply with quote
I'm not sure you can move the IVT. My experience with #build(interrupt=____) is that it basically creates a jump table at the address you specify and the original IVT points to that jump table. This is so you can have the application write its own ISR instead of relying on the bootloader. However, it doesn't free up that space as that space is still used.

Now I didn't look at the datasheet for this PIC, so if it has a fuse or something that lets you move the IVT, that's different, but #build isn't normally able to physically do that on its own.

Normally, the first and the last pages of flash on a PIC are offlimits when it comes to flashing an application from a bootloader.
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