 |
 |
| View previous topic :: View next topic |
| Author |
Message |
DrDoug
Joined: 22 Feb 2012
Posts: 4
|
| program reboots from long function call |
 Posted: Wed Mar 07, 2012 12:13 pm |
 |
|
PIC18LF458
CCS v4.084
IDE v8.46
Ok, I can't figure this one out. I am trying to implement a boot sector at the beginning of the program. After completion, the boot sector will jump to a function with a set address at the beginning of the main sector, which in turn will call the main application routine. Fairly standard stuff.
Everything was working fine, until my program got to a certain length. Now my program reboots after the call to the application main routine.
The following is a stripped-down version of the code I am developing:
| Code: |
#include "PIC18F458.h"
#FUSES HS
#define RCON (*(unsigned char *)0x0FD0)
unsigned char bRCON;
// ***** BOOT SECTOR
#ORG 0x0028, 0x01FE DEFAULT
#use delay(clock=16000000)
#use RS232(baud=19200, UART1)
void main(void)
{
bRCON = RCON;
RCON = 0x1F;
output_low(PIN_D5); //needed to power my hardware RS232 xceiver
delay_ms(100);
printf("\r\nRCON=0x%02x ", bRCON);
putc('1');
goto_address(0x0200);
}
#ORG DEFAULT
// ***** MAIN CODE SECTOR
#ORG [b]0x2556[/b], 0x7FFE DEFAULT
void test(void)
{
putc('3');
infiniteloop:
restart_wdt();
goto infiniteloop;
}
#ORG DEFAULT
// ***** ENTRY POINT TO MAIN CODE SECTOR
#ORG 0x0200, 0x208
void mainjump(void)
{
putc('2');
test();
}
|
The location of the test() routine seems to be the problem. In the snipped above, I have the routine set at ROM address 0x2556. This code will execute fine (the output is "RCON=0x1f 123"), and the the program will just set there idle in its infinite loop.
However, if I move the test() function to address 0x2558 or 0x255A, the program will give me the same output message, but then will immediately reboot.
If I set the address to 0x255C or greater, I'll only get the message RCON=0x1f 12", and the unit will continuously reboot.
Note that the RCON register always gives me the value 0x1f, which is interpreted as a "MCLR from run". No hardware reset is actually occurring (there's only a pull-up on the MCLR pin). I also tried sticking a RESET instruction at the end of ROM space to detect if the program counter was somehow getting outside of my code, but it didn't make any difference.
Anyone have any idea what could be the issue here? I've checked the program and disassembly listings, and the op codes look right to me, so I don't think it is necessarily a compiler bug. I'm kinda stumped here. |
|
 |
drolleman
Joined: 03 Feb 2011
Posts: 116
|
|
| Posted: Wed Mar 07, 2012 1:58 pm |
|
|
| I've had this problem before. to fix it I'll break it into smaller functions, another way is to change the order of the functions. This usually works. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Wed Mar 07, 2012 3:47 pm |
|
|
Are you sure you are not managing to overwrite some other code located up there (like a loader or something) ? Another possibility that comes to mind is you have run into a chip with bad flash memory. You might try another chip and try reading the flash back to see if it matches what was supposed to be written. One of the things we used to do in critical systems was to have a background task running that calculated the CRC of each "task" in FLASH and compared it to the known CRC for that task. If it didn't match, it reset the processor or halted it depending on the criteria.
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
DrDoug
Joined: 22 Feb 2012
Posts: 4
|
|
| Posted: Wed Mar 07, 2012 6:27 pm |
|
|
Arrrggghhh!
Ok, I figured out the problem (I guess). I downloaded the code from the chip and discovered that any program data past a certain address (0x2560) wasn't actually programmed into the chip. I checked the hex file, and confirmed that the codes for these addresses were in the file, but somehow they weren't actually getting programmed. I then imported the hex file into MPLAB (rather than build it through the compiler), downloaded it, and this time all the code space programmed correctly!?!
So, essentially, if I build my project, then try to use the ICD3 to program my chip, nothing past 0x2560 was getting programmed (but this would still pass the verify test). But importing a hex file would work fine with the ICD3.
I dug around in my drawers and found a PicKit3. I tried it with the compiler and it works just fine. So I guess this was all a ICD3 bug. Wow, that was 2 work days completely wasted. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Wed Mar 07, 2012 7:22 pm |
|
|
It's always easy once you know the answer :-) Having been down similar paths in the past was why I suggested reading it back again to verify it was actually programmed. Years ago, I beat my head on the wall trying to find out why my hand assembled code for the 8080 was not working - including putting a hardware write protect on the memory. Turned out to be a 2102 STATIC RAM chip with a bit that would flip after about 45 seconds all by itself.
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu Mar 08, 2012 4:48 am |
|
|
Do you REALLY know whats going on? There's an awful lot of "I guess"s there. This smells to me of the "boot sector" code not fitting in the space you've allocated for it. There's quite a bit of compiler supplied set up code which is of unknown length. Fitting compiled C code into any given, small, memory space is always tricky. Its one reason why bootloaders are usually written in assembler - you can control the size of the code precisely: no guessing.
I'd review everything about this code: where its placed (all of it), how big it is, what calls what, and when. There are very few reports of issues with ICD3. I use it all the time, never had any thing similar. Though there's always a first time. I'd look carefully at the programmer settings for the ICD 3: maybe you, or someone else, set something up there that, on the assumption of what memory was required, only programs some regions. There's all sorts of things that may be wrong. I'd always assume operator and developer error first until proven different, AND IMPORTANTLY, UNDERSTOOD WHY.
RF Developer |
|
|
|
|
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
