MPLAB / XC8 can't jump to ASM?

I have a project for a PIC18F25K50 mixed C and build; most of what I want to do I can easily manage (and should for efficiency) in the assembly, but some of the parts that I like to make development easier use C. I actually have a couple of these and keep running into with the same problem: I cannot use ASM to navigate to a label. Every single function to go - CALL

, GOTO

, BNC

etc. - failure when receiving a label, setting the PC to some random but consistent value, where there are no instructions leading to the program freezing, Using the address works great: BC $+4

skips the next line.

An example of what doesn't work is the following:

#asm
_waitUS:
    GLOBAL  _waitUS
waitLoop:
    //12 cycles = 1 microsecond:
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    DECFSZ  WREG, F, ACCESS
    GOTO waitLoop
    RETURN
#endasm

void main() {
    //DEBUG:
    waitUS(6);
}

      

        
        
        
      

    

Now this may not work in general, and I am begging to focus on the jumping problem - it's still in prototyping because I can't even call the called function. The program compiles without problems.

Once called waitUS(6)

, the computer jumps from - in my case - 0x7C96

to 0x52

. Call switching C for MOVLW 6; CALL _waitUS

is exactly the same.

If I strictly use C to call / jumping (as in the previous project), it works fine and figures out where it is going.

I've been looking for an answer to this question for several weeks and still haven't seen anyone else with this problem, although every project I do (including plaintext in notepad, compiling via command line) has exactly the same question. What's connected with this?

Edit: By opening the memory view of the program, I was able to better understand what it does. The compiler knows where the functions are and tries to navigate to the correct location. Apparently CALL just doesn't know where this is going.

Example: The address 0x7C92

contains CALL 0x2044, 0

. This is how it should be, this is where the desired function begins. However, when this command PC

is executed , it changes to 0x205E , half of the function is missing.

Trying to be smart, I decided to attach some NOPs to the beginning of the function after my label, lining up the actual code with 0x205E

. Unfortunately, it seems like any change has changed where its unpredictable jump lands and then lands on 0x2086

.

By the way, when it runs in random locations, it will often go through GOTO

- and it will go to the specified location as intended. This only works in the same function as trying to use GOTO

instead CALL

ends up in the same wrong place, despite requiring a compiled result.