PCM 3.124 C code is pretty unstable

[gil motta]

Hello, Please help me out!!

I am using PCM 3.124 and MPLAB 5.70 and 16F874A

I wrote a software that features A/D, PWM, SPI and USART and all the I/Os work fine but my software is growing

My .lst tells me that I am using 1873 bytes therefore the page #1 is empty and I have plenty of memory left.

My problem is that the compiler seems to be unstable sometimes my code works sometimes it does not I got to a point that if I add one or two lines of code the generated code makes my target hardware go crazy and malfunction.

The code that I am trying to add is a call to a subroutine that is already being called from other locations so I know that the subroutine WORKS. a simple line like this:

display_blank();

it is enough to make the software go nuts then i delete the line recompile, reprogram and It works fine. I spent 10 hours adding and deleting the line above and got the same problem over and over.

Have you seen a problem like this before. This is out of my control please help.
___________________________
This message was ported from CCS's old forum
Original Post ID: 8948

[nilsener]

Dear,

I have seen something like your problem before in my code, I remember Version 3.068. I add only a new variable and after that nothing works. In this case it happens if codesize is approx 95\% of the 18f877 ROM. Until now I did not know the reason for this problem. I solved the problem by reducing codesize. A terrible solution !

Wish you good luck using CCS Compilers...

regards nilsener

:=Hello, Please help me out!!
:=
:=I am using PCM 3.124 and MPLAB 5.70 and 16F874A
:=
:=I wrote a software that features A/D, PWM, SPI and USART and all the I/Os work fine but my software is growing
:=
:=My .lst tells me that I am using 1873 bytes therefore the page #1 is empty and I have plenty of memory left.
:=
:=My problem is that the compiler seems to be unstable sometimes my code works sometimes it does not I got to a point that if I add one or two lines of code the generated code makes my target hardware go crazy and malfunction.
:=
:=The code that I am trying to add is a call to a subroutine that is already being called from other locations so I know that the subroutine WORKS. a simple line like this:
:=
:= display_blank();
:=
:=it is enough to make the software go nuts then i delete the line recompile, reprogram and It works fine. I spent 10 hours adding and deleting the line above and got the same problem over and over.
:=
:=Have you seen a problem like this before. This is out of my control please help.
___________________________
This message was ported from CCS's old forum
Original Post ID: 8983

[Nicholas Kinnas]

<font face="Courier New" size=-1>:=Hello, Please help me out!!
:=
:=I am using PCM 3.124 and MPLAB 5.70 and 16F874A
:=
:=I wrote a software that features A/D, PWM, SPI and USART and all the I/Os work fine but my software is growing
:=
:=My .lst tells me that I am using 1873 bytes therefore the page #1 is empty and I have plenty of memory left.
:=
:=My problem is that the compiler seems to be unstable sometimes my code works sometimes it does not I got to a point that if I add one or two lines of code the generated code makes my target hardware go crazy and malfunction.
:=
:=The code that I am trying to add is a call to a subroutine that is already being called from other locations so I know that the subroutine WORKS. a simple line like this:
:=
:= display_blank();
:=
:=it is enough to make the software go nuts then i delete the line recompile, reprogram and It works fine. I spent 10 hours adding and deleting the line above and got the same problem over and over.
:=
:=Have you seen a problem like this before. This is out of my control please help.

Without seeing your hardware or code it is difficult to pinpoint anything but before you blame the compiler make sure that your code is not hanging because it is waiting for a hardware response. Put a break point at the beginning of your code to see if maybe you are getting a watchdog reset. Make sure your USART input is not stuck in an active state for some reason. It is possible that making the call to the subroutine from a different place is hanging your code because the hardware is not in the right state.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 8992

[darren logan]

Oooooh this kind of post makes my skin crawl !

I've been there, got the T-shirt as they say.

I solved it by literally - physically moving procedures/functions around.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9016

[Laurent chouinard]

:=I solved it by literally - physically moving procedures/functions around.

Physically? Cool! I always knew that printing code and then using tape and glue to re-arrange programs would work :P

hehe sorry I couldn't resist
___________________________
This message was ported from CCS's old forum
Original Post ID: 9017

[johnpcunningham]

This may or may not be your problem but I have seen problems when your RAM can only recognize the first bank. Try adding the *= 16 to your device statement. Example:

#device 16F877 *=16
___________________________
This message was ported from CCS's old forum
Original Post ID: 9025

[PCM programmer]

:=I am using PCM 3.124 and MPLAB 5.70 and 16F874A
:=My problem is that the compiler seems to be unstable sometimes my code works sometimes it does not I got to a point that if I add one or two lines of code the generated code makes my target hardware go crazy and malfunction.
----------------------------------------------------------

Are you keeping an archive of each version of the compiler
that you download ? You need to do that, so you can go
back to a previous version if CCS makes a bad version.
When you download a new version, give it a name like this:
PCM3124.EXE

Save it in a special folder. Eventually, you will have many
old versions available. Example:

PCM3124.EXE
PCM3123.EXE
PCM3122.EXE
PCM3121.EXE
etc.

If you have not been doing this, and if you still have
download rights, then go immediately to the CCS download
page and get vs. 3.110. At least that version should work.
Get it before your download rights expire (If you only
have 30 days). <a href="http://www.ccsinfo.com/download.shtml" TARGET="_blank">http://www.ccsinfo.com/download.shtml</a>
___________________________
This message was ported from CCS's old forum
Original Post ID: 9028

[Charlie U]

:=Hello, Please help me out!!
:=
:=I am using PCM 3.124 and MPLAB 5.70 and 16F874A
:=
:=I wrote a software that features A/D, PWM, SPI and USART and all the I/Os work fine but my software is growing
:=
:=My .lst tells me that I am using 1873 bytes therefore the page #1 is empty and I have plenty of memory left.
:=
:=My problem is that the compiler seems to be unstable sometimes my code works sometimes it does not I got to a point that if I add one or two lines of code the generated code makes my target hardware go crazy and malfunction.
:=
:=The code that I am trying to add is a call to a subroutine that is already being called from other locations so I know that the subroutine WORKS. a simple line like this:
:=
:= display_blank();
:=
:=it is enough to make the software go nuts then i delete the line recompile, reprogram and It works fine. I spent 10 hours adding and deleting the line above and got the same problem over and over.
:=
:=Have you seen a problem like this before. This is out of my control please help.

This may have nothing to do with your problem, but I suffered for a couple of days with a similar intermittent problem. All I did was convert a #define value to a read from EEPROM. The plan was to eventually add the capability to change the EEPROM data via the serial port to set some timing parameters. Welllll... two days later and many lost handfuls of hair (and there weren't many to begin with) and a very sore forehead after I discovered the problem, it turned out, I had forgotten to cast the EEPROM int to a signed long for a comparison. I have no idea what caused the program to work sometimes and fail others, but it drove me nuts. The lesson learned here is check your types very carefully!!!.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9030