Hi All
I though it be an idea to present an introductory document to working with the LPC23XX based on my experiences porting the uTasker to it. In a nut-shell, the porting work has taken rather longer than expected due to a lack of time to dedicate to the project and also various difficulties which were not always easy to explain when actually finding the time. Since the basic project is however now operational and I believe the initial difficultes have been mastered here is something to get the ball rolling:
Getting started with the LPC23XX
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.
Working with the debugger from internal SRAM
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.
For a program to be able to run from the internal SRAM, it must be linked accordingly. For this reason its code starts at 0x40000000 and the processor stack pointers are set to the top of the 32k SRAM space. This is defined by the linker script.
The code is downloaded by the debugger into RAM at this location and the PC is set to start operation from the first address 0x40000000.
What you need to know about the LPC23XX boot programmer
I have deleted the software in FLASH which was supplied with the board since it initialised some parts of the chip which could cause some difficulties – mainly because programs would run correctly when these initialisations were performed but unexpectedly not when the initialisations 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.
There are two checks which are performed
- first the input P2.10 is read (ISP input). If it is low the boot software continues to run*.
- secondly a value at the reserved interrupt vector location 0x00000014 is checked. This must be equal to the 2's compliments of the check-sum of the other vector values for the boot software to recognise a valid program and thus start execution at the address 0x00000000.
*On the MCB2300 board there is a switch marked INT0 which is connected via jumper J8 to P2.10. If the jumper is in position the boot software can be forced by resetting the board with also the INT button pressed. In addition the software used on the PC to load FLASH can control the reset line and the ISP input via hardware control lines. In some cases one has to be careful when connecting COM0 since a terminal may inadvertently hold the device in reset or cause it to be unintentionally started in ISP mode. To avoid this, jumpers J9 and J10 can be removed.
MEMMAP Register at location 0xe01fc040
This register is very important when working from internal SRAM. It has three possible values:
- 0x00 – 64 bytes of the boot software from its 8k boot block in FLASH from 0x7fffe000 is mapped to address 0x00000000.
- 0x01 – the start of internal FLASH (64 bytes starting at 0x00000000) is mapped to address 0x00000000 (i.e. where it is).
- 0x02 – the start of internal SRAM (64 bytes starting at 0x40000000) is mapped to address 0x00000000.
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.
If you connect a debugger to a target with no program loaded to it is possible to see that MEMMAP has the value 0x00 and then the boot software vectors are present from the address 0x00000000. By modifying the MEMMAP to 0x01 the empty FLASH is switched in and by modifying it to 0x02 the first 64 bytes of SRAM are visible. This can be a useful test when the board does something unexpected – either not starting the code as expected or not executing interrupts as expected – since it is then possible to verify that the expected memory is switched to the vector locations.
Clocks
The LPC23XX can run from several clock sources including an internal RC (Resistor/Capacitor) oscillator, and RTC (Real Time Clock) oscillator, a crystal and the output from a PLL (Phase Locked Loop) derived from one of the inputs.
My interest is to run from a PLL at maximum speed and, due to accuracy issues, to use an external crystal to achieve 72MHz.
There are two important points to bear in mind:
- first that the PLL in the first chips has some problems (check the revision that you have and the most up to data errata sheet) and so the code uses the recommended method of setting the PLL output to 288Mh from a 12MHz crystal before post-dividing by 4 to obtain the desired 72MHz speed.
- secondly, the boot software may set up the PLL to operate from the RC oscillator source. This fact, plus the fact that the boot software also programs some ports, means that it is best to not assume any particular state and thus be able to handle cases where the PLL is already programmed or not. When the PLL is already programmed it is important to correctly disable it before setting it up for the desired configuration.
Ports
As mentioned in the previous section it is important to remember that the boot program can have changed some port settings. In addition to this I found that it is important to actively set all port configurations to defaults on start up to ensure that ports also behaved as expected. This seems contrary to the details in the data sheet but it may also have something to do with the boot software operation – in any case the active initialisation solves any problems.
There is one difficulty that I always experience when debugging. If I stop the processor running and open a memory window which displays the FAST IO register values the content of these registers don’t seem to make any sense. Also the fact that the debugger displays them stops the FAST IO from working correctly any more. After resetting all works fine again just as long as I don’t have a windows causing the debugger to access them. This is strange and a nuisance but I simply avoid looking at them and then there is no further problem…
Running code from FLASH
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.
This program communicates with the LPC23XX via UART 0 (COM0 on the MCB2300 evaluation board). If there is no valid program already loaded in FLASH the LPC23XX start up the boot software automatically and waits for a synchronisation over the serial port. It is very easy to test whether it is basically operating by connecting a terminal emulator to the serial port and typing a question mark “?” – the board will adapt itself to the baud rate used and answer with “SYNCHRONIZED”.
If there is already valid software loaded in FLASH simply reset the board and keep the INT0 button pressed (ensure that the INT0 jumper is set so that this button is connected with P2.10).
Start FLASH MAGIC and configure it to use the appropriate COM port – I use 115200 BAUD which works reliably – and the device LPC2378, plus oscillator (12.000000) in the case of the MCB2300 board.
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 synchronisation 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.
Hopefully the software works correctly on the target, but if there is a need to debug it, debugging from FLASH works well, with the usual restriction of 2 program breakpoints.
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
