The Godfather talking
You think I am funny guy huh?
Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 06, 2016, 11:11:04 11:11


Login with username, password and session length


Pages: [1]
Print
Author Topic: XC8 Weird Problem  (Read 4464 times)
0 Members and 1 Guest are viewing this topic.
Tomshao
Inactive

Offline Offline

Posts: 3

Thank You
-Given: 2
-Receive: 0


« on: December 15, 2012, 02:15:58 14:15 »

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~~
Logged
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #1 on: December 16, 2012, 11:42:04 11:42 »

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

Offline Offline

Posts: 3

Thank You
-Given: 2
-Receive: 0


« Reply #2 on: December 17, 2012, 06:52:19 18:52 »

typedef unsigned char INT8U;

typedef struct _REQUEST {
    INT8U commandid;
    INT8U datalength;
    INT8U datafield[COMMAND_MAXIMUM_REQUESTLENGTH];
    INT8U checksum;
} REQUEST;
Logged
FTL
V.I.P
Junior Member
*****
Offline Offline

Posts: 61

Thank You
-Given: 81
-Receive: 22


« Reply #3 on: December 17, 2012, 11:42:52 23:42 »

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. 
Logged
Tomshao
Inactive

Offline Offline

Posts: 3

Thank You
-Given: 2
-Receive: 0


« Reply #4 on: December 18, 2012, 09:21:36 09:21 »

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.
Logged
FTL
V.I.P
Junior Member
*****
Offline Offline

Posts: 61

Thank You
-Given: 81
-Receive: 22


« Reply #5 on: December 18, 2012, 11:03:49 11:03 »

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.
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #6 on: December 19, 2012, 01:51:27 01:51 »

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.
Logged
pickit2
Moderator
Hero Member
*****
Offline Offline

Posts: 3816

Thank You
-Given: 567
-Receive: 2049


There is no evidence that I muted SoNsIvRi


« Reply #7 on: December 19, 2012, 02:12:26 02:12 »

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?
Logged

Note: If you have no posts other than, I want or reporting a dead link Then you can't complain If I remove your post So Stop Leeching
Thiru09
Cracking Team
Active Member
****
Offline Offline

Posts: 246

Thank You
-Given: 285
-Receive: 815



« Reply #8 on: December 19, 2012, 07:50:57 07:50 »

Quote
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
Logged
metal
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2018

Thank You
-Given: 514
-Receive: 477


Top Topic Starter


« Reply #9 on: December 19, 2012, 11:42:19 11:42 »

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.
Logged

nothing to say..
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #10 on: December 19, 2012, 04:38:15 16:38 »

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.
Logged
Wannabe
Global Moderator
Senior Member
*****
Offline Offline

Posts: 429

Thank You
-Given: 209
-Receive: 277



« Reply #11 on: December 19, 2012, 10:59:25 22:59 »

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  Smiley
Logged
marcodassi
Junior Member
**
 Muted
Offline Offline

Posts: 37

Thank You
-Given: 64
-Receive: 20


« Reply #12 on: January 11, 2013, 02:59:03 02:59 »

Yep... what a weird weird bug!
Any news about it? Has Microchip been informed about that?
Regards
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC