Strange PIC Behaviour after programming

liak · Post by **liak** » Fri May 09, 2008 2:54 am

Dear All,
It's really embarassing but I will have to ask.

I have just completed my main project, finally completed after months of refinement. Thanks to all the help I have from this forum.
I program the PIC with bootloader via MAX232 at serial Comm1 on my PC. All the while and before this it worked fine. But this strange thing occurs after I completed my last refinement yesterday.
It seems that all the program is running well. But when I disconnected the MAX232, the PIC refused to run at all. All the program had been burned into the PIC. When I re-connect the MAX232, the PIC starts to run again. Anyone can think of the strange cause for this?
I do not want to include the MAX232 into the final package. And with previous projects, it worked well and okay with the MAX232 disconnected. Very strange. I can't find any explanation, please help. I used USART module in my program for input from the PC, but this part of the module is not runned unless triggered by the user.

RadioT · Post by **RadioT** » Sat May 10, 2008 1:38 pm

Hi Liak,

It's hard to debug from here! But it sounds like the PIC is waiting for some sort of response from the RS232 chip. This is a basic debug problem. There are a lot of things you can try to debug this, like disabling the RS232 port, putting probes on all the lines to the RS232 chip and scoping the line levels, etc.

Also, how many K is your code? I found that I started to run into occasional odd problems after I exceeded 64K in my object code size. Sometimes all I had to do was move modules around and it would compile and run fine. I have no idea if it's a compiler thing, an assembler thing or even the chip I'm using, but I've always been able to get it to work.

73's,
de Tom

David Barker · Post by **David Barker** » Sat May 10, 2008 1:53 pm

I'm not personally aware of any compiler or ASM problems for code over 64K...

RadioT · Post by **RadioT** » Sat May 10, 2008 3:05 pm

Actually, David, I don't know of any specific issues, either! For all I know it could even be a combination of the ICD2, MPLab's 64K debugging limit, using a "J" part and my PC's wonky USB drivers. I get blue screens from time to time just to remind me what operating system I'm running!

It's just a suggestion. When seeing problems that can't be easily explained, I change a few things and it's usually easily fixed. I'm just relating that debugging tidbit in case it can be of help to Liak. I really only started seeing these things afer the code in this project expanded over 64K.

-Tom

Doj · Post by **Doj** » Sun May 11, 2008 10:26 pm

Hello all, I have had problems above 64k and below 64k!!!, but the issue is nothing to do with the compiler rather the fact that it becomes far easier to mess up array and string lengths when you get so many variables in a big program(I have found).

All the strange issues I have pulled my hair out with have ended up being string/array length issues, changing position in memory seemed to alter the issue but that ended up luck as the overwritten code did not cause a seen issue.

String length has the greatest cause of my headaches, usually forgetting the null!!! and I now use BOUND for array length!

RadioT · Post by **RadioT** » Tue Aug 19, 2008 5:19 am

The problem I had was found to be due to nesting a set of CASE statements in a long list of user choices. Sometimes it would compile and put the assembler in place, sometimes it would not. Now that I can see what's going on with the COF files, I was able to fix it. I think the increased number of CASE statements coincided with the code going over 64K by coincidence.

By the way, I fixed the problem with the nested CASE statements by replacing them with with if-then-else statements.

The problem I encountered using a huge number of if-then-else comparisons has also been fixed by David (My code is over 95K now and has about 330 "IF" statements).

-Tom