Beruflich Dokumente
Kultur Dokumente
(1/1)
mark:
Hi All
I am using the Keil MCB2300 evaluation board together with IAR and
a J-Link debugger. The following is a guide to understanding the
LPC23XX (the board uses the LPC2378) and how to overcome first
difficulties.
There are various bugs in the first versions of the device and the
evaluation boards tend to have these chips on them so one has also
to be wary of the restrictions and use the required workarounds to
ensure of no unnecessary problems.
The device has a total of 58k internal RAM but some of this RAM is
assigned generally for use by various peripheral devices and is not
contiguous in memory. Therefore first steps involve the use of 32k of
SRAM on the local bus which is located in the address range
0x40000000..0x40007fff. For a program to operating in internal RAM
its code and its variable must be located there – this restricts the size
of the program which can operate and so this method is only really of
use for more simple experiments and debugging of peripheral code.
Generally debugging code loaded to internal FLASH is required and
this will be looked at after the initial difficulties are solved.
I have deleted the software in FLASH which was supplied with the
board since it initialized some parts of the chip which could cause
some difficulties – mainly because programs would run correctly
when these initializations were performed but unexpectedly not when
the initializations failed. This can be confusing so it is best to ensure
that your own code is really working correctly without the
‘unexpected’ help of something which will not be there later anyway.
Even with no code loaded into FLASH the LPC23XX doesn’t just try
to run non-existent code but contains its own boot loader (called ISP
[In System programming] mode). This will either start code execution
or else stay in its own code where it supports FLASH programming
over UART 0. This FLASH programming will be explained later but
first a few details about how the boot loader decides whether to start
the code in FLASH or not.
0x00 is the default after a reset so that the internal boot software is
executed. If it decides to start a program in user FLASH it switches
the value to 0x01 so that the user code is mapped in to the reset
vector and starts it there. If code is to be run in SRAM the code
should set the value to 0x02 so that the vectors from
0x40000000..0x4000003f are ‘seen’ also between
0x00000000..0x0000003f so that interrupts will operate correctly.
Clocks
Ports
The first thing which needs to be solved to run code from FLASH is to
get it programmed. After compiling and linking the project with
settings appropriate for the target (linker script file for FLASH based
code) I load it using the program FLASH MAGIC. This is a free
software available on the Internet [http://www.flashmagictool.com/],
and developed by the company Embedded Systems Academy for
NXP – it should however not be used for production work according
to the programs notes.
In the ISP menu you can do some things like reading the chip’s
signature and checking whether its FLASH is blank. To program the
FLASH memory enter the path to the HEX file to be loaded (Intel
Extended format is required for it to be recognised). It may be a good
idea to verify the contents after loading by checking the option “Verify
after programming”. Although it is also possible to delete the FLASH
contents in the ISP menu it is practical to check the Ease option
“Erase blocks used by Hex File” so that it is automated. To program
just press the Start button and wait until it confirms that all has
completed.
Should something not work, verify that the board is really in ISP mode
by resetting with INT0 pressed. If working on your own hardware be
careful about the quality of the RXD signal at the UART input – I
know from experience that even the smallest glitches on the line can
cause synchronization or loading to fail. There are a number of posts
in various forums where people are despairing about not being able
to work with the ISP port. Usually bad capacitors in the RS232 driver
circuit or other problems are found to be the cause. In my case I had
a fast logic gate in the line which was ringing slightly (overshoot) and
this would almost always cause FLASH loading to fail somewhere
during the process. After removing this circuit (which was found to be
unnecessary in the design after all) we never had any problems again
– this was with LPC210X devices but I understand that the LPC2378
can also be sensitive.
The uTasker project supplies IAR projects to work in RAM and also to
compile to the target FLASH. The uTasker simulator also enables a
large part of the development/debugging to already be performed in
the uTasker simulator environment on the LPC23XX so it is hoped
that debugging on the target is only necessary in some specific
situations.
This will eventually make its way into a new tutorial for the LPC23XX.
Comments are welcome.
Regards
Mark
Navigation