Callback Function is called but not executed

[Oesteves]

Hello! I have a project based on MC9S08LL64. As it is quite big and uses all the flash available (64KB), I had to use the Banked Memory Model. My code also makes large use of callback functions (functions that are called after some event occur). I noticed a strange behaviour: sometimes, a callback function is being called (I put some debug messages that are shown at the serial port) but its code is not executed (as if the 'jump' was not performed correctly). However, if I try to rearrange the order at which the source code modules are linked, sometimes it works.

This microprocessor is quite buggy. If I put a breakpoint inside the paging window, the code can not run. So, I wonder if the problem I described above has anything to do with the banked memory model or if the compiler is generating wrong code. 

Does anyone have any idea of what might be causing the problem?

Thanks in advance! 

[kef]

•  This microprocessor is quite buggy.

Really? It wouldn't surprise me if you blamed software, because banked memory support in Codewarrior for S08 is quite fresh.

• If I put a breakpoint inside the paging window, the code can not run.

You should put breakpoint not in page window, but in the source code. Also what does it mean code can't run? Certainly MCU isn't stalled and executes some instructions. The question is what is it executing?

Different effects with different link orders makes me thinking that something wrong is either with linking or with mixing pointers to banked and to nonbanked routines. Though it is not clear how does it break.

You should also mention 1) what CW version are you using and 2) if you are using original prj.wizard created prm file.

I think you should do service request for this.

[Oesteves]

Thank you for your tips.

I'm afraid i was not clear when talking about the breakpoint. What I wanted to say is stated in this Errata:

http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08LL64_0M46S.pdf?fsrch=1&WT_TYPE=E...

"The DBG module does not support setting breakpoints in the paging windowarea of the memory map. Setting a breakpoint in memory addresses that areaccessible only through the paging window is not functional. Thus for theDescription:flash addresses 0x0000 through 0x103B and addresses 0x1800 through0x18A0, the debug (DBG) module will not work. This area of 4,316 bytes offlash will not be supported by the features of the DBG module."

The workaround so far is:

"This area of 4,316 bytes should be used as storage for nonvolatile constants.If application software must be placed here, make sure to place simplefunctions that will not need extensive debugging. The PRM file has placedthe lowest priority on this section of flash so that applications that only usethe entire flash space will use this area."

When I said the code can not run what i meant to say is. If I put a breakpoint in a source code that is allocated in a banked region, the debuuger won't let the code run. I keep pressing the "Play" button but the it does not run. 

Code Warrior used id V6.3 and the .prm file used is not the one provided by the wizard. 

Project.prm currently used:

/* This is a linker parameter file for the mc9s08ll64 */NAMES END /* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your own files too. */SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */    /* RAM */    Z_RAM     =  READ_WRITE   0x0060 TO 0x00FF;           /*    159 bytes */    RAM       =  READ_WRITE   0x0100 TO 0x0FFE;           /*   3839 bytes */        /* Unbanked FLASH ROM */    ROM1      = READ_ONLY 0x4000 TO 0x7FFF FILL 0x83; // 16384 bytes    ROM2      = READ_ONLY 0xC000 TO 0xFFAD FILL 0x83; // 16302 bytes    OTHER     = READ_ONLY 0xFFAE TO 0xFFBF FILL 0x83; // 18 bytes    INT_VECT  = READ_ONLY 0xFFC0 TO 0xFFFF FILL 0x83; // 64 bytes    /* Banked FLASH ROM */    PAGE0     =  READ_ONLY 0x08000 TO 0x0BFFF FILL 0x83; // 16384 bytes    PAGE2     =  READ_ONLY 0x28000 TO 0x2BFFF FILL 0x83; // 16384 bytesENDPLACEMENT /* Here all predefined and user segments are placed into the SEGMENTS defined above. */    /* Non-zero page variables */    DEFAULT_RAM                         INTO  RAM;                                            _ZEROPAGE,                          INTO  Z_RAM;    /* */    _PRESTART,                          /* startup code */    STARTUP,                            /* startup data structures */    NON_BANKED,                         /* runtime routines which must not be banked */    ROM_VAR,                            /* constant variables */    STRINGS,                            /* string literals */    VIRTUAL_TABLE_SEGMENT,              /* C++ virtual table segment */    COPY                                /* copy down information: how to initialize variables */                                        INTO  ROM1,ROM2;    /* Routines which can be banked */    DEFAULT_ROM,                        INTO  PAGE0,PAGE2,ROM1,ROM2;                                        END//STACKTOP 0x0FFFSTACKSIZE 0xC8VECTOR 0 _Startup /* Reset vector: this is the default entry point for an application. */

[kef]

So you are having debugging issues with early maskset.

1. You may try using simulator to simulate suspicious function call. I know it is not simple to use simulator without fully simulated hardware, but you may try to set specific function pointer in simulator, then set program counter to calling routinee and try to step in to your callee.

2. Using real hardware, you may insert BKGD instruction just before function call via pointer. Debugger should stop on BKGD. Then you could step instruction by instruction into callee. Symbolic stepping over C lines probably won't work, since debugger is using breakpoints for this. But stepping over opcodes should always work, since TRACE1 BDM command is used for this, not breakpoints.

[tonyp]

Are you using Assembly or C?

One idea:

If your callout function happens to be on a different page, then a CALL / RTC instruction pair is required (JSR/RTS won't work).  Make sure this is what you or your compiler uses.

Or, you could move all callout functions into non-paged memory.

[Oesteves]

Sorry, I'm using C. The main problem in putting all of the callback functions in the non-banked memory is that i'm not sure if they all will fit there. Thank you!