<?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のトピックReset behavior of LPC2368</title>
    <link>https://community.nxp.com/t5/LPC-Microcontrollers/Reset-behavior-of-LPC2368/m-p/552341#M14368</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by schneekette on Mon Dec 30 08:17:19 MST 2013&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi!&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'm having an issue with the LPC236x reset behaviour: On all my boards the RESET# signal is being completely ignored. When pulling RESET# (pin 17 on FBD100 package) to GND, nothing happens. The low does not even show up on RESET_OUT# (pin 14). The LPC just continues running.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Given:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* LPC2364 and LPC2368 in FBD100 package&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* connection of dedicated pins as on Keil MCB2300 (...maybe I'm missing something here?)&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* RESET# connected on pin 17&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Really tested:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;I must admit, that I would not believe it if someone told me. Therefore I really tried to touch pin 17 of the package directly with a GND connection to exclude the possibility of a bad solder joint or whatever. But the state of the RESET# pin is definitely ignored.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I could imagine the following reasons:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;1) There is some possibility of disabling the RESET# input by the setup of the other dedicated pins (debug port etc). Actually I'm quite sure that I have the same setup as Keil does on the MCB2300, but maybe I'm not seeing something.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;2) There is any possibility of disabling the RESET# input by software, which I'd find very unlikely.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;3) There is an issue on my controllers. But I tested 2 different LPCs explicitly for this behaviour and they behave identical.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;4) Any other idea?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'd expect the most likely reason to be that it is possible to turn off the RESET# input by hardware and I'm doing this by accident. But I did not find any documentation about that and no reports of other users.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Do you have any idea what could be the reason for this behaviour?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;And again: The low on&amp;nbsp; pin 17 is definitely there...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thank a lot!&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Stephan&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 15 Jun 2016 19:52:16 GMT</pubDate>
    <dc:creator>lpcware</dc:creator>
    <dc:date>2016-06-15T19:52:16Z</dc:date>
    <item>
      <title>Reset behavior of LPC2368</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/Reset-behavior-of-LPC2368/m-p/552341#M14368</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by schneekette on Mon Dec 30 08:17:19 MST 2013&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi!&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'm having an issue with the LPC236x reset behaviour: On all my boards the RESET# signal is being completely ignored. When pulling RESET# (pin 17 on FBD100 package) to GND, nothing happens. The low does not even show up on RESET_OUT# (pin 14). The LPC just continues running.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Given:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* LPC2364 and LPC2368 in FBD100 package&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* connection of dedicated pins as on Keil MCB2300 (...maybe I'm missing something here?)&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;* RESET# connected on pin 17&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Really tested:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;I must admit, that I would not believe it if someone told me. Therefore I really tried to touch pin 17 of the package directly with a GND connection to exclude the possibility of a bad solder joint or whatever. But the state of the RESET# pin is definitely ignored.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I could imagine the following reasons:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;1) There is some possibility of disabling the RESET# input by the setup of the other dedicated pins (debug port etc). Actually I'm quite sure that I have the same setup as Keil does on the MCB2300, but maybe I'm not seeing something.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;2) There is any possibility of disabling the RESET# input by software, which I'd find very unlikely.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;3) There is an issue on my controllers. But I tested 2 different LPCs explicitly for this behaviour and they behave identical.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;4) Any other idea?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'd expect the most likely reason to be that it is possible to turn off the RESET# input by hardware and I'm doing this by accident. But I did not find any documentation about that and no reports of other users.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Do you have any idea what could be the reason for this behaviour?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;And again: The low on&amp;nbsp; pin 17 is definitely there...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thank a lot!&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Stephan&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 19:52:16 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/Reset-behavior-of-LPC2368/m-p/552341#M14368</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T19:52:16Z</dc:date>
    </item>
    <item>
      <title>Re: Reset behavior of LPC2368</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/Reset-behavior-of-LPC2368/m-p/552342#M14369</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by TheFallGuy on Mon Dec 30 08:50:56 MST 2013&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Might be worth trying to "Ask NXP Experts" on the NXP main page:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;&lt;A class="jive-link-external-small" href="https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.nxp.com%2Ftechnicalsupport%23" rel="nofollow" target="_blank"&gt;http://www.nxp.com/technicalsupport#&lt;/A&gt;&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 19:52:17 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/Reset-behavior-of-LPC2368/m-p/552342#M14369</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T19:52:17Z</dc:date>
    </item>
  </channel>
</rss>

