Strange jumps after printf

ljbeng · Joined: 10 Feb 2004 Posts: 205

This is an 18F4620 chip and version 3.249.

I have a program that takes >45ms at 4MHz to display 10 characters on an lcd. That's ~ 45,000 clock cycles. So I started digging. If I do a break in the lst file and step through the program in the problem area, I get some strange jumps.

Ttelmah · Guest

You can see from the listing, that the code does not jump to E3D4, so what you have to ask is 'why does my debugging enviroment think the code jumps to E3D4'?. Now, you don't say what the debugging enviroment is, but I'd perhaps suspect this is an ICD?. If so, your code addresses, suggest that you may be running into the problem of the code overlaying part of the ICD code. The ICD itself, needs a number of resources. Normally a few hundred bytes at the top of memory, two stack levels, some RAM etc.. If these are not available, then behaviours like you describe will occur. I think for your chip, it is 12 RAM locations, and about 640 ROM locations that are needed.
Another possibility is if you are loading the wrong ICD code for the chip, but this is normally automatic. However if the file from an older ICD setup is in the directory, confusion can result...
Have you tried the code with debugging disabled?. Does the delay disappear?.

Best Wishes

ljbeng · Joined: 10 Feb 2004 Posts: 205

Yes, it is the CCS ICD with 1.39 loaded. I just tried the program without debug turned on and it still has this long delay. I have 95% of rom used with debug on and 47% of RAM.

mpfj · Joined: 09 Sep 2003 Posts: 95 Location: UK

Are you sure the listing file matches what's actually programmed inot the PIC ? A couple of times, I've fooled myself by compiling code into one directory, and then loading the COFF file from another Embarassed

and then speding ages trying to work out what's going on !?!

Also, does this only occur when you're doing a CALL instruction ? Might there be a stack overflow problem ? Check the stack usage in the listing file.

ljbeng · Joined: 10 Feb 2004 Posts: 205

Ttelmah · Guest

How are you trying with 'debug turned off'?. You normally need to remove ICD=true, and also switch off loading of the firmware by the ICD (untick the box 'automatically load firmware if needed', in the ICD setup), otherwise the firmware will still be transferred into the chip when you program it.

Best Wishes

ljbeng · Joined: 10 Feb 2004 Posts: 205

Ttelmah,

I do remove ICD=TRUE (and the program gets slightly smaller) but I do not see this firmware check box you speak of. Thanks.

Ttelmah · Guest

I have only used these units under MPLAB. In there it is under the settings for the ICD. However if I remember correctly, on the USB units, in the CCS setup, you turn off ICD=true, and then select 'Mach-X', instead of the ICD, which simply programs the chip, rather than handling things as if it is an ICD. I don't know how you do this on the serial units. The key is that there 'has' to be a way of telling the ICD not to transfer the extra code. ICD=true, only changes the 'stubs' in the generated code, to access the ICD, the act of using the ICD, then transfers an extra hex file (the 'icdfirmwarexxx.fw' file), into the chip. If you open this with a text editor, you will get an idea of how much extra code has to be put into the chip, and why I suspect at 94 to 95% 'full', you may be having problems with this.

Best Wishes

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

The amount of RAM and ROM memory used by the ICD2 depends on the processor you are using. Exact quantities are given in the MPLAB helpfiles, search for the chapter 'Resources Used By MPLAB ICD 2'.

In the PIC18F4620 the ICD-2 uses Program Memory 0xFD80-0xFFFF (640 bytes), RAM 0xEF$ to 0xEFF (12 bytes) and two stack levels.

ROM, RAM and stack levels don't seem to be the limiting factor here.

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

This problem reminds me of a debug session I had. It turned out that the 'Disassembly Listing' window in MPLAB was not properly updated after compiling and I was still working with an old code view. Closing and re-opening the 'Disassembly listing' synchronized things again.

ljbeng · Joined: 10 Feb 2004 Posts: 205

I am only using the CCS 3.249 environment and the ICD-S40 to debug. I even made my program smaller (53%) by removing the setup and programming subroutines. I still get the long printf delays and strange jumps in both debug environment and production chips. I even tried programming the chip with my QuickWriter and still see this problem.

Thanks for all your input, people....

Does CCS have any ideas..... I will email this on....

ljbeng · Joined: 10 Feb 2004 Posts: 205

CCS says it is in the %w command. What can I do about that? I was using a division routine I found here and I changed to %w as it was much cleaner to code.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

ljbeng · Joined: 10 Feb 2004 Posts: 205

Here is how I used to do it....