• AVR Freaks

Hot!HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE

Page: 12 > Showing page 1 of 2
Author
TechDpt
Starting Member
  • Total Posts : 42
  • Reward points : 0
  • Joined: 2011/06/13 09:29:39
  • Location: 0
  • Status: offline
2019/07/23 00:41:53 (permalink)
0

HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE

Hi all,
I've a design builded with the HI-TECH PICC V8.05PL2 (MPLAB IDE v7.30) that work perfectly so I've tried to port it inside the latest IDE MPLAB v8.92 and the HI-TECH PICC V9.83.
Device is set as PIC16F876A.
I've resolved the definition by updating it, no issue about it (no need to define the legacy header for that), the real trouble is how to restore the behavior with C calling from assembly code.
Here below the project (I've created it as new fresh one, not imported from previous version) to show the wrong behavior:
 
#include <pic.h>

#define TRUE 1
#define FALSE 0
#define DELAY_CLK        6
 
 
char Delayctr;
unsigned int i;

void Delay_Tclk(void);
void Delay_Tclk(void)
{
 #asm
  movlw DELAY_CLK
  movwf _Delayctr
 Loop_tclk:
  decfsz _Delayctr,f
  goto Loop_tclk
 #endasm
 return;
}

void main(void)
{
 i = 0;
 while(TRUE)
 {
  i += 1;
  #asm
   fcall _Delay_Tclk
  #endasm
 }
}

 
Here below the compilation errors:
 
Warning [1090] C:\Tecnico\sw\testasm.c; 6. variable "_i" is not used
Error [800] testasm.as; 195. undefined symbol "_Delay_Tclk"

 
I've tested it with the Lite version, so no optimisation was set.
 
This code work properly inside my V8.05PL2 release, no errors, but I can not figure out how keep it working into the v9.83 release.
Someone could give me a hand?
Thank!
post edited by TechDpt - 2019/07/23 00:42:57
#1

37 Replies Related Threads

    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 01:55:10 (permalink)
    +1 (1)
    Have you considered moving to XC8?
    I just tried your source in XC8 v1.45 free mode, and it compiled without error.
    I must say, calling C from assembler is fraught with risk, as you're going to confuse the compiled stack.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 02:16:45 (permalink)
    0
    Thank you ric,
    I'm try also in XC8 but I've got error about #asm directive that is not properly recognised, could you please post the code you try in MPLABX?
    Thank!
    #3
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 02:50:50 (permalink)
    +1 (1)
    I think you missed me specifically mentioning v1.45.
    I assume you are using v2.05, and have it set to C99 mode.
    Edit the project properties and change it back to C90 mode, and it will behave a lot more like HiTech C.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 05:28:37 (permalink)
    0
    Thank you ric for the advice, I've missed the compiler release :)
    I've also a lot of trouble with this IDE release so I'll try to install the v5.15 in order to see if the things are working better... I'll report back my results.
    post edited by TechDpt - 2019/07/23 05:30:10
    #5
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 06:20:53 (permalink)
    0
    I've installed the IDE V5.15 and the XC8 compiler V1.45, now most of the error disappear.
    Tthe ones that I have is about undefined symbol _PORTC, _STATUS and _PORTA that I'm using inside a  #asm, #endasm directive because I've coded directly in assembly a driver for I2C EEPROM.
     
     
    i2c.c:575: error: (800) undefined symbol "_PORTC"
    i2c.c:588: error: (800) undefined symbol "_STATUS"
    i2c.c:242: error: (800) undefined symbol "_PORTA"

     
    here below a piece of code:
     
     
    void I2C_Data_write()
    {
     #asm
      movlw 0xA0
      btfsc _AT24C1024MSB_addr,0
      movlw 0xA2
      movwf _EE_data_tm

      bsf _PORTC,SCL  ; <-- ERROR (800) SCL=5
      fcall _Delay_tsustart
      bcf _PORTC,SDA ; <-- THIS ONE GET NO ERROR SDA=4
      fcall _Delay_thdstart
    ; control byte
      movlw 0x08
      movwf _temp

     
    do you have some suggest about this?
     
    Thank!
    post edited by TechDpt - 2019/07/23 07:55:38
    #6
    1and0
    Access is Denied
    • Total Posts : 9464
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 07:45:53 (permalink)
    0
    TechDpt
    I've installed the IDE V5.15 and the XC8 compiler V1.45, noe most of the error disappear, the ones that I have is about undeffined symbol _PORTC, _STATUS and _PORTA that I'm using inside a  #asm, #endasm directive because I've coded directly in assembly a driver for I2C EEPROM.
     
     
    i2c.c:575: error: (800) undefined symbol "_PORTC"
    i2c.c:588: error: (800) undefined symbol "_STATUS"
    i2c.c:242: error: (800) undefined symbol "_PORTA"


    Remove the underscore in front of the SFR symbols.  With that said, why don't you use the EEPROM functions and/or macros provided by XC8?
     
    #7
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 08:15:31 (permalink)
    0
    Thank 1and0 for the info, this will sove the error about the SFR registers but I got a lot of error (1347) because the linker was unable to fit all the code inside the PIC I think, but with my old licensed High Tech V8.05PL2 with Global Optimization level OFF, just Enabled the assembler optimization for the PICC Compiler, PICC Assembler with no optimization I can build all and the final result was:
     
    Total ROM used     6174 words (75.4%)
    Total RAM used      297 bytes (80.7%)
     
    with the XC8 I can do same my doubt is that if with the PRO release this should be compiled or not... sad that with a newer release of the compiler the final result are so different...
    I've attached the V8.05PL2 option used to compile, was very fast with no issue... hope someone can help to achieve same result with the XC8 v1.45...
     
    Concerning the EEPROM function you suggest to use, my EEPROM on I2C is wired different pin like the usual for the I2C master inside the PIC and with my code I'm able to address I2C EEPROM up to the 1024kbits size, actually the EEPROM is wired to PORTC, RC5 (SCL) and PORTC,RC4 (SDA), the routine you refer can be configured also to manage the I2C from any pin than the hardware RC3/RC4 (because I can use the MSSP module) ?
     
    There is some way to get the same behaviour of the old V8.05PL2 compiler?
     
    Thank for your time!
     
     
    Thank!
     
    post edited by TechDpt - 2019/07/23 08:18:20

    Attached Image(s)

    #8
    NKurzman
    A Guy on the Net
    • Total Posts : 17596
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 09:01:17 (permalink)
    +1 (1)
    The Hi-Tech 8.XX is Very old. the Compiler was rewritten for Version 9.XX,  Then Microchip bought it and renamed it XC8.  
    #9
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 23:03:01 (permalink)
    0
    Yes I know it but the fact is that this compiler have a very good engine... anyway in order to try the porting from the old Hi-Tech and the XC8 (v1.45) actually the problem are the many error of this type:
     
    :0: error: (1347) can't find 0x11F words (0x11f withtotal) for psect "text25" in class "CODE" (largest unused contiguous range 0x61)
     
    that I think is related the unability of the compiler to allocate all the code inside a block of memory, again this trouble was not present with the old compiler... so this may be a proof that the old engine was better than this one or simply that I've to test the compiler in PRO release, but at the moment I've not installed it as trial, so can I activate it inside MPLABX or I've to reinstall the compiler in order to activate the trial mode and test if this is able to perform the code compilation?
     
    Thank!
    post edited by TechDpt - 2019/07/23 23:07:23
    #10
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 23:08:06 (permalink)
    +1 (1)
    XC8 was created by the same programming team, who made even more improvements to it.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #11
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 23:19:54 (permalink)
    +1 (1)
    TechDpt
    that I think is related the unability of the compiler to allocate all the code inside a block of memory, again this trouble was not present with the old compiler...

    Do you have a lot of C code all grouped in one single function?
    XC8 does try to implement each function inside a single code page. (A PIC16F876 has four pages.)
    Simply breaking it up into smaller functions would allow that, and is better programming practice.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/23 23:59:47 (permalink)
    0
    I've also performed another test but this time inside the MPLAB IDE v8.92 with a newer release of the Hi-Tech compiler the V9.83, again I get errors of another type:
     
    fixup overflow referencing psect bssBANK1 (0xD9) into 1 byte at 0x934/0x2 -> 0x49A
     
    and all related variables defined as global inside the C code and used into the assembly code referenced with the underscore so _<variable-name>, again the new compiler release although was always Hi-Tech is not smart as the old release... so a back step in performarce for a newer compiler release... sad...
     
    It is curious as many different release of same compiler (XC8 should be build from the old Hi-Tech core I think) produce so different result with the same code.
     
    Thank!
    post edited by TechDpt - 2019/07/24 00:25:43
    #13
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 01:50:57 (permalink)
    +1 (1)
    Can you show a particular line that generates that error?
    If it's something like
    movwf _temp

    try
    movwf BANKMASK(_temp)

     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #14
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 02:46:31 (permalink)
    0
    Hi ric,
    this is a piece of code:
     
    void I2C_Data_read(void)
    {
     #asm
      clrwdt

      clrf BANKMASK(_EE_Error_Flag) ; <-- row 226 catch two error!
      movf _AT24C1024MSB_addr,W
      movwf _AT24C1024MSB_addr_tmp
      movf _EEHY_addr,W
      movwf _EEHY_addr_tmp
      movf _EELO_addr,W
      movwf _EELO_addr_tmp

      movlw 0xA0
      btfsc _AT24C1024MSB_addr_tmp,0
      movlw 0xA2

      movwf _EE_data_tm

      bsf _PORTA,3
    [...]

     
    I've did some testo with BANKMASK, but the compiler catch an error:
     
    Error [876] C:\Tecnico\sw\sensore-v400mplab\i2c.c; 226. syntax error
    Error [800] C:\Tecnico\sw\sensore-v400mplab\i2c.c; 226. undefined symbol "BANKMASK"

     
    the BANKSEL directive is instead recognized and give no error.
     
    I've also did another test, isolate the clrf _EE_Error_Flag instruction and perform it in C code and the bank bits are correctly set and no error arise, but if I try to use it directly inside the asm code it will catch up errors...
     
    Thank for your help in understanding how to solve this problem!
    post edited by TechDpt - 2019/07/24 03:00:25
    #15
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 03:26:18 (permalink)
    +1 (1)
    Have a read of the XC8 User Guide "2.4.7 Assembly Code"
    and particularly "2.7.8 How Do I Fix a Fixup Overflow Error?"
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #16
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 03:48:12 (permalink)
    0
    ric
    Have a read of the XC8 User Guide "2.4.7 Assembly Code"
    and particularly "2.7.8 How Do I Fix a Fixup Overflow Error?"
     


    Reading the DS50002053H document "MPLAB® XC8 C Compiler User’s Guide" into the docs folder for the v1.45 installation I can not find the "2.4.7 Assembly Code" chapter, may be another manual?
     

    Attached Image(s)

    #17
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 04:12:22 (permalink)
    0
    Concerning instead the XC8 from manual I can read (2.5.16 In-Line Assembly) that
     
    "For 8-bit compilers, change any instance of #asm ... #endasm, so that each instruction in the #asm block is placed in its own asm()statement"
     
    so I've tried to perform some changing of the following code:
     
    void Delay_Tclk(void)
    {
     #asm
      movlw DELAY_CLK
      movwf _Delayctr
     Loop_tclk:
      decfsz _Delayctr,f
      goto Loop_tclk
     #endasm

     return;
    }

     
    with this one:
     
    void Delay_Tclk(void)
    {
      asm("movlw DELAY_CLK"); // Numero cicli
      asm("movwf _Delayctr"); // Variabile indice
    asm("Loop_tclk:");
      asm("decfsz _Delayctr,f"); // delayctr=delayctr-1
      asm("goto Loop_tclk"); // Continua il ciclo
     return;
    }

     
    but compiler seems not able to recognise the defined label DELAY_CLK...
     
    i2c.c:90: error: (800) undefined symbol "DELAY_CLK"
     
    I can really see where are all the improvement made at this compiler... it seems most trouble improved to me ... :)
     
    Thank!

    Attached Image(s)

    #18
    ric
    Super Member
    • Total Posts : 23165
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 04:21:16 (permalink)
    +1 (1)
    TechDpt
    Reading the DS50002053H document "MPLAB® XC8 C Compiler User’s Guide" into the docs folder for the v1.45 installation I can not find the "2.4.7 Assembly Code" chapter, may be another manual?

    Sorry, that reference was to the most recent manual for version 2.05. I forgot you mentioned going back to 1.45.
    It's "3.4.7 Assembly Code" and "Section 3.7.8 “How Do I Fix a Fixup Overflow Error?”)" in the 1.45 manual.
     
    Concerning instead the XC8 from manual I can read (2.5.16 In-Line Assembly) that
     
    "For 8-bit compilers, change any instance of #asm ... #endasm, so that each instruction in the #asm block is placed in its own asm()statement"
     
    so I've tried to perform some changing of the following code:

    You are reading the CCI chapter, which does NOT apply to normal syntax.
    Avoid the "asm()" syntax. It's horrible, and much less powerful than #asm ... #endasm.
    Unfortunately it is all that is available in C99 mode in the later compilers.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #19
    TechDpt
    Starting Member
    • Total Posts : 42
    • Reward points : 0
    • Joined: 2011/06/13 09:29:39
    • Location: 0
    • Status: offline
    Re: HI-TECH v9.83 PIC16F876A ISSUE WITH C FUNCTION CALLING FROM ASSEMBLY CODE 2019/07/24 04:50:13 (permalink)
    0
    Also again for the XC8 I can see a very different behaviorconcerning this simple assembly coded routine, let me explain, a variable used as cycle counter is put by the compiler into the psect    bssBANK1 as shown below (extracted from the .lst file):
     
    393 psect bssBANK1
       394 0000' __pbssBANK1:
       395 0000' _SerialBufferTx:
       396 0000' ds 20
       397 0014' _SerialBufferRx:
       398 0014' ds 20
       399 0028' _ADClobyte:
       400 0028' ds 2
       401 002A' _ADChibyte:
       402 002A' ds 2
       403 002C' _DataFromADC1:
       404 002C' ds 2
       405 002E' _DataFromADC0:
       406 002E' ds 2
       407 0030' _iTimeoutBetweenSample:
       408 0030' ds 2
       409 0032' _iNumberOfStep:
       410 0032' ds 2
       411 0034' _EELO_addr_tmp:
       412 0034' ds 1
       413 0035' _EEHY_addr_tmp:
       414 0035' ds 1
       415 0036' _AT24C1024MSB_addr_tmp:
       416 0036' ds 1
       417 0037' _temp:
       418 0037' ds 1
       419 0038' _Delayctr:
       420 0038' ds 1
       421 0039' _bFlagContinuousMode:
       422 0039' ds 1
       423 003A' _bFlagWriteTime:
       424 003A' ds 1
       425 003B' _bFlagDebug:
       426 003B' ds 1
       427 003C' _bFlagMeasurementDone:
       428 003C' ds 1
       429 003D' _bFlagStartPhase2:
       430 003D' ds 1
       431 003E' _bFlagStartPhase1:
       432 003E' ds 1
       433 003F' _newState:
       434 003F' ds 1
       435 0040' _oldState:
       436 0040' ds 1
       437 0041' _curState:
       438 0041' ds 1
       439 0042' _Unita:
       440 0042' ds 1
       441 0043' _Decine:
       442 0043' ds 1
       443 0044' _Centinaia:
       444 0044' ds 1
       445 0045' _Migliaia:
       446 0045' ds 1
       447 0046' _RSFlag:
       448 0046' ds 1
       449 0047' _TxMaxChr:
       450 0047' ds 1
       451 0048' _TxCtr:
       452 0048' ds 1
       453 0049' _EEi_data_rd:
       454 0049' ds 1
       455 004A' _EE_data_wr:
       456 004A' ds 1
       457 004B' _EE_data_rd:
       458 004B' ds 1
       459 004C' _EELO_addr:
       460 004C' ds 1
       461 004D' _EEHY_addr:
       462 004D' ds 1
       463 004E' _AT24C1024MSB_addr:
       464 004E' ds 1
       465 004F' _EE_Error_Flag:
       466 004F' ds 1

     
    I've performed a first test with this code:
    void Delay_Tclk(void)
    {
     Delayctr = DELAY_CLK;
    asm("Loop_tclk:");
     asm("decfsz _Delayctr,f");
     asm("goto Loop_tclk");
      return;
    }

     
    and from the listing I've:
     
    11633 ;psect for function _Delay_Tclk
     11634 0000' _Delay_Tclk:
     11635
     11636 ;i2c.c: 90: Delayctr = 6;
     11637
     11638 ;incstack = 0
     11639 ; Regs used in _Delay_Tclk: [wreg]
     11640 0000' 3006 movlw 6
     11641 0001' 1283 bcf 3,5 ;RP0=0, select bank0
     11642 0002' 1303 bcf 3,6 ;RP1=0, select bank0
     11643 0003' 0080' movwf ??_Delay_Tclk
     11644 0004' 0800' movf ??_Delay_Tclk,w
     11645 0005' 1683 bsf 3,5 ;RP0=1, select bank1
     11646 0006' 1303 bcf 3,6 ;RP1=0, select bank1
     11647 0007' 0080' movwf _Delayctr^(0+128)
     11648 0008' Loop_tclk:
     11649
     11650 ;#
     11651 0008' 0BB8' decfsz _Delayctr,f ;#
     11652 0009' 2800' goto Loop_tclk ;#
     11653 000A' 0008 return
     11654 000B' __end_of_Delay_Tclk:
     11655 ;i2c.c: 94: return;

     
    seems correct, from the C assigment the correct bank is selected.
     
    here below another test with different code:
    void Delay_Tclk(void)
    {
     asm("movlw 6");
     asm("movwf _Delayctr");
    asm("Loop_tclk:");
     asm("decfsz _Delayctr,f");
     asm("goto Loop_tclk");
      return;
    }

     
    and related listing:
    11532 ;psect for function _Delay_Tclk
     11533 0000' _Delay_Tclk:
     11534
     11535 ;incstack = 0
     11536 ; Regs used in _Delay_Tclk: []
     11537 0000' 3006 movlw 6 ;#
     11538 0001' 00B8' movwf _Delayctr ;#
     11539 0002' Loop_tclk:
     11540
     11541 ;#
     11542 0002' 0BB8' decfsz _Delayctr,f ;#
     11543 0003' 2800' goto Loop_tclk ;#
     11544
     11545 ;i2c.c: 95: return;
     11546 0004' 0008 return
     11547 0005' __end_of_Delay_Tclk:

     
    I can not see any bank selection, but the variable effectively reside into the bssBANK1 so what is wrong?
    It is a very strange behavior...
     
    Thank.
     
    post edited by TechDpt - 2019/07/24 04:59:00
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5