<?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>LPC MicrocontrollersのトピックLPC43S20 - using AES 128 with code size larger than internal SRAM</title>
    <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC43S20-using-AES-128-with-code-size-larger-than-internal-SRAM/m-p/574812#M19108</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by rsbogdan on Fri Nov 13 14:21:12 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;We currently use the LPC4337 and load code from the external flash using the 256-bit decryption in firmware. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;To move to a Flashless part for cost savings, we will need to use the the LPC43S30 AES 128-bit engine version to keep the Ethernet interface. (LPC43S20 seems to have better availability, but we can't use it)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The LPC43S30 has only 256kB SRAM internal. Our&amp;nbsp; overall code +&amp;nbsp; data memory size exceeds this, but I might assume that the AES engine can manage partial code blocks in SRAM (cache-style) ? &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Is it true that we can have an internal SRAM size smaller than our executable and we would just have wait states for code misses while (it's) loading alternate 128-bit blocks ? &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I can't find this in the AES functional description.&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 15 Jun 2016 18:57:45 GMT</pubDate>
    <dc:creator>lpcware</dc:creator>
    <dc:date>2016-06-15T18:57:45Z</dc:date>
    <item>
      <title>LPC43S20 - using AES 128 with code size larger than internal SRAM</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC43S20-using-AES-128-with-code-size-larger-than-internal-SRAM/m-p/574812#M19108</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by rsbogdan on Fri Nov 13 14:21:12 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;We currently use the LPC4337 and load code from the external flash using the 256-bit decryption in firmware. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;To move to a Flashless part for cost savings, we will need to use the the LPC43S30 AES 128-bit engine version to keep the Ethernet interface. (LPC43S20 seems to have better availability, but we can't use it)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The LPC43S30 has only 256kB SRAM internal. Our&amp;nbsp; overall code +&amp;nbsp; data memory size exceeds this, but I might assume that the AES engine can manage partial code blocks in SRAM (cache-style) ? &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Is it true that we can have an internal SRAM size smaller than our executable and we would just have wait states for code misses while (it's) loading alternate 128-bit blocks ? &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I can't find this in the AES functional description.&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 18:57:45 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/LPC43S20-using-AES-128-with-code-size-larger-than-internal-SRAM/m-p/574812#M19108</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T18:57:45Z</dc:date>
    </item>
    <item>
      <title>Re: LPC43S20 - using AES 128 with code size larger than internal SRAM</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/LPC43S20-using-AES-128-with-code-size-larger-than-internal-SRAM/m-p/574813#M19109</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by vtw.433e on Fri Nov 13 15:05:29 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;That is NOT correct. It is your responsibility for managing copying your application into internal RAM. None of the Cortex-M class devices support virtual memory (paging etc).&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 18:57:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/LPC43S20-using-AES-128-with-code-size-larger-than-internal-SRAM/m-p/574813#M19109</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T18:57:47Z</dc:date>
    </item>
  </channel>
</rss>

