9S08AC128 Paged Memory Programming using Code Warrior 6.3

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

9S08AC128 Paged Memory Programming using Code Warrior 6.3

Jump to solution
1,782 Views
LDAA_STAB
Contributor I

Anyone here willing to share some examples of paged programming using CW? We would like to see how others solve the page programming challenge.

 

In our case we have an operationial issue that is giving us fits.

Here's the background:  a small product was created using the 9S08AC128. We were planning for expansion from the start.  Not much memory requried initially.  But, like all ongoing ventures, marketing wanted more functionality which means more memory.  We had time so in order to gain some experience with the banked/ paged menory technique we decided to create two projects based on AC128.  The first project expanded on the current, non-paged code set.  It was was created using the small memory model for AC128. The project was created using CW.  The application code was integrated and thoroughly tested and operates as designed.  The second project would implement memory paging.  It was created using the banked memory model. Source files from the non-banked project were imported into the banked project. None of the source files were modified.  The banked project makes, loads to the target, and runs. The banked project contains several modules (files). One of the modules was selected and modified according to AN3730:  #pragma CODE_SEG PAGED_ROM and #pragma CODE_SEG DEFAULT surround the functional prototypes and functions in the module. The code makes and loads to the target hardware but does not run.  We dis-assembled the target module and found RTC in place of RTS.  We dis-assembled one of the other modules that contain functions that call the functions wrapped in #pragma CODE_SEG PAGED_ROM and found the CALL opcodes in place of JSR.  Reading the .S19 file shows S1 data records in the 0x8000 range (S1238000nnnnnn).

We modified the .prm file by adding a new line in the PLACEMENT area:  PAGED_FLASH INTO P_PAGE2.  Commented P_PAGE2 out of the PAGED_ROM line and changed the #pragma segment names to PAGED_FLASH in the targeted module.  Compilation now produces S2 records with address fields: 0x028nnn.  The code loads and can be viewed from the debugger (in page mode). The application starts but promply bombs out. Breakpointing our way through the code from reset forward indicates a while loop test associated with a timer causes the crash:

 

  ClearRegBits(TPM2C0SC, 0x80);         /* Wait 8uS */

  while ( (TPM2C0SC & 0x80) == 0);      /* */

 

 

Comment the while loop out and execution continues on but then stops at unrelated code.  After the crash PC is at 0x0000, Stack points to the same address as before the crash. The source code was imported from a known good program.  This leaves issues with settings in CW, banked setup or code or

one of the associated apps.

 

What are we missing?

 

Thoughts? Comments? Assistance? Code examples?

 

Thank you!

WmB  

Labels (1)
0 Kudos
1 Solution
508 Views
kef
Specialist I

Porting from Small to Banked memory model should be as easy as just telling
Project Wizard that you want Banked memory model. But with one main exception:
interrupt handlers.

  1. Did you use #pragma TRAP_PROC, or did you use interrupt keyword, both
    where OK in Small model, but are not enough in Banked model. You still need to
    use TRAP_PROC or interrupt keyword to make interrupt handlers exiting with RTI
    instruction, but since CPU doesn't bank switching when calling interrupt
    handlers, you need to tell linker that interrupt handlers have to be allocated
    in nonbanked memory. See below how
  2. In case you are using pointers to "near" functions, you need to
    use near keyword when defining such function pointers. Some users try to avoid
    function pointers, but they still can have some vectors.c, in which they may
    have array of pointers to near interrupt handlers.

It is bit weird that CW 6.3 compiler requires two near keywords when
defining function pointers. It won’t compile if one of near’s below is missing.

  void __near (* __near fptr)(void);

Allocation to nonbanked memory is done like you say putting prototypes and
function between pragmas:

#pragma CODE_SEG NON_BANKED

void near myfoo1(void);

void near myfoo2(void);

#pragma CODE_SEG DEFAULT

here ^^ NON_BANKED is PLACEMENT derfined in PRM
file. Additional to ^^ these two pragmas you need to use near keyword in front
of each prototype/define.  If you don’t
like near keyword, then you need to use __NEAR_SEG
attribute:

#pragma CODE_SEG __NEAR_SEG
NON_BANKED

void myfoo1(void);

void myfoo2(void);

#pragma CODE_SEG DEFAULT

__NEAR_SEG makes all functions near

  • Reading the .S19 file shows S1 data records in
    the 0x8000 range (S1238000nnnnnn).

It is OK. PPAGE=0 , CPU address 0x8000 is also paged address. Since address
fits 16bits, burner uses S1 record to define banked code.

View solution in original post

0 Kudos
2 Replies
509 Views
kef
Specialist I

Porting from Small to Banked memory model should be as easy as just telling
Project Wizard that you want Banked memory model. But with one main exception:
interrupt handlers.

  1. Did you use #pragma TRAP_PROC, or did you use interrupt keyword, both
    where OK in Small model, but are not enough in Banked model. You still need to
    use TRAP_PROC or interrupt keyword to make interrupt handlers exiting with RTI
    instruction, but since CPU doesn't bank switching when calling interrupt
    handlers, you need to tell linker that interrupt handlers have to be allocated
    in nonbanked memory. See below how
  2. In case you are using pointers to "near" functions, you need to
    use near keyword when defining such function pointers. Some users try to avoid
    function pointers, but they still can have some vectors.c, in which they may
    have array of pointers to near interrupt handlers.

It is bit weird that CW 6.3 compiler requires two near keywords when
defining function pointers. It won’t compile if one of near’s below is missing.

  void __near (* __near fptr)(void);

Allocation to nonbanked memory is done like you say putting prototypes and
function between pragmas:

#pragma CODE_SEG NON_BANKED

void near myfoo1(void);

void near myfoo2(void);

#pragma CODE_SEG DEFAULT

here ^^ NON_BANKED is PLACEMENT derfined in PRM
file. Additional to ^^ these two pragmas you need to use near keyword in front
of each prototype/define.  If you don’t
like near keyword, then you need to use __NEAR_SEG
attribute:

#pragma CODE_SEG __NEAR_SEG
NON_BANKED

void myfoo1(void);

void myfoo2(void);

#pragma CODE_SEG DEFAULT

__NEAR_SEG makes all functions near

  • Reading the .S19 file shows S1 data records in
    the 0x8000 range (S1238000nnnnnn).

It is OK. PPAGE=0 , CPU address 0x8000 is also paged address. Since address
fits 16bits, burner uses S1 record to define banked code.

0 Kudos
508 Views
LDAA_STAB
Contributor I

Implemented your suggestions, especially pragmas at the ISRs.  The whole project now operates as expected.

Thanks for the suggestions.

0 Kudos