Questions about boot process of LPC1769

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Questions about boot process of LPC1769

1,286 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MOLINARO on Wed Apr 09 10:15:56 MST 2014
Hi,

I am new with LPCXpresso1769 board, and I have two questions about the boot process of LPC1769. My programs run fine, I am just asking for explanations.

I have read the User Manual, UM10360, Rev 3 (20 December 2013) and section 32.3 says:

Quote:

Pin P2.10 is used as a hardware request signal for ISP and therefore requires special attention. Since P2.10 is in high impedance mode after reset, it is important that the user provides external hardware (a pull-up resistor or other device) to put the pin in a defined state. Otherwise unintended entry into ISP mode may occur.



But I have found in section 9.2.1:

Quote:

All I/Os default to input with pullup after reset.



So what is the state after reset ? In LPCXpresso 1769 board, it seems that P0.12 is not connected.

The second question is about "Criterion for Valid User Code" (section 32.3.1.1):

Quote:

The reserved Cortex-M3 exception vector location 7 (offset 0x 001C in the vector table) should contain the 2’s complement of the check-sum of table entries 0 through 6. This causes the checksum of the first 8 table entries to be 0. The boot loader code checksums the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is transferred to the user code.



But the vector table generated by the new project wizard is:
void (* const g_pfnVectors[])(void) = {
    &_vStackTop, // The initial stack pointer
    ResetISR,                               // The reset handler
    NMI_Handler,                            // The NMI handler
    HardFault_Handler,                      // The hard fault handler
    MemManage_Handler,                      // The MPU fault handler
    BusFault_Handler,                       // The bus fault handler
    UsageFault_Handler,                     // The usage fault handler
    0,                                      // Reserved
...


The vector at location 7 is 0, and does not conform to the above rule. But, actually, program is running. So documentation is not accurate ?
Labels (1)
0 Kudos
Reply
2 Replies

1,091 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MOLINARO on Thu Apr 10 12:14:59 MST 2014
Thank you very much for your answer.

I have checked that OpenOCD computes also the checksum.
0 Kudos
Reply

1,091 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Wed Apr 09 23:40:00 MST 2014
The Tools take care of the checksum (location 0x1c) for you and update your image with the correct checksum. (Check the memory at location 0x1c to confirm for yourself).

[list]
  [*]When debugging, the debugger automatically calculates and writes the checksum into the image while it is programming the flash
  [*]For *binary* images, we provide a checksum utility that calculates the checksum and writes the correct value into the binary image.
  [*]The standalone FlashMagic application will perform a similar operation for you.
[/list]
HTH
0 Kudos
Reply