XC8 Weird Problem

[Tomshao]

Hi guys,

I've been stucked for hours. It is a project for PIC16F1824, the compiler I am using is XC8 V1.12 in PRO mode.

Here is a segment of C code:

==================================================================
            case COMMAND_STATE_WAIT_DATALENGTH:
                Request.datalength = val;
                datacount++;
                if (Request.datalength>128) {
                    *cmderr = COMMAND_ERROR_DATALENGTH;
                    command_state = COMMAND_STATE_ABORT;
                } else if (Request.datalength ==0) {
                    command_state = COMMAND_STATE_WAIT_CHECKSUM;
                } else {
                    command_state = COMMAND_STATE_WAIT_DATA;
                }

                break;
==========================================================

After compile,it turns into something like this:


!            case COMMAND_STATE_WAIT_DATALENGTH:
!                Request.datalength = val;
0x6B4: MOVF val, W
0x6B5: MOVWF 0x47
0x6B6: MOVLW 0x63
0x6B7: MOVWF FSR1L
0x6B8: MOVLW 0x20
0x6B9: MOVWF FSR1H
0x6BA: MOVF 0x47, W
0x6BB: MOVWF INDF1
!                datacount++;
0x6BD: INCF datacount, F
!                if (Request.datalength>128) {
0x6BC: MOVLW 0x20
0x6BE: SUBWF INDF1, W
0x6BF: BTFSS STATUS, 0x0
0x6C0: GOTO 0x6C8
!                    *cmderr = COMMAND_ERROR_DATALENGTH;
0x6C1: MOVF 0x52, W
0x6C2: MOVWF FSR1L
0x6C3: MOVLW 0x3
0x6C4: CLRF FSR1H
0x6C5: MOVWF INDF1
!                    command_state = COMMAND_STATE_ABORT;
0x6C6: MOVLW 0x6
0x6C7: GOTO 0x70E
!                } else if (Request.datalength ==0) {
0x6C8: MOVLW 0x62
0x6C9: MOVWF 0x47
............................................

My question is, shouldn't the MOVLW 0x20(marked in red) be MOVLW 0x80?

After I change the compiler mode to "Free", the code works without any problem. However, the rom footprint of Free mode is so large and it has no pratical meaning for me.

Any suggestions? Your help will be greatly appreciated:

Posted on: December 15, 2012, 01:52:57 13:52 - Automerged
I changed "Request.datalength>128" to "Request.datalength+1>128+1", and it worked. >_<!
what a miracle~~

[sarah90]

What is the data type of Request.datalength? Looks like a problem related to signed/unsigned types.

[Tomshao]

typedef unsigned char INT8U;

typedef struct _REQUEST {
    INT8U commandid;
    INT8U datalength;
    INT8U datafield[COMMAND_MAXIMUM_REQUESTLENGTH];
    INT8U checksum;
} REQUEST;

[FTL]

It certainly looks like a compiler bug from what you've shown.

What does the compiler generate if you change it from ">128" to ">64" or ">32"? The subtract with 0x20 implies a comparison with 32. 

[Tomshao]

After I changed 128 to 64, it yields:
........................................................................
!                datacount++;
0x6D5: INCF datacount, F
!                //if (Request.datalength+1>COMMAND_MAXIMUM_REQUESTLENGTH) {
!                if (Request.datalength>64) {
0x6D4: MOVLW 0x20
0x6D6: SUBWF INDF1, W
0x6D7: BTFSS STATUS, 0x0
0x6D8: GOTO 0x6E0
.......................................................................

After I changed it from 128 to 32 it yields:
......................................................................
!                datacount++;
0x6D5: INCF datacount, F
!                //if (Request.datalength+1>COMMAND_MAXIMUM_REQUESTLENGTH) {
!                if (Request.datalength>32) {
0x6D4: MOVLW 0x20
0x6D6: SUBWF INDF1, W
0x6D7: BTFSS STATUS, 0x0
0x6D8: GOTO 0x6E0
......................................................................

It's quite weird and I agree with you, that may be some bug of the compiler.

[FTL]

That is amazingl You've given it 3 different comparison values, and it generated the same code! Clearly that is a bug. Fortunately you found a bypass with the +1 on each side. And I thought the CCS compilers were buggy with all the fixes they issue.

Maybe you should post this on the Microchip support forums and see what they think.

[Gallymimu]

Be sure to open a support ticket with Microchip in addition to putting it on the support forum.  That way it is more likely to get logged into their system as a bug to fix.

If you give them the source code, and the compiler version they will definitely address it.  Microchip is pretty good about working with people especially if they have bugs that the apps engineering can reproduce.

[pickit2]

Hi guys,
After I change the compiler mode to "Free", the code works without any problem. However, the rom footprint of Free mode is so large and it has no pratical meaning for me.

Just read the topic.... if it works in free mode, and not in patched version, how can microchip, find the bug...
If so, do you think they will help with the patching?

[Thiru09]

if it works in free mode, and not in patched version, how can microchip, find the bug...

May be this is the bug of PRO version's optimization section.

Regards,
Thiru

[metal]

I still think you need to open a ticket @ microchip's site so that they fix it.
I reported many bugs that are fixed now.

[Gallymimu]

I would suggest installing the "trial" version of the pro compiler, see if you get the same results, and then you will be in good shape with Microchip... There is a trial version of pro for XC8 right?  It's been so long since I have installed it I can't remember.

[Wannabe]

You can choose during installation to activate a 60 day PRO evaluation, and as far as I can tell the activation process doesn't send e-mail or any personal information. So just saying that you're in your evaluation period should be good.
Happy bug-squashing 

[marcodassi]

Yep... what a weird weird bug!
Any news about it? Has Microchip been informed about that?
Regards