<?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>Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/39291/vector-table-offset-lpc1788-vtor---nor-flash</link><description> 
Hello, 

 
I&amp;#39;m using uVision 4.20 and an LPC1788 development board. 

 
The development board has external NOR flash at CS0 (0x80000000).
I am able to download code to the external NOR flash using and INI
setup file but I can&amp;#39;t seem to write the VTOR</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/146694?ContentTypeID=1</link><pubDate>Thu, 09 Jun 2011 05:47:20 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f43f07c4-0254-40bd-b866-a777aa7dabdb</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for all the info.&lt;/p&gt;

&lt;p&gt;
So specifically for the LPC1788 what kind of performance
variations could one expect when running code from SDRAM versus
running from internal RAM (connected to I &amp;amp; D-Code buses).&lt;/p&gt;

&lt;p&gt;
Thanks.&lt;/p&gt;

&lt;p&gt;
Mac&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/145106?ContentTypeID=1</link><pubDate>Wed, 08 Jun 2011 20:27:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9d0a9375-373c-4e80-9faa-4b4cf61ed339</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Per,&lt;/p&gt;

&lt;p&gt;
Many Thanks for your detailed and enlightening elaboration.&lt;/p&gt;

&lt;p&gt;
I heard that, &amp;quot;the trend of MIPS is multi-thread, whereas the
trend of ARM is multi-core, but they both learn something from each
other.&amp;quot;&lt;/p&gt;

&lt;p&gt;
Just as what you said,&lt;/p&gt;

&lt;p&gt;
&amp;quot;In the end, we get general-purpose beasts, but with specialized
hardware hidden inside.&amp;quot;&lt;/p&gt;

&lt;p&gt;
&amp;quot;In the end, what we see is really the same trend. &lt;b&gt;We get
amalgamated processors&lt;/b&gt; where the manufacturer may randomly decide
to call their design Von Neumann or Harvard but &lt;b&gt;the real design
really is both or neither.&lt;/b&gt;&amp;quot;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/142901?ContentTypeID=1</link><pubDate>Wed, 08 Jun 2011 19:18:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2b7bbf37-0c86-4489-96b9-20cc5c2f932d</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Harvard and von Neumann are basically teoretical concepts that
only exists for older processors. Strictly following these two
architectures leads to much too many problems in real world
situations.&lt;/p&gt;

&lt;p&gt;
In reality, most processors wants to be von Neumann (to be
general) but with internal Harvard optimizations for concurrency.&lt;/p&gt;

&lt;p&gt;
On one hand, RAM is normally faster than flash, which is a reason
why faster processors normally always runs the programs from RAM and
only have flash as a kind of disk storage. Or why there are special
flash acceleration modules caching the flash accesses using a very
wide flash access bus much wider than the normal instruction size.
But if both data and code are stored in RAM, the step is very close
to allowing any RAM to be used for both code and data, allowing the
developer to decide how to best make use of the chip.&lt;/p&gt;

&lt;p&gt;
As the speeds goes up, the chips needs special optimizations. So
most faster chips needs caches between processor core and memory. And
with more advanced pipelines, it gets advantageous to extend the
ability to concurrent access by having separate code and data caches.
And then the caches will work better if the processor can have one
bus for filling the data cache and another bus for filling the code
cache.&lt;/p&gt;

&lt;p&gt;
Multi-port memories are very expensive and large. And with
single-port memory, all accesses must be strictly serialized. So it
is advantageous to split the memory into multiple blocks, and have
one access bus for each memory region, and then try to add a
multiplexer that allows switching of accesses between core caches and
peripherials to the different memory regions.&lt;/p&gt;

&lt;p&gt;
In the end, we get a situation where only small or old processors
will be either von Neumann or Harvard, while all newer and faster
processors just have to have be combinations.&lt;/p&gt;

&lt;p&gt;
The PC have always had a unified memory. But internally, the x86
processors got separate code and data caches many years ago. The PIC
chips have had separate memoriy regions just because it have been
natural to separate the read-only code memory from the read/write
RAM. But when the flash isn&amp;#39;t fast enough, or the chips gets enough
RAM that customers wants to be able to download software modules
dynamically into RAM and run, it gets contraproductive with strict
&amp;quot;DATA&amp;quot; memory.&lt;/p&gt;

&lt;p&gt;
Another thing here is that 8-bit processors have room for very
small OP-codes (and often originated at a time when the transistor
count had to be kept very low). So the OP-codes are very specialized,
where the separation between &amp;quot;code&amp;quot; and &amp;quot;data&amp;quot; opcodes tells what
subsets of memory addressing that will be performed. A move to 32-bit
processors means that the OP-codes can have enough bits to specify
generic memory addressing - a processor may not just be able to load
a register with data relative to another register + offset or
relative to two registers, but may just as well be able to perform a
code jump relative PC + register + offset.&lt;/p&gt;

&lt;p&gt;
In the end, we get general-purpose beasts, but with specialized
hardware hidden inside. And the developer can get just about anything
to function, but can get the chips to run more efficient when running
programs that can take advantages of the internal optimizations. So
we can place some variables on one RAM region for primary access by
the processor core, while having other variables in a second RAM
region where a DMA channel for ethernet or USB may perform accesses
with little interference with the interactions the core at the same
time makes with the first RAM region.&lt;/p&gt;

&lt;p&gt;
In the end, what we see is really the same trend. We get
amalgamated processors where the manufacturer may randomly decide to
call their design Von Neumann or Harvard but the real design really
is both or neither.&lt;/p&gt;

&lt;p&gt;
And the trend isn&amp;#39;t new. We have for a long time had something
called &amp;quot;Modified Harvard&amp;quot;, where the code memory have allowed data
access. All because the Harvard architecture is too much an academic
construct - clean and elegant but not practical. And the Von Neumann
architecture is practical but raw and brute force with scaling
problems.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/139928?ContentTypeID=1</link><pubDate>Wed, 08 Jun 2011 18:29:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c4e6eb16-6fb7-483a-bf8b-eb9b616347f7</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Recently, I am developing something for the Fujitsu F2MC-16LX and
Microchip PIC16 platforms.&lt;/p&gt;

&lt;p&gt;
It is interesting that:&lt;/p&gt;

&lt;p&gt;
Most PIC MCUs are Harvard architecture MCUs; but the newest PIC32
(based on MIPS32 M4K Core) has a Von Neumann architecture.&lt;/p&gt;

&lt;p&gt;
Whereas ARM7 MCUs are Von Neumann architecture MCUs; but the newer
Coretex-M3 has a Harvard architecture.&lt;/p&gt;

&lt;p&gt;
Different trends, with different reasons that I don&amp;#39;t
know/understand.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/136503?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 23:21:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:24871227-6f85-45fa-adbf-8cc91b7e4aa3</guid><dc:creator>Robert &amp;#160;</dc:creator><description>&lt;p&gt;&lt;p&gt;
TM&amp;gt;It might surprise you, but as far as I can recall, on a
LPC1788 that might actually slow your program (because of
architectural considerations - the chip cannot take advantage of its
Harvard architecture if not executing from internal flash).&lt;/p&gt;

&lt;p&gt;
Incorrect.&lt;/p&gt;

&lt;p&gt;
LPC17xx on-chip RAM mapped at 0x20XXXXXX (AHB SRAM) is connected
to System Bus but on-chip RAM mapped at 0x10XXXXXX (Local SRAM) is
connected to I-Code &amp;amp; D-Code Bus.&lt;/p&gt;

&lt;p&gt;
Running code from Local SRAM will be fast (chip can take advantage
of the Harvard architecture).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/139929?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:31:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e708b136-2b44-4d6b-bd57-5de7a935583f</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
I have a similar situation with a LPC2478. The program for that
product is organized in the following way:&lt;br /&gt;
1. bootloader(s) zone at the first 16[KB] of internal flash.&lt;br /&gt;
2. program components until the end of internal flash.&lt;br /&gt;
3. The rest of the program inside a NOR flash.&lt;/p&gt;

&lt;p&gt;
Note that you would need to:&lt;br /&gt;
1. Configure uv4 to program the NOR flash so you can debug.&lt;br /&gt;
2. Make sure your bootloader can program the application parts that
reside in NOR flash.&lt;br /&gt;
3. Adjust your scatter loading files to house a separate load region
for the NOR flash.&lt;br /&gt;
4. Create a small PC application that stitches the load regions
binaries generated by the linker together so that the bootloader can
program it seamlessly.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/130798?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:23:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:92f2948a-7644-476b-aed3-40fe5183a28f</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
I believe you are correct execution is fastest out or internal
flash, than iRAM, than SDRAM than external flash.&lt;/p&gt;

&lt;p&gt;
I can not use the internal flash because 1) it is too small and 2)
I have a bootloader that already lives there.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/126866?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:15:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa302e23-ab04-41f4-95eb-66441dd8f179</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Why do you copy the application into RAM in the first place? It
might surprise you, but as far as I can recall, on a LPC1788 that
might actually slow your program (because of architectural
considerations - the chip cannot take advantage of its Harvard
architecture if not executing from internal flash). Why not run from
internal flash? It is too small?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/116388?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:09:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:702e6dad-a941-4d4d-994e-a9c108fd475c</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
I guess that is what I&amp;#39;m asking.&lt;/p&gt;

&lt;p&gt;
What is the best strategy. I have a bootloader that lives in
internal flash. The bootloader (if not updating firmware) loads the
user application from external flash into SDRAM.&lt;/p&gt;

&lt;p&gt;
It loads the user application into SDRAM because it is too big to
load into iRAM.&lt;/p&gt;

&lt;p&gt;
I guess I have to split my user application into 2 binaries one
with the vector table that loads into iRAM and the other that loads
into SDRAM. Do this sound right?&lt;/p&gt;

&lt;p&gt;
Thanks.&lt;/p&gt;

&lt;p&gt;
M&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/126865?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:06:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cae142d3-98ae-4137-a63f-02c06b3f9d01</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
what if the NOR flash is somehow deleted (assuming it does not
carry code)? You&amp;#39;re 100% toast, as is your program...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/119291?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 05:05:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8eba06b4-6b7d-4fba-bdb2-5c81210793c8</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Do you really want to _physically_ separate the vector table from
the rest of the program? what if the NOR flash needs to be replaced
(assuming it does not carry code)?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/104920?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 04:59:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0b81afd8-7907-4c8f-960f-1dd3e82e2b32</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
I fail to see the problem. Why not have the vector table in the
internal flash or the internal RAM?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/79328?ContentTypeID=1</link><pubDate>Tue, 07 Jun 2011 04:54:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b101d5a5-7088-4c19-baa7-480a83fe804d</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for you reply.&lt;/p&gt;

&lt;p&gt;
That&amp;#39;s what I was afraid of.&lt;/p&gt;

&lt;p&gt;
What is the general strategy then when the user code is larger
than the devices (LPC1788) internal flash.&lt;/p&gt;

&lt;p&gt;
Do I need to split my user application binary into two (using
scatter file) so that I can load one into iRAM and the other into
SDRAM?&lt;/p&gt;

&lt;p&gt;
Basically I have a setup on an LPC2478 where I copy the entire
user application into SDRAM and remap the ARM7 vectors using the
MEMMAP register of that device.&lt;/p&gt;

&lt;p&gt;
I guess there is no way of doing this same strategy on the LPC1788
so I&amp;#39;m wondering what do people do normally?&lt;/p&gt;

&lt;p&gt;
Thanks.&lt;/p&gt;

&lt;p&gt;
M&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Vector Table Offset LPC1788 (VTOR) - NOR Flash</title><link>https://community.arm.com/thread/59485?ContentTypeID=1</link><pubDate>Fri, 03 Jun 2011 06:10:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:97c77616-902d-4537-9a1b-00f30080ab8c</guid><dc:creator>Robert &amp;#160;</dc:creator><description>&lt;p&gt;&lt;p&gt;
Vector Table can be used only for Code &amp;amp; SRAM region in
Cortex-M cores (addresses 0x00000000 .. 0x3FFFFFFF).&lt;/p&gt;

&lt;p&gt;
Bits 31..30 in VTOR register are not used and writing 0x80000000
will NOT set VTOR to 0x80000000.&lt;/p&gt;

&lt;p&gt;
So you can&amp;#39;t put the vector table in External memory.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>