|
|
View previous topic :: View next topic |
Author |
Message |
jeremiah
Joined: 20 Jul 2010 Posts: 1353
|
|
Posted: Tue Feb 11, 2014 8:27 pm |
|
|
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
|
|
Posted: Tue Feb 11, 2014 8:38 pm |
|
|
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
|
Problems with IVT on PIC24HJ |
Posted: Sat Feb 22, 2014 3:04 pm |
|
|
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
|
|
Posted: Sat Feb 22, 2014 11:11 pm |
|
|
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. |
|
|
|
|
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
|