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
How to make the CCS debugger step beyond loaded code space

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



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

How to make the CCS debugger step beyond loaded code space
PostPosted: Tue Sep 18, 2007 7:49 am     Reply with quote
Is there anyway to make the CCS debugger step beyond the loaded code space ?

As I can't actually use a debugger to see if the boot loader vectors to the correct starting point of the loaded application I'm stuck. !


Boot loader Progress so far:

1) Application code is written to memory correctly. I checked this by comparing hex files of the application code and what was written to the chip.

2) The boot loader reset vector is retained at location 0 and the application interrupt vectors are where they should i.e. comparing hex files.

3) Relocating the application reset vector is now done, I'm using theByteFactory way of doing that.
It appears to be correct: Again by comparing the hex files after an application has been loaded by the boot loader code.
Thanks to "ckielstra" for help on that.

4) Where does the boot loader "go" when it hits the goto address (i.e. the reset vector of the loaded app.) As I can't actually use a debugger to see where the boot loader vectors to I'm stuck. !

Thanks to everyone for all the help:


As to the question can program rom space be programmed with VDD at 3.3V the answer is a definite Yes. The only location that requires 5V is to burn the fuses.
So make the boot loader use the same fuses as the application.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Sep 18, 2007 11:37 am     Reply with quote
Quote:
Is there anyway to make the CCS debugger step beyond the loaded code space ?

I couldn't make the ICD2 do this with a 16F877. If I manually set
the program memory range to be larger than the actual program,
and then right-click on the Program Memory window, and then set
the PC to an address outside the actual program, it gives me an error
message:
Quote:
ICD0203: Operation not supported for current device.


Here is a work-around. Use the CCS function, goto_address(), and
just jump to the absolute address. Then you can step to it with the
debugger. You don't even have to "manually set the program range"
in the ICD2 setup screen. Just leave it as normal. I tested this method
and it works. It may work with the CCS ICD-U40 as well.

I'm assuming that your entire purpose is just to step through the
debugger code, to see how it works. This method should let you do it.
Code:
#include <16F877.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)

//======================================
void main()
{
char c;

c = 0x55;

goto_address(0x1000);

while(1);
}
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Tue Sep 18, 2007 1:58 pm     Reply with quote
PCM programmer wrote:
Quote:
Is there anyway to make the CCS debugger step beyond the loaded code space ?

I couldn't make the ICD2 do this with a 16F877. If I manually set
the program memory range to be larger than the actual program,
and then right-click on the Program Memory window, and then set
the PC to an address outside the actual program, it gives me an error
message:
Quote:
ICD0203: Operation not supported for current device.


Here is a work-around. Use the CCS function, goto_address(), and
just jump to the absolute address. Then you can step to it with the
debugger. You don't even have to "manually set the program range"
in the ICD2 setup screen. Just leave it as normal. I tested this method
and it works. It may work with the CCS ICD-U40 as well.

I'm assuming that your entire purpose is just to step through the
debugger code, to see how it works. This method should let you do it.
Code:
#include <16F877>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)

//======================================
void main()
{
char c;

c = 0x55;

goto_address(0x1000);

while(1);
}


Thanks for the reply.

The reason for wanting to do this is simple:
I need to know where the bootloader is vectoring to.
I called CCS and Mark told me the debugger will only show PC value but it should step. He suggested I watch the PC and track it in the LST file of the application.

I tried your suggestion and used a goto_address ( hard coded the address of the application) and in the debugger it shows the PC at the correct location, but on next "step" nothing happens, the PC does not increment. !
As if there is no code at that location.! Yet the hex dump says there is. !

What I gather from this is the debugger does not report the correct PC when it's outside of the loaded code area.

Finding out why the this boot loader does not run the loaded app. is not easy without a debugger.

Darn it ! Every hex dump says it should work !
I think there is a clue in that goto_address() does not even run the application !
But when the hex file says everything is in place I must be doing something else wrong.

Doing a goto_address(0 from the boot_loader main() should leave the stack unused.

Any way I'll plod on, although I'm running out of ideas about how to debug this bootloader.

Perhaps if I could pay someone to look at the code, but finding someone with the time to spare that really can solve the puzzle is most likely as difficult and solving it.

I have said it before :
"the first place you go blind is when reading your own code" .... !

I have no doubt it's a self inflicted error !
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Sep 18, 2007 3:27 pm     Reply with quote
If you control the bootloader source code and I think you do, you could
put in code to read the jump vector bytes and send them out through
some debug port. You could temporarily create a soft UART on one
pin to do this. Then you could see the vector.
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Tue Sep 18, 2007 3:48 pm     Reply with quote
PCM programmer wrote:
If you control the bootloader source code and I think you do, you could
put in code to read the jump vector bytes and send them out through
some debug port. You could temporarily create a soft UART on one
pin to do this. Then you could see the vector.

Good idea. Until now I've been relying on doing HEX file reads with the ICD-U40 and studying the results.

Yes I am in control of the boot loader and it is blue teeth connect (yes blue teeth because the SIG would sue if I used the real name )

Seeing the actual value will cast a new light on the subject Very Happy

Thanks for the tip.
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