<?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 Pair of MC9S08AC60-cannot program-periodic reset? in 8-bit Microcontrollers</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Pair-of-MC9S08AC60-cannot-program-periodic-reset/m-p/573065#M22104</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;I am migrating a design from using a pair of older MC908GP32 microcontrollers to a pair of MC9S08AC60CPUE devices.&amp;nbsp; I am using P&amp;amp;E Micro USB Universal MultiLink and CodeWarrior Special Edition 10.6 in Win7 or the Classic IDE version on XP.&amp;nbsp; In the original design with the MON08-based MC908GP32 units, the /RST pins were tied together on the controllers - presumably so a fault reset on one would induce a reset on the other.&amp;nbsp;&amp;nbsp; Each device was programmable with P&amp;amp;E Micro's MON08 version Multilink cable. It all worked fine.&lt;/P&gt;&lt;P&gt;In the new design, I kept both /RESET pins on the MC9S08AC60 microcontrollers tied together, and brought the net trace also out to the RESET pins on the separate 6-pin BKGND debug headers (1 header for each device), but all tied to a common /RESET net.&lt;/P&gt;&lt;P&gt;I cannot program either device because it seems I cannot stay in BKGND mode. Always end up with Error 34 from PE Micro/programmer interface.&amp;nbsp; Vcc is very stable (5.0V), and there are 0.1uF caps on the RESET pins on each device. Placing a scope probe on the RESET pins indicates one (or both) of the new devices causing /RESET to pulse low approximately 75 milliseconds apart before going high again, even with new programming cable attached.&amp;nbsp; Is this normal behavior for brand new (virgin) devices?&amp;nbsp;&amp;nbsp;&amp;nbsp; If so, I guess I need to separate the /RESET pin connections to each micro and its respective&amp;nbsp; BKGD programming header so they don't interfere?&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks for any advice!&lt;/P&gt;&lt;P&gt;Mike&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 24 Jun 2016 15:25:35 GMT</pubDate>
    <dc:creator>mfugere</dc:creator>
    <dc:date>2016-06-24T15:25:35Z</dc:date>
    <item>
      <title>Pair of MC9S08AC60-cannot program-periodic reset?</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Pair-of-MC9S08AC60-cannot-program-periodic-reset/m-p/573065#M22104</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;I am migrating a design from using a pair of older MC908GP32 microcontrollers to a pair of MC9S08AC60CPUE devices.&amp;nbsp; I am using P&amp;amp;E Micro USB Universal MultiLink and CodeWarrior Special Edition 10.6 in Win7 or the Classic IDE version on XP.&amp;nbsp; In the original design with the MON08-based MC908GP32 units, the /RST pins were tied together on the controllers - presumably so a fault reset on one would induce a reset on the other.&amp;nbsp;&amp;nbsp; Each device was programmable with P&amp;amp;E Micro's MON08 version Multilink cable. It all worked fine.&lt;/P&gt;&lt;P&gt;In the new design, I kept both /RESET pins on the MC9S08AC60 microcontrollers tied together, and brought the net trace also out to the RESET pins on the separate 6-pin BKGND debug headers (1 header for each device), but all tied to a common /RESET net.&lt;/P&gt;&lt;P&gt;I cannot program either device because it seems I cannot stay in BKGND mode. Always end up with Error 34 from PE Micro/programmer interface.&amp;nbsp; Vcc is very stable (5.0V), and there are 0.1uF caps on the RESET pins on each device. Placing a scope probe on the RESET pins indicates one (or both) of the new devices causing /RESET to pulse low approximately 75 milliseconds apart before going high again, even with new programming cable attached.&amp;nbsp; Is this normal behavior for brand new (virgin) devices?&amp;nbsp;&amp;nbsp;&amp;nbsp; If so, I guess I need to separate the /RESET pin connections to each micro and its respective&amp;nbsp; BKGD programming header so they don't interfere?&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks for any advice!&lt;/P&gt;&lt;P&gt;Mike&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 24 Jun 2016 15:25:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Pair-of-MC9S08AC60-cannot-program-periodic-reset/m-p/573065#M22104</guid>
      <dc:creator>mfugere</dc:creator>
      <dc:date>2016-06-24T15:25:35Z</dc:date>
    </item>
    <item>
      <title>Re: Pair of MC9S08AC60-cannot program-periodic reset?</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Pair-of-MC9S08AC60-cannot-program-periodic-reset/m-p/573066#M22105</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Yes, indeed - having the RESET lines tied together - which was OK for the MC908GP processors that used the MON08 ROM routines, doesn't work well with the BKGND Debug controllers in the MC9S08AC60 devices.&amp;nbsp;&amp;nbsp; Separating the (2) /RESET lines allows the Universal MultiLink programmer to do its job and unprotect, erase, and program the chips.&lt;/P&gt;&lt;P&gt;I will have to look at wiring and output pin to an IRQ pins on the devices to see about implementing a method to allow each device to cause a reset-inducing interrupt on the other.&lt;/P&gt;&lt;P&gt;I'll leave this here for posterity/future reference.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 27 Jun 2016 13:34:07 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Pair-of-MC9S08AC60-cannot-program-periodic-reset/m-p/573066#M22105</guid>
      <dc:creator>mfugere</dc:creator>
      <dc:date>2016-06-27T13:34:07Z</dc:date>
    </item>
  </channel>
</rss>

