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

Bootloader questions with dsPIC30F6014A
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
jeremiah



Joined: 20 Jul 2010
Posts: 1353

View user's profile Send private message

PostPosted: Tue Feb 11, 2014 8:27 pm     Reply with quote

We typically run at 9600. I've never tried to go much higher because we have a specialized homebrew downloader (made with visual c++ as well) that was in existance before I came along. It would have taken some retooling to make it faster and I've never had the time to mess with it.

EDIT: Technically, I'm not even sure it runs that fast, that's just the baud setting on the com port. We have some interesting handshaking protocols involved, so that might actually slow it down more. I would have to scope it to be sure.
naughty_mark



Joined: 29 Aug 2012
Posts: 97

View user's profile Send private message

PostPosted: Tue Feb 11, 2014 8:38 pm     Reply with quote

jeremiah wrote:
We typically run at 9600. I've never tried to go much higher because we have a specialized homebrew downloader (made with visual c++ as well) that was in existance before I came along. It would have taken some retooling to make it faster and I've never had the time to mess with it.

EDIT: Technically, I'm not even sure it runs that fast, that's just the baud setting on the com port. We have some interesting handshaking protocols involved, so that might actually slow it down more. I would have to scope it to be sure.

Thanks for your help, it is clear now~
Actually, my 115200 baudrate is not real 115200 as you said, like handshaking, flash program waiting time etc.. Just the transfer speed for a data block is 115200bps.
9600bps might be slow for production in this project, it looks I have to write a program at PC side to achieve higher speed.
Thanks for all your help, I do appreciate.
PIC18



Joined: 28 Aug 2011
Posts: 3

View user's profile Send private message

Problems with IVT on PIC24HJ
PostPosted: Sat Feb 22, 2014 3:04 pm     Reply with quote

Hello everyone.

I'm using version 5.015 with PCD pic24HJ128GP502.

I have a HTTP bootloader installed done for me in the pic, the boot works well then downloads the application of a http server and install correctly.
My problem is in the application.

I set the reset vector at 0x5630 and Interrupt Vector Table at 0x5634, I have also used the #org to prevent overwriting the boot.

Code:


#build(stack=256)        //the compiler uses 128 instead and an stack overflow is produced
#build(reset=0x005630,interrupt=0x005634)                                     
#org 0x000000,0x000003 {}             //boot reset vector (4 Words)
#org 0x000004,0x0001FF {}              //boot IVT
#org 0x000200,0x005628 {}              //boot code




Installing a simple application like that, all works well.

Test App:
Code:

void main(void)

   fprintf(DEBUG,"DEBUG:APP RUNNING...\r\n");
   while(TRUE)
   {
     delay_ms(1000);
     fprintf(DEBUG,"DEBUG:MAIN LOOP\r\n");
   }
}



The problem arises to use interrupts, it is assumed that by declaring a directive (#int_xxx),
the compiler must write to the IVT in the position corresponding to the defined interrupt vector, the direction of ISR, as it does in the boot,
but in instead write a GOTO instruction with the address of the ISR and obviously an address Error occurs.

Here I put the two IVT that I see that are different

Interrupt Vector Table of Boot:
Code:


00000:  GOTO    405A
*
00008:  DATA    6E,0B,00
0000A:  DATA    DE,0B,00
0000C:  DATA    16,0C,00
*
0001A:  DATA    EC,0A,00
*
00022:  DATA    98,0C,00
*
0002A:  DATA    4E,0C,00





Interrupt Vector Table of Applicacion:
Code:


05630:  GOTO    5A90
*
0563C:  GOTO    5976
05640:  GOTO    59E6
05644:  GOTO    5A1E
*
05660:  GOTO    58F4




Any tips?

thanks
jeremiah



Joined: 20 Jul 2010
Posts: 1353

View user's profile Send private message

PostPosted: Sat Feb 22, 2014 11:11 pm     Reply with quote

EDIT: You really should start your own thread. It hurts how much help you get by doing this. Maybe ask a mod to split the thread for you.

Did you #rom the bootloader code IVT to the correct location? It looks like your bootloader locations for the ICR is either setup to point to a different location than your application or has other code in it.

I would have expected the addresses of your application IVT to be stored in the bootloader IVT, but I don't see that. That would cause a lot of problems.

EDIT:
As an example, in one of my example bootloaders, I do something like this:

Code:

//App IVT entries are spaced twice as far apart as Bootloader IVT entries
//due to using GOTO commands (4 WORDs) instead of just addresses (2 WORDs)
#define REMAP_IVT_ENTRY(entry) \
   #ROM entry = {0x00FFFFFF & ((entry-BL_IVT_START)*2+APP_IVT_START)}

//Remap the IVT using the APP IVT location to keep the compiler from
//not wanting to let you remap the IVT here.  This doesn't generate any code,
//but lets the #ROM and #ORG statements work
#BUILD (interrupt=APP_IVT_START)  //must do this to remap IVT table

//IVT Mapping to application code space
//To mass generate these, use a compiler with output with the following
//code:
//for(int i = 0x0004; i < 0x0100; i+=2){
//   printf("REMAP_IVT_ENTRY(0x%04x)\r\n",i);
//}
REMAP_IVT_ENTRY(0x0004)
REMAP_IVT_ENTRY(0x0006)
REMAP_IVT_ENTRY(0x0008)
REMAP_IVT_ENTRY(0x000a)
REMAP_IVT_ENTRY(0x000c)
REMAP_IVT_ENTRY(0x000e)
REMAP_IVT_ENTRY(0x0010)
REMAP_IVT_ENTRY(0x0012)
REMAP_IVT_ENTRY(0x0014)
REMAP_IVT_ENTRY(0x0016)
REMAP_IVT_ENTRY(0x0018)
REMAP_IVT_ENTRY(0x001a)
REMAP_IVT_ENTRY(0x001c)
REMAP_IVT_ENTRY(0x001e)

#ORG 0x0020,0x01FF{} 


The hex generated:
Code:

ROM data:
000004: 0404 0000 0408 0000 040C 0000 0410 0000
00000C: 0414 0000 0418 0000 041C 0000 0420 0000
000014: 0424 0000 0428 0000 042C 0000 0430 0000
00001C: 0434 0000 0438 0000


Notice how all those addresses look. In my code APP_IVT_START is 0x0404, so all these addresses start at 0x0404 and increase by 4 (to allow space for the application IVT to have gotos). Your bootloader IVT doesn't look like this, so it throws up flags for me.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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