|
|
View previous topic :: View next topic |
Author |
Message |
ferrumvir
Joined: 01 Feb 2006 Posts: 64 Location: England
|
Bootloaded application does not run, how to trace the error? |
Posted: Mon Jan 22, 2007 2:59 am |
|
|
Hi,
I've written a bootloader which does everything I think it should, however all applications I've attempted to load with it fail to run.
I wrote a lot of details into another thread http://www.ccsinfo.com/forum/viewtopic.php?t=29529 but no one seemed prepared to read through it, fair enough it is rather a long post.!. Sorry for starting a new thread, but hopefully this is a more readable/answerable post.
Can anyone give me any advice on how to trace the error and solve the problem?
Thanks Scott |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Jan 22, 2007 12:27 pm |
|
|
One way to find the problem would be to:
1. Write a very small application program. By small, I mean two lines
of code in main(). Use as little of the CCS library code as possible.
Library code is invoked with #use() statements.
Confirm that the application program runs OK if you use a normal
programmer to burn it into the PIC (ie, don't bootload it).
2. Now download it to the PIC, using the bootloader.
3. Confirm that it fails.
4. Read the PIC's program memory using your programmer and MPLAB.
5. Look at the Program Memory window in MPLAB. Print out the listing.
6. Study the listing. Look for where the error occurs. It may be jumping
to an address where it expects a library routine to be, but in fact there's
nothing there. It may using a RAM location that is also being used
by another part of the program, and thus it's being corrupted.
7. Print the .LST file for the application program (the non-bootloaded
listing, that's made by MPLAB when you compile the application).
Compare that listing with the one that you read from the bootloaded
code. Look for any important differences between the two listings,
with respect to program flow (jumps) and RAM usage.
-------
With regard to people not looking at your post:
Remember who you're asking questions to -- most of us are working
at jobs during the day where we're supposed to get something done.
If I see a post with tons and tons of code in it and I'm supposed to be
drawing a schematic, I just say "I don't have time for this", and I skip
the thread. That's why I always say to people "Keep it short". The
shorter the post (or the code), the better the chance that we will have
the time to look at it. I think other people feel the same way. |
|
|
ferrumvir
Joined: 01 Feb 2006 Posts: 64 Location: England
|
|
Posted: Tue Jan 23, 2007 3:57 am |
|
|
Thanks PCM Programmer,
Only needed to get as far as Point 4. Thanks for that, it had not crossed my mind to do that...
Found the bug and it was as small one (but as usual - critical), and now the application works just fine.
The problem I had, should you wish to know, was a check when to erase_program_eeprom
Code: |
if( addr&0x00000300==0 ){erase_program_eeprom(addr) // WRONG
if( addr&0x00000030==0 ){erase_program_eeprom(addr) // CORRECT
|
This meant that instead of it erasing at 0x40 boundaries it was erasing everytime I wrote to 0x8xx, which was the start of the application location. My bootloader checked the memory stored after each write and always returned correctly. I thought all was fine, little did I know that later lines were erasing parts I'd just written. One look at the downloaded HEX file, three lines of 0xFF followed by one correct line, pointed me firmly in the direction of the erase_program_eeprom, and sure enough my bug!
Thanks again PCM.
Cheers Scott |
|
|
|
|
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
|