PRM problems for 908QB8

[bigmac]

Hello all,

I have recently been using CW08 V5.0 to test and debug some functions written in C.  I used the wizard to create a new project, and chose the 908QB8 as the target device, and tested the functions using full chip simulation.

At one point, after re-arranging some code from main() into a separate function, a previously operational function became erroneous.  This was subsequently found to be caused by the stack over-writing some of my global variables.  The stack size in the default PRM file that was generated by the wizard was then increased from 48 bytes to 80 bytes, with a resulting link error.

The 908QB8 device has 256 bytes of RAM, with the top 64 bytes in page 1, and the remainder in page 0.  However, the default PRM file allocates both global variables and stack to the top 64 bytes only.  The page 0 RAM remains unused.

I have now altered the PRM file so that global variables are allocated from the start of RAM in page 0, and the allocated stack still commences at the top of RAM, but its size may be any value within the RAM capacity.  This seems much more appropriate for this device.

NAMES END

SEGMENTS 
   ROM    =  READ_ONLY    0xDE00 TO 0xFDFF;
   Z_RAM  =  READ_WRITE   0x0040 TO 0x00FF;
   RAM    =  READ_WRITE   0x0040 TO 0x013F;
   ROM1   =  READ_ONLY    0xFFB0 TO 0xFFBD;
   ROM2   =  READ_ONLY    0xFFC2 TO 0xFFCF;
END

PLACEMENT
   DEFAULT_RAM                   INTO  Z_RAM;
   DEFAULT_ROM, ROM_VAR, STRINGS INTO  ROM;
   _DATA_ZEROPAGE, MY_ZEROPAGE   INTO  Z_RAM;
   SSTACK                        INTO  RAM;
END

STACKSIZE 0x50

VECTOR 0 _Startup

I realise that it will often be necessary to alter the PRM file to meet particular circumstances, however, the 908QB8 default file generated by the wizard appears quite inappropriate, in view of the type of problem encountered with a very simple program.  Does anyone know if it is possible to alter the file that the wizard automatically generates for the 'QB8?

Thank you.

Regards,
Mac

[CompilerGuru · Accepted solution]

in your prm, you define the 0x40..0xFF area twice, once as part of the RAM and once as part of the Z_RAM SEGMENT.

   Z_RAM  =  READ_WRITE   0x0040 TO 0x00FF;
   RAM    =  READ_WRITE   0x0040 TO 0x013F;

Well I dont have an installation here, but does this not cause any problems? I would expect a linker diagnostics for this, and if there is none, or if it is ignored, that the stack overlaps with your variables.

I would recommend to actually keep the separation of the zero page area and the non zero page area, and then use the Z_RAM area too once RAM is full.
E.g. (not tested)

PLACEMENT
_DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM;
DEFAULT_RAM INTO RAM, Z_RAM;
SSTACK INTO RAM, Z_RAM;
DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM;
END

About your question, the wizard generated prm file is copied from lib\hc08c\prm. But I would be very careful with modifying the template. Any kind of introduced bugs will be very hard to track. The original prm may not be the best, but it at least works. Also note that the wizard does adapt some of the prm file content for special use (for the memory model, for assembly only projects, OSEK, ...).

As for the HC08, using direct addressing is providing many benefits, explicitely allocating the often used variables in a __SHORT_SEG (direct) section may help a lot. Maybe the tiny memory model (and using the 64 non direct bytes explitely extended (__far) would be a good aproach for this chip too.

Daniel