<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: PRM problems for 908QB8 in CodeWarrior for MCU</title>
    <link>https://community.nxp.com/t5/CodeWarrior-for-MCU/PRM-problems-for-908QB8/m-p/137891#M2106</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;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.&lt;BR /&gt;&lt;BR /&gt;&lt;PRE&gt;
   Z_RAM  =  READ_WRITE   0x0040 TO 0x00FF;
   RAM    =  READ_WRITE   0x0040 TO 0x013F;
&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;E.g. (not tested)&lt;BR /&gt;&lt;BR /&gt;PLACEMENT&lt;BR /&gt;_DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM;&lt;BR /&gt;DEFAULT_RAM INTO RAM, Z_RAM;&lt;BR /&gt;SSTACK INTO RAM, Z_RAM;&lt;BR /&gt;DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM;&lt;BR /&gt;END&lt;BR /&gt;&lt;BR /&gt;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, ...).&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Daniel&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 27 Nov 2006 02:40:18 GMT</pubDate>
    <dc:creator>CompilerGuru</dc:creator>
    <dc:date>2006-11-27T02:40:18Z</dc:date>
    <item>
      <title>PRM problems for 908QB8</title>
      <link>https://community.nxp.com/t5/CodeWarrior-for-MCU/PRM-problems-for-908QB8/m-p/137890#M2105</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt; &lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;Hello all,&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;I have recently been using CW08 V5.0 to test and debug some functions written in C.&amp;nbsp; 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.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;At one point, after re-arranging some code from main() into a separate function, a previously operational function became erroneous.&amp;nbsp; This was subsequently found to be caused by the stack over-writing some of my global variables.&amp;nbsp;&lt;/SPAN&gt; &lt;SPAN style="font-size: 2;"&gt;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.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;The 908QB8 device has 256 bytes of RAM, with the top 64 bytes in page 1, and the remainder in page 0.&amp;nbsp; However, the default PRM file allocates both global variables and stack to the top 64 bytes only.&amp;nbsp; The page 0 RAM remains unused.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;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&amp;nbsp;size may be any value within the RAM capacity.&amp;nbsp; This seems much more appropriate for this device.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;NAMES END&lt;BR /&gt;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;SEGMENTS&amp;nbsp;&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;ROM&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_ONLY&amp;nbsp;&amp;nbsp;&amp;nbsp; 0xDE00 TO 0xFDFF;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;Z_RAM&amp;nbsp; =&amp;nbsp; READ_WRITE&amp;nbsp;&amp;nbsp; 0x0040 TO 0x00FF;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;RAM&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_WRITE&amp;nbsp;&amp;nbsp; 0x0040 TO 0x013F;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;ROM1&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_ONLY&amp;nbsp;&amp;nbsp;&amp;nbsp; 0xFFB0 TO 0xFFBD;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;ROM2&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_ONLY&amp;nbsp;&amp;nbsp;&amp;nbsp; 0xFFC2 TO 0xFFCF;&lt;BR /&gt;END&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;&lt;BR /&gt;PLACEMENT&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;DEFAULT_RAM&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; Z_RAM;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;DEFAULT_ROM, ROM_VAR, STRINGS INTO&amp;nbsp; ROM;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;_DATA_ZEROPAGE, MY_ZEROPAGE&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; Z_RAM;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;SSTACK&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; RAM;&lt;BR /&gt;END&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;&lt;BR /&gt;STACKSIZE 0x50&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;BR /&gt;&lt;SPAN style="font-family: 'Courier New'; font-size: 2;"&gt;VECTOR 0 _Startup&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;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.&amp;nbsp; Does anyone know if it is possible to alter the file that&amp;nbsp;the wizard automatically generates for the 'QB8?&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;Thank you.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN style="font-size: 2;"&gt;Regards,&lt;BR /&gt;Mac&lt;BR /&gt;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 25 Nov 2006 11:06:40 GMT</pubDate>
      <guid>https://community.nxp.com/t5/CodeWarrior-for-MCU/PRM-problems-for-908QB8/m-p/137890#M2105</guid>
      <dc:creator>bigmac</dc:creator>
      <dc:date>2006-11-25T11:06:40Z</dc:date>
    </item>
    <item>
      <title>Re: PRM problems for 908QB8</title>
      <link>https://community.nxp.com/t5/CodeWarrior-for-MCU/PRM-problems-for-908QB8/m-p/137891#M2106</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;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.&lt;BR /&gt;&lt;BR /&gt;&lt;PRE&gt;
   Z_RAM  =  READ_WRITE   0x0040 TO 0x00FF;
   RAM    =  READ_WRITE   0x0040 TO 0x013F;
&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;E.g. (not tested)&lt;BR /&gt;&lt;BR /&gt;PLACEMENT&lt;BR /&gt;_DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM;&lt;BR /&gt;DEFAULT_RAM INTO RAM, Z_RAM;&lt;BR /&gt;SSTACK INTO RAM, Z_RAM;&lt;BR /&gt;DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM;&lt;BR /&gt;END&lt;BR /&gt;&lt;BR /&gt;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, ...).&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Daniel&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 27 Nov 2006 02:40:18 GMT</pubDate>
      <guid>https://community.nxp.com/t5/CodeWarrior-for-MCU/PRM-problems-for-908QB8/m-p/137891#M2106</guid>
      <dc:creator>CompilerGuru</dc:creator>
      <dc:date>2006-11-27T02:40:18Z</dc:date>
    </item>
  </channel>
</rss>

