<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>LPC1768 trouble</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/28361/lpc1768-trouble</link><description> 
I have weird situation on LPC1768 microcontroller. I have copied
project software from original to new folder for backup needs. I
compiled the copied program with uVision4 and download it to uC via
ulink2. The flashing process is stopped at 70% and</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/130849?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 22:51:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:db27b589-02b4-426a-9f8c-b59588b9727d</guid><dc:creator>Franc Hanzic</dc:creator><description>&lt;p&gt;&lt;p&gt;
I looked on new and previous startup file and find edited CRP code
in previous one.&lt;/p&gt;

&lt;p&gt;
;IF :LNOT::DEF:NO_CRP&lt;br /&gt;
;AREA |.ARM.__at_0x02FC|, CODE, READONLY&lt;br /&gt;
;CRP_Key DCD 0xFFFFFFFF&lt;br /&gt;
;ENDIF&lt;/p&gt;

&lt;p&gt;
Don&amp;rsquo;t ask me why the code was edited with semicolon,
I&amp;rsquo;m not the only developer in our company. Can be edited CRP
protection the reason of this problem?&lt;br /&gt;
But still, this startup code is working with other projects.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/127080?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 14:02:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:59a02183-0be0-45a7-b25d-afbd0e606f4b</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Note that at reset, there are no PLL settings. The PLL will be
activated a while later, after the primary boot loader have checked
any CRP settings, the signature of the interrupt vector table and the
state of P2.10.&lt;/p&gt;

&lt;p&gt;
If CRP allows it, and P2.10 requests it, then the primary boot
loader will wait for FlashMagic programming, and PLL settings will
not matter.&lt;/p&gt;

&lt;p&gt;
Note that it can be quite easy to manage to create settings that
violate the PLL limitations, which is why such changes should be done
with CRP disabled and preferably with a pause from boot until PLL
activation. If you for some reason have a corruption in the generated
binary, then a lot of interesting things can happen. Not only can you
get wrong PLL settings. You can also get the processor to enter
power-down state where it may shut down the flash and may stop the
oscillator.&lt;/p&gt;

&lt;p&gt;
Have you checked the map files to see what memory regions your
corrupt program tries to program? Does it reach outside of existing
flash memory? Does it contain data at address 0x2FC and the following
3 bytes?&lt;/p&gt;

&lt;p&gt;
If you can prove that the binary does not overwrite the CRP
address and does not program outside of existing flash, then it
really should be safe to program even a corrupt binary, since
reset+P2.10 should be enough to catch the processor and
erase/reprogram. It would be very interesting to know what address
range it tries to program when you say you lose it after about 70% of
the download.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/116496?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 13:35:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e00d3c98-e83c-4ffd-92e8-844f3afd4706</guid><dc:creator>Franc Hanzic</dc:creator><description>&lt;p&gt;&lt;p&gt;
I only checked startup and configuration files only, without
changes. I have no purpose to overclock the uC. Something has to
change in both files (corrupted?) when I compiled the program. The
previous version was working without problems. So, I have tried on 3
uC and they are useless now. I know that the highest level of CRP
totally lock the uC memory. The problem is that I cannot reset the
uC. Maybe there was problem in PLL settings and now the uC cannot
enter in init mode that includes reset and primary bootloader
sequence.&lt;br /&gt;
If the settings are the reason for this problem, then I think that
the other developers had similar problem &amp;ndash; or I&amp;rsquo;m only
one that make errors.&lt;br /&gt;
And yes, the pins are all inputs with 2.4V at reset.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/105239?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 12:44:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2528c761-2def-41c4-be76-d194793c7bd3</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
It&amp;#39;s a bit strange that you get 2.4V. I would have expected all
processor pins to be held at 3.3V while the reset is active - unless
there is external components drawing the signal low.&lt;/p&gt;

&lt;p&gt;
The reset condition should be all GPIO as inputs with a weak
pull-up activated.&lt;/p&gt;

&lt;p&gt;
2.4V is more common for a GPIO that is configured as input in
high-impedive mode.&lt;/p&gt;

&lt;p&gt;
When using FlashMagic, I would expect it to be impossible to
overwrite the primary boot loader. I don&amp;#39;t know about the design, but
it doesn&amp;#39;t seem impossible that the JTAG interface can perform an
overwrite. I haven&amp;#39;t checked how Keil implement their
JTAG-programming. It was my belief that they just downloaded a small
program into RAM, and then downloaded buffers data and had the tiny
help program call the primary boot loader to perform a standard IAP
to erase/program each sector. That is the &amp;quot;conventional&amp;quot; way to
program many chips, since it isn&amp;#39;t needed to know the electrical
interface, timing or temperature compensation etc for playing
directly with the flash memory.&lt;/p&gt;

&lt;p&gt;
But are you saying that you are permanently losing boards? From
your first post, I got the feeling that you could get in contact with
them somehow and then got them to work well if you reprogrammed them
with a build based on your original startup files.&lt;/p&gt;

&lt;p&gt;
A dangerous thing is that a &amp;quot;stupid&amp;quot; program can:&lt;br /&gt;
- deactivate the primary boot loader from supporting FlashMagic&lt;br /&gt;
- deactivate the JTAG interface&lt;br /&gt;
- configure the chip to use an impossible PLL setting&lt;/p&gt;

&lt;p&gt;
The above would result in a chip where you are locked out, and
that (because of the too high clock frequency) totally fails to run
after the PLL setting has activated. The chip might get warm. But
most importantly - almost everything gets &amp;quot;who knows what happens&amp;quot;
when all the internal clocking runs outside specifications. Note that
even the GPIO block is clocked.&lt;/p&gt;

&lt;p&gt;
Because of the above possibilities, it is very much recommended
that while experimenting with PLL settings etc, not to turn on any
code protect, and also to add an intentional delay loop before the
PLL code. So if the chip gets overclocked, you can still use this
delay time for catching it with JTAG and stop the execution.&lt;/p&gt;

&lt;p&gt;
I very much gets a feeling that you are for some reason
overclocking the chip. Of course pure speculation from my side.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/79559?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 09:48:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:97f46dac-866c-43c8-ace6-44d50a4f16ce</guid><dc:creator>Franc Hanzic</dc:creator><description>&lt;p&gt;&lt;p&gt;
But can be primary bootloader or reset function overwritten? I
have suspected CRP protection mode at beginning, but most suspicious
is that the reset doesn&amp;rsquo;t response anymore. The output pins are
at 3.3V in high state, but when you reset the uC, the output drops to
2.4V and stay at 2.4V when the reset button stays pushed in normal
operation. In my situation the output pins stay at 3.3V by pressed
reset button.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC1768 trouble</title><link>https://community.arm.com/thread/66900?ContentTypeID=1</link><pubDate>Mon, 05 Sep 2011 09:12:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a7f1126a-118d-4d07-8aa0-b44fbc3b2f80</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Not sure what goes wrong that makes the processor hang, but maybe
you are trying to download to a memory region that doesn&amp;#39;t contain
any flash memory. You should take a closer look at the map file for
the project.&lt;/p&gt;

&lt;p&gt;
Another thing to be careful about is that you can lock out the
internal boot loader and/or the JTAG interface if you happen to
activate the code-protect feature.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>