PICC 3.126 bugs?

[James A. Littlefield]

I am having problems with both 3.110 and 3.126 compiles for the 16F877. Previously working code is now broken! In examining the assembly code generated I find a case where the compiler has generated a direct "goto 000" from within the code generated by a macro expansion. Thus every time the macro is used the program appears to restart!!

Is anyone else seeing odd things w/ 3.126?
___________________________
This message was ported from CCS's old forum
Original Post ID: 9523

[Dave Yeatman]

:=I am having problems with both 3.110 and 3.126 compiles for the 16F877. Previously working code is now broken! In examining the assembly code generated I find a case where the compiler has generated a direct "goto 000" from within the code generated by a macro expansion. Thus every time the macro is used the program appears to restart!!
:=
:=Is anyone else seeing odd things w/ 3.126?
___________________________
This message was ported from CCS's old forum
Original Post ID: 9535

[Dave Yeatman]

I use macros quite a bit and have not seen a problem. Could you post the macro and the code around where it was used so we can test it?

(This board is acting strange!)

Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 9537

[PCM programmer]

:=I am having problems with both 3.110 and 3.126 compiles for the 16F877. Previously working code is now broken! In examining the assembly code generated I find a case where the compiler has generated a direct "goto 000" from within the code generated by a macro expansion. Thus every time the macro is used the program appears to restart!!
:=
:=Is anyone else seeing odd things w/ 3.126?
------------------------------------------------
What about PCM vs. 3.127 ? I was trying to debug a program
in a 16F628. I was using printf to display the output of
the comparator as '1' or '0'. It put out garbage chars.
I switched back to vs. 3.110 and now it works.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9540

[James A. Littlefield]

:=I use macros quite a bit and have not seen a problem. Could you post the macro and the code around where it was used so we can test it?
:=
:=(This board is acting strange!)
:=
:=Dave

Pardon a novice user of this board but I don't know how to post an attached file! I therefore embed herewith the macro source and a portion of the list file generated to show the problem. If anyone wants the full source/project files etc I can also provide them!

#if BOGUS
#define TM_RD ((active1Wire != 0) ? WIRE1AIN : WIRE1BIN)
#else
#define TM_RD (ReadTBIT())
uint8 ReadTBit(void)
{
if (active1Wire != 0) return(WIRE1AIN);
else return(WIRE1BIN);
}
#endif

If I use the bogus definition of TM_RD, the code fails wherease the other (hopefully equivalent!) definition works as expected.

Here is a sample section of the lst file with the bogus definition used.

.................... /*
.................... ** Wait for line to come up for at least a few samples
.................... */
.................... while (!TM_RD);
0084: MOVF 22,F
0085: BTFSC 03.2
0086: GOTO 08F
0087: MOVLW 00
0088: BTFSC 06.4
0089: MOVLW 01
008A: XORLW 00
008B: BTFSC 03.2
008C: GOTO 000
008D: GOTO 000
008E: GOTO 092
008F: MOVLW 00
0090: BTFSC 05.1
0091: MOVLW 01
0092: XORLW 00
0093: BTFSC 03.2
0094: GOTO 084
.

In stepping through this code w/ ICD I find that the goto at address 008C gets executed which pops one back to program start address...argh.

Another curious thing is that this "problem" appears to be context dependent. In my full blown application the TM_RD macro is used in multiple places and different code is generated in these other places.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9541

[James A. Littlefield]

:=:=I am having problems with both 3.110 and 3.126 compiles for the 16F877. Previously working code is now broken! In examining the assembly code generated I find a case where the compiler has generated a direct "goto 000" from within the code generated by a macro expansion. Thus every time the macro is used the program appears to restart!!
:=:=
:=:=Is anyone else seeing odd things w/ 3.126?
:=------------------------------------------------
:=What about PCM vs. 3.127 ? I was trying to debug a program
:=in a 16F628. I was using printf to display the output of
:=the comparator as '1' or '0'. It put out garbage chars.
:=I switched back to vs. 3.110 and now it works.

Well....I was having problems with 3.110 and that was the motivation for getting 3.126! After 3.126 did not solve the problem I jumped into the compiler's output and saw the issue referenced previously.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9542

[v8power]

<font face="Courier New" size=-1>Hey I have this problem too

i just finished this battle here is the email i got back from tech support today


"There is a bug in 3.127 where the setup_vref blows away the baud rate register.
The attached DLL will fix."

they sent me a DLL to fix this I will post it on my web site until they get the patch out then it will be gone.

www.cdwtechnologies.com/pcm.zip

unzip the .dll to you PICC/DLL directory.





:=:=I am having problems with both 3.110 and 3.126 compiles for the 16F877. Previously working code is now broken! In examining the assembly code generated I find a case where the compiler has generated a direct "goto 000" from within the code generated by a macro expansion. Thus every time the macro is used the program appears to restart!!
:=:=
:=:=Is anyone else seeing odd things w/ 3.126?
:=------------------------------------------------
:=What about PCM vs. 3.127 ? I was trying to debug a program
:=in a 16F628. I was using printf to display the output of
:=the comparator as '1' or '0'. It put out garbage chars.
:=I switched back to vs. 3.110 and now it works.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 9554

[PCM programmer]

<font face="Courier New" size=-1>:=Hey I have this problem too
:=
:=i just finished this battle here is the email i got back from tech support today
:=
:="There is a bug in 3.127 where the setup_vref blows away the baud rate register.
:=The attached DLL will fix."

------------------------------------------------------
Thanks for telling me about that.

I found another bug with the setup_vref() function.
This bug is in PCM vs. 3.110 and 3.127, and probably more.

If you use the VREF_A2 parameter to enable VREF output
on Pin A2, the compiler inserts code to write to the
TRISA register, making Pin A2 into an output. This
affects the VREF voltage. If the latch for A2 happens
to be loaded with a 0, it kills VREF. If it happens
to be set at 1, then it raises VREF to a higher voltage.

When enabling VREF to come out on Pin A2, that pin needs
to be configured as an input, per the 16F628 data sheet.
ie., set the TRISA bit = 1 for pin A2.

Hopefully, CCS will fix this soon. In the meantime, I
am setting up VREF by writing directly to the VRCON register.
</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 9631

[James A. Littlefield]

The problem I previously described re: version 3.126 has been corrected in 3.129. Specifically, some macro expansions results in the compiler generating a jump to 000.
___________________________
This message was ported from CCS's old forum
Original Post ID: 9962