<?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: questions about e500v2 (P2020) machine check interrupt in P-Series</title>
    <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346306#M5017</link>
    <description>&lt;P&gt;Hi ufedor,&lt;/P&gt;&lt;P&gt;Thanks for your reply.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I set&amp;nbsp;&lt;SPAN&gt;HID1[RFXE] to 0, and the machine check still occur in my test. So is this a expected behavior? Or there is something wrong?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Sun, 26 Sep 2021 10:49:51 GMT</pubDate>
    <dc:creator>GeekFork</dc:creator>
    <dc:date>2021-09-26T10:49:51Z</dc:date>
    <item>
      <title>questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1342542#M5015</link>
      <description>&lt;P&gt;Hi Experts,&lt;/P&gt;&lt;P&gt;I am having some troubles about P2020’s machine check interrupt. Could someone kindly help to answer my questions below? Thanks in advance!&lt;/P&gt;&lt;P&gt;The hardware board is produced by ourselves with a P2020 on it. Our software applications run under a embedded OS.&lt;/P&gt;&lt;P&gt;The system raise a machine check exception from time to time. When it happens:&lt;BR /&gt;- (MCSR) Machine Check Syndrome Register is 0x8, this indicates a “BUS_RBERR(Bus read data bus error)”&lt;BR /&gt;- (MCAR) Machine Check Address Register is 0xB000xxxx. This is a RapidIO address in system. However, I am sure system never read/write this address after initialization.&lt;BR /&gt;- (MCSRR0) Machine Check Save/Restore Register 0 usually points to a “sync” instruction, and occasionally points to a store instruction(the address of store instruction is a normal DRAM address used as function stack)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Currently&amp;nbsp; I cannot address the reason why machine check happen.&lt;/P&gt;&lt;P&gt;My questions are:&lt;BR /&gt;1.What is the meaning of a “Bus read data bus error”? It looks that my MCAR and MCSRR0 register value have no relationship with this syndrome type?&lt;BR /&gt;2.Do MCSR/MCAR/MCSRR0 always save the correct informations about a machine check exception?&lt;BR /&gt;3.I configure a address(say 0xc0000000) in MMU and do not configure it in LAW(Local Access Windows), system will immediately raise a machine check interrupt when 0xc0000000 is read, but if 0xc0000000 is written, there is no any interrupt/exception in system, is this a expected behavior of the processor?&lt;/P&gt;&lt;P&gt;Thanks.&lt;BR /&gt;Jerry&lt;/P&gt;</description>
      <pubDate>Sun, 19 Sep 2021 07:09:12 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1342542#M5015</guid>
      <dc:creator>GeekFork</dc:creator>
      <dc:date>2021-09-19T07:09:12Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1342756#M5016</link>
      <description>&lt;P&gt;1) BUS_RBERR gets set because the core_fault_in gets asserted to the CPU signaling a fault on the internal bus.&lt;/P&gt;
&lt;P&gt;Sources, capable to generate core_fault_in are described in the P2020 QorIQ Integrated Processor Reference Manual, Rev. 2, Table 5-1. Differences between the e500 core and the QorIQ core implementation, HID1[RFXE].&lt;/P&gt;
&lt;P&gt;2) The registers should contain correct data for unsuccessful read (uncorrectable read error) operations.&lt;/P&gt;
&lt;P&gt;3) Yes, see 2).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Note:&lt;/P&gt;
&lt;P&gt;RFXE should always be 0 for normal operation for the e500v2; it should be set only if it is necessary that the assertion of core_fault_in generate a machine check or a checkstop because peripherals are not properly configured to report bus faults. This would typically occur only during software or firmware development.&lt;/P&gt;</description>
      <pubDate>Mon, 20 Sep 2021 12:45:08 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1342756#M5016</guid>
      <dc:creator>ufedor</dc:creator>
      <dc:date>2021-09-20T12:45:08Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346306#M5017</link>
      <description>&lt;P&gt;Hi ufedor,&lt;/P&gt;&lt;P&gt;Thanks for your reply.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I set&amp;nbsp;&lt;SPAN&gt;HID1[RFXE] to 0, and the machine check still occur in my test. So is this a expected behavior? Or there is something wrong?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sun, 26 Sep 2021 10:49:51 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346306#M5017</guid>
      <dc:creator>GeekFork</dc:creator>
      <dc:date>2021-09-26T10:49:51Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346308#M5018</link>
      <description>&lt;P&gt;For possible sources of the machine check please refer to the PowerPC e500 Core Family Reference Manual, Table 5-8. e500 Machine Check Exception Sources.&lt;/P&gt;</description>
      <pubDate>Sun, 26 Sep 2021 11:00:01 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346308#M5018</guid>
      <dc:creator>ufedor</dc:creator>
      <dc:date>2021-09-26T11:00:01Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346311#M5019</link>
      <description>&lt;P&gt;When the exception occurs,&amp;nbsp;&lt;SPAN&gt;Machine Check Syndrome Register is 0x8(BUS_RBERR - Bus read data bus error), but the MCSRR0 and MCAR register do not provide instruction and address which have something to do with&amp;nbsp;BUS_RBERR. This is what are confusing me.&amp;nbsp; Do you have any other suggestions I can follow to look into the reason of&amp;nbsp; this exception.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;</description>
      <pubDate>Sun, 26 Sep 2021 11:19:49 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346311#M5019</guid>
      <dc:creator>GeekFork</dc:creator>
      <dc:date>2021-09-26T11:19:49Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346330#M5020</link>
      <description>&lt;P&gt;You wrote:&lt;/P&gt;
&lt;P&gt;&amp;gt; Machine Check Save/Restore Register 0 usually points to a “sync” instruction&lt;/P&gt;
&lt;P&gt;Which instruction is before the "sync"?&lt;/P&gt;</description>
      <pubDate>Sun, 26 Sep 2021 16:54:25 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346330#M5020</guid>
      <dc:creator>ufedor</dc:creator>
      <dc:date>2021-09-26T16:54:25Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346341#M5021</link>
      <description>&lt;P&gt;it's a store or read instruction. the access address of the instruction is a valid DRAM memory region&lt;/P&gt;</description>
      <pubDate>Mon, 27 Sep 2021 00:04:45 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1346341#M5021</guid>
      <dc:creator>GeekFork</dc:creator>
      <dc:date>2021-09-27T00:04:45Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1347213#M5022</link>
      <description>&lt;P&gt;How many boards were tested?&lt;/P&gt;</description>
      <pubDate>Tue, 28 Sep 2021 03:52:13 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1347213#M5022</guid>
      <dc:creator>ufedor</dc:creator>
      <dc:date>2021-09-28T03:52:13Z</dc:date>
    </item>
    <item>
      <title>Re: questions about e500v2 (P2020) machine check interrupt</title>
      <link>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1347305#M5023</link>
      <description>&lt;P&gt;Maybe 2 boards.&amp;nbsp; Both have the same result.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I am manually creating a machine check exception, and then to see if the software &amp;amp; hardware can provide the expected information (instruction address and the address instruction are reading).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'll ping you again when I collect other questions.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Much appreciate for your reply.&lt;/P&gt;</description>
      <pubDate>Tue, 28 Sep 2021 06:37:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/questions-about-e500v2-P2020-machine-check-interrupt/m-p/1347305#M5023</guid>
      <dc:creator>GeekFork</dc:creator>
      <dc:date>2021-09-28T06:37:35Z</dc:date>
    </item>
  </channel>
</rss>

