[sdcc-devel] [ sdcc-Bugs-3521376 ] pic14 incorrect asm op code

[SourceForge.net <no...@so...>]

Bugs item #3521376, was opened at 2012-04-25 08:59
Message generated for change (Settings changed) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3521376&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic14 target
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Don Wooton (dwooton)
>Assigned to: Raphael Neider (tecodev)
Summary: pic14 incorrect asm op code

Initial Comment:
Several of my PIC projects have an LED that lights very early in
main() before interrupts are enabled.  After upgrading to a newer
version of sdcc, the LED no longer lights at all.  Err ... well ..
all other functions of the image are also non operational.

I tracked it down to a non functioning __sdcc_gsinit_startup.
Testing shows that if main() is ever called, memory has not been
properly initialized.  This is due to an invalid op code in idata.asm.

I find that builds beginning with svn #7080 have this problem.
The problem seems to be due to differing use of registers rather
something introduced in that version.
 
__sdcc_gsinit_startup is in idata.c

I tested with many svn versions of sdcc between #5883 and #7635.
I can consistently compile my code using any version of sdcc and
the PIC will perform correctly ONLY using an older sdcc or if I
force the link to use an idata.asm generated by an older sdcc.
    
In all cases when I used an idata.asm I created it from the
unmodified idata.c from the sdcc pic14 source.  The code of
idata.c has not changed since 2007.

I create the idata.asm with:

sdcc -V --Werror --std-c99 -mpic14 -p16f688 --i-code-in-asm -S idata.c

In the fragments attached it is clear that the ADDWF instruction on
line 0010 was intended to be ADDLW.  It is clear that register
0x46 would have no value there.  Older versions of sdcc use
MOVLW (_cinit + 2) to get &cinit.entry[0].
    
    - Don


----------------------------------------------------------------------

Comment By: Don Wooton (dwooton)
Date: 2012-06-24 12:02

Message:
The patch works for me.  THANK YOU!!

I tested with:

SDCC :
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
3.2.0 #7962 (Jun 23 2012) (Linux)

gpasm-0.14.2 #711 (Jun 23 2012)

I used --debug-xtra and did not see any CHECK: messages.

_sdcc_gsinit_startup worked as expected.

I also tested using __code data table lookups and that works.
That saves a lot of memory.

I suggest closing the bug.

    -- Don


----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2012-06-23 07:10

Message:
Raphael's patch applied in svn revision #7962.

Borut

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2012-06-23 06:22

Message:
A possible fix is available in the attached patch cinit-fix.patch (against
sdcc r7955).
If possible, please test and report your findings.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3521376&group_id=599