<?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>OSBDM and TBDML中的主题 Re: Is this a bug?</title>
    <link>https://community.nxp.com/t5/OSBDM-and-TBDML/Is-this-a-bug/m-p/271480#M2619</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Wang,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In a way it is but I'm unsure what the correct way of treating this situation should be.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When using the trace function in Codewarrior it creates a buffer in RAM to store the trace information.&amp;nbsp; It also includes an zeroed region in the binary file image to initialise the buffer to zero when the image is loaded into the target.&amp;nbsp; This situation is accepted by USBDM when working within Codewarrior since it makes some sense to download 'stuff' to RAM when debugging a target.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The USBDM stand-alone programmer produces an error because it doesn't make sense to 'program' something to RAM.&amp;nbsp; If your program image contains data destined to RAM then it would (usually) indicate that there is a mistake in the memory map since such data would be lost when the target is reset.&amp;nbsp; It seems sensible to flag this as an error.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Basically - You should turn off the trace function when producing a final image for production.&amp;nbsp; This is sensible in any case since tracing should not (normally) be in use in the production target.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When I have time I will consider adding an option to the programmer to ignore writes to RAM but I really think this is of little value.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;bye&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 16 Jul 2013 00:12:56 GMT</pubDate>
    <dc:creator>pgo</dc:creator>
    <dc:date>2013-07-16T00:12:56Z</dc:date>
    <item>
      <title>Is this a bug?</title>
      <link>https://community.nxp.com/t5/OSBDM-and-TBDML/Is-this-a-bug/m-p/271479#M2618</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi pgo,&lt;/P&gt;&lt;P&gt;I'm learning to how to use KL05z32.when I use codewarrior10.3 to debug my program,it works well.when I use ARM programmer to program my elf file,it failed and a dialog comes out&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper" image-alt="5102_5102.png"&gt;&lt;img src="https://community.nxp.com/t5/image/serverpage/image-id/119605i90796F404E06B789/image-size/large?v=v2&amp;amp;px=999" role="button" title="5102_5102.png" alt="5102_5102.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;I began to find reason and find codewarrior Trace function results in the error.when I disable Trace function fo my project,The dialog don't come out.&lt;/P&gt;&lt;P&gt;Is this a bug?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 15 Jul 2013 08:29:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/OSBDM-and-TBDML/Is-this-a-bug/m-p/271479#M2618</guid>
      <dc:creator>wangbaode</dc:creator>
      <dc:date>2013-07-15T08:29:56Z</dc:date>
    </item>
    <item>
      <title>Re: Is this a bug?</title>
      <link>https://community.nxp.com/t5/OSBDM-and-TBDML/Is-this-a-bug/m-p/271480#M2619</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Wang,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In a way it is but I'm unsure what the correct way of treating this situation should be.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When using the trace function in Codewarrior it creates a buffer in RAM to store the trace information.&amp;nbsp; It also includes an zeroed region in the binary file image to initialise the buffer to zero when the image is loaded into the target.&amp;nbsp; This situation is accepted by USBDM when working within Codewarrior since it makes some sense to download 'stuff' to RAM when debugging a target.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The USBDM stand-alone programmer produces an error because it doesn't make sense to 'program' something to RAM.&amp;nbsp; If your program image contains data destined to RAM then it would (usually) indicate that there is a mistake in the memory map since such data would be lost when the target is reset.&amp;nbsp; It seems sensible to flag this as an error.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Basically - You should turn off the trace function when producing a final image for production.&amp;nbsp; This is sensible in any case since tracing should not (normally) be in use in the production target.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When I have time I will consider adding an option to the programmer to ignore writes to RAM but I really think this is of little value.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;bye&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 16 Jul 2013 00:12:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/OSBDM-and-TBDML/Is-this-a-bug/m-p/271480#M2619</guid>
      <dc:creator>pgo</dc:creator>
      <dc:date>2013-07-16T00:12:56Z</dc:date>
    </item>
  </channel>
</rss>

