Problem with CALL instruction (does not update PPAGE register) on 9s12dp256b

[m_wohlwender]

Hi,

I have problems with the PPage switching within banked flash memory. I added some service-routines which are used all over the code. The problem occurs e.g. when code located in bank 31 calls the service-routines located in bank 32. To call the service-routine the compiler generates a "call 0x1234,0x32" instruction but when I step over the assembly code with the debugger I can see that the call instruction puts the address of the following instruction and the PPAGE register to the stack, but the PPAGE register is not changed from 31 to 32 and the instruction pointer points to 0x31 0x1234 after the call.

I compiled the code with the Compiler-Flags "-CpPPAGE=0x0030 -Mb". I tried to compile the code with the flags "-CpPPAGE=RUNTIME -Mb" and linked datapage.c to the code but this doesn`t fixed the problem.

In the S12CPU15UG.pdf I have read within chapter 4.4.8:

"The HCS12 has dedicated signal lines that allow the CPU to access the bank page register without having

to use an address in the normal 64K byte address space. This eliminates the need for the program to know

where the page register is physically located."

So why do I have to specify the PPAGE address to the compiler at all?

Used Tool Versions:

CodeWarrior Development Studio for Motorola HC12 3.1, build 4047. (see Attachment for more details)

Thanks for your help

Best regards

Mario

[CompilerGuru]

Is the "0x1234,0x32" just an address you invented?
As the PPAGE window is from 0x8000 to 0xBFFF this is not a valid address.
Otherwise I would suggest that you check that nothing else, especially not the debugger interferes with your observation. It would be really strange if a CALL instruction would fail to set PPAGE, so I wonder if the issue is not elsewhere, for example the CALL instruction did not properly download or someone (debugger, who else?) overwrites PPAGE,or...
I would suggest that you create a test setup project which only contains this particular call and then see if it fails there too. If it does, post the test project here. If it does not fail, search for differences.

Daniel

[m_wohlwender]

Hi again,

I reduced my project to a minimum to find the error easier. With this project I discovered that the code is running and I only have Problems when stepping through code with the debugger step by step (stepping over a call instruction doesn't modify the PPAGE Register).

Then I compared my project-files to them generated by the CodeWarrior wizard and discovered that there are a lot of instructions different within the project.ini-File within the ICD12-Block. 

Finally I found that in my project there was one line missing:

DMM_MCUID03C6_MODULE0=Registers 0x0 0x400 1 4 0 2 1 1

my ini-File started with ...MODULE0=Ram.

Adding this line (and re-numbering the Modules) seems to fix the Problem.

At the moment debugging works fine but I have a lot of undokumented? (I havent found them within the online help of the hiwave debugger) instructions in my project.ini-File which are not appearing within the wizard generated .ini-File. I do not know who created my .ini-file, and I do not want to have some more bugs resting there...

Perhaps you can help me to find a documentation of the commands inside the [ICD 12]-Block within the .ini-File.

Thanks a lot for your help!

Mario   

[CrasyCat]

Hello

The .ini file is not supposed to be changed manually.

It looks like you did try to play around with debugger Memory Map functionality.

In order to return to original settings I would recommend you to do the following:

  - Start the debugger

  - In the MultilinkCyclonePro menu select Debugging Memory map

  - In the Debugging memory map window click on "RevertToDefault"

This should get you back to the correct memory map for the selected device.

CrasyCat

[m_wohlwender]

Hi again,

I tried to reconstruct the problem with a small project, but I was not able to see the problem again.

Here is the code of my test project (I created the project with the CodeWarrior Wizard):

/* main.c */

#include <hidef.h>      /* common defines and macros */
#include <mc9s12dp256.h>     /* derivative information */

#pragma CODE_SEG USER1
char service1(char i);
#pragma CODE_SEG USER2
char service2(char i);

#pragma CODE_SEG DEFAULT

#pragma LINK_INFO DERIVATIVE "mc9s12dp256b"

void main(void)
{
  /* put your own code here */
  char i = 0;

  EnableInterrupts;
 
  for(;
  {
    i = service1(i);
  } /* wait forever */
}

#pragma CODE_SEG USER1
char service1(char i)
{
  return service2(i);
}
#pragma CODE_SEG USER2
char service2(char i)
{
  return (++i);
}
#pragma CODE_SEG DEFAULT

/*.prm-File */

...

PLACEMENT

...

USER1             INTO  PAGE_32;
USER2             INTO  PAGE_31;

DEFAULT        INTO  PAGE_30; 

...

The small program works as it should work, it calls service1() from main() (sets PPAGE from 30 to 32 and then calls service2() (sets PPAGE from 32 to 31) and then returns to main() (PPAGE = 30).

The only difference I found within the compiler-flags is a -D_HCS12 define (Compiler/Assembler) but adding this to my large Project didn't solve the problem. The datapage.c is identical in both projects. The start12.c is little bit different but I haven't found anything what could be the reason for my problems.

The assembly code of both projects is correct I think (in my big project there is a "call addr, page" instruction too) but the instructions behave different. So it can't be the datapage.c/start12.c, it must be something within uC config, am I right? What could be the reason for this? What prerequisites are needed to get the ppage switching to work?

Mario

[J2MEJediMaster]

What memory model are you using the build each program? For the large program you should be using a banked memory model, using a compiler switch of -Mb. You can change this option from the HC12 Compiler Options settings panel > Code Generation, and check memory model.

Sorry if this is obvious and already covered.

---Tom

[Lundin]

On CW3.1 I use -CpPPAGE=0x30 as well as linking datapage.c.

I would recommend you to alter datapage.c so that it says that PPAGE is 0x30 everywhere. I don't trust that file at all, I had all kinds of weird errors of the kind you describe because this file contained wrong addresses for PPAGE and because the compiler ignored the CpPPAGE instruction entirely.