Getting started with LPCXpresso + LPC1768 custom board

[beloloprutek]

Hi,

could you please help me to get started with LPCXpresso and custom LPC1768 board (MiniDK2)?

I use STLinkV2 and OpenOCD for debugging. I have added OpenOCD as External Tool and I can connect to running OpenOCD via telnet localhost and control LPC1768 core (halt, reset, poll etc. commands).

I have also added Debug Configuration with GDB that should connect to OpenOCD via localhost. I think it also works ok (almost, because I have connect to OpenOCD via telnet and execute halt command to be able to run Debug but I assume it's a problem with code causing BusFault).

I have imported all projects from lpcopen_2_10_lpcxpresso_nxp_lpcxpresso_1769.zip to my workspace and what I have noticed is that projects are reffered to board and chip projects. I have removed standard Board_Init(); and Board_LED_Toggle(0); from blinky example and defined my own configuration of LED pins. To blink newly defined LEDs I use Chip_GPIO_WritePortBit(LPC_GPIO, LED1_GPIO_PORT_NUM, LED1_GPIO_BIT_NUM, flag);

My problem is that MCU jumps to BusFault_Handler(void) from startup file even before reaching main() function :-/

Could you please help me to move forward? I have no idea what is the reason of such behavior.

Or maybe could you give me a hint how to create absolutely clean/basic project containing only startup files and ready for LPCOpen usage?

[lpcxpresso_supp]

One thing to look at here is going to be - how are your downloading your image into flash to execute? The fact that you are seeing lots of movs r0,r0 in memory suggests that programming has not worked correctly.

Using one of our "natively supported" debug probes such as LPC-Link2, the IDE will do this automatically for you using our built in flash download technology. But this will not be available using your OpenOCD route and you will need to use the flash drivers that OpenOCD provides. I'm afraid that we can't provide any assistance on this. Nor can we provide assistance on configuring OpenOCD more generally.

Regards,

LPCXpresso Support

[beloloprutek]

Ok thank you for your answers. I will consider buying LPC-Link2.

[lpcxpresso_supp]

You haven't provided much information, but a Bus Fault is typically the result of an access to non-existent memory (e.g. NULL pointer). I suspect this issue may be related to missing board/chip initialization once you removed the board/chip libraries. What do you use for startup code? You didn't mention your development environment, but the lpcopen_2_10_lpcxpresso_nxp_lpcxpresso_1769.zip archive contains projects for the eclipse based LPCXpresso IDE. LPCXpresso does not support STLinkV2/OpenOCD so I presume you're using a third party eclipse based IDE. You might check what demos came with the Mini-DK2, and leverage some of the startup code. There should be CMSIS initialization examples available for download from a number of websites for that part.

Thanks and regards,

LPCXpresso Support

[beloloprutek]

Ok, I confirm that I am able to step through startup code mentioned above and when I reach

#if defined (__REDLIB__)

    // Call the Redlib library, which in turn calls main()

    __main() ;

#else

    main();

#endif

debugger jumps to } bracket ending ResetISR() routine and then jumps over fault handlers mentioned above and stops while loop in BusFault_Handler.

What is interesting, I have already stepped through SystemInit() and jumped into main() where I could step through LED blinking. But now I get BusFaults after startup again :-/ In the mean time I was changing Debug Configurations to allow GDB start without external "halt" in OpenOCD command line.

When I don't use debugger and just reset MCU to execute previously loaded firmware it blinks 2 LEDs as programmed. No BusFaults in such conditions?

I'm not familiar with LPCXpresso. What is the advantage in using it instead of clean Eclipse? What I have noticed is that projects generate makefiles so I don't have to create my own. There are also tools for projects import where chip and board projects can be selected. I assume there is quite big part that I am not aware of because of not using dedicated probes.

[beloloprutek]

Hi,

thank you for your answer. I use LPCXpresso v8.2.0_647 and I am a little bit shocked with your sentence "LPCXpresso does not support STLinkV2/OpenOCD". If it's intentional maybe I shouldn't say it out loud that my config seems to work :smileywink:

I have only removed call of Board_Init(); in main() to avoid wrong GPIO configuration like setting output on pin that should be an input with state forced by some external component. But everething seems to crash even before reaching that point. Or maybe I was misleaded by place of BusFault_Handler(void) definition and it gets back to cr_startup_lpc175x_6x.c file after some problems in main?

But if I recall correctly, I was stepping through code from startup (I will have to wait till Monday to confirm that):

// Copy the data sections from flash to SRAM.

    while (SectionTableAddr < &__data_section_table_end) {

        LoadAddr = *SectionTableAddr++;

        ExeAddr = *SectionTableAddr++;

        SectionLen = *SectionTableAddr++;

        data_init(LoadAddr, ExeAddr, SectionLen);

    }

    // At this point, SectionTableAddr = &__bss_section_table;

    // Zero fill the bss segment

    while (SectionTableAddr < &__bss_section_table_end) {

        ExeAddr = *SectionTableAddr++;

        SectionLen = *SectionTableAddr++;

        bss_init(ExeAddr, SectionLen);

    }

and then it looked like jumping over 3 handlers (that's a little bit weird) and stopping on last while loop:

__attribute__ ((section(".after_vectors")))

void HardFault_Handler(void)

{ while(1) {}

}

__attribute__ ((section(".after_vectors")))

void MemManage_Handler(void)

{ while(1) {}

}

__attribute__ ((section(".after_vectors")))

void BusFault_Handler(void)

{ while(1) {}

}

Examples that came with that board are for Keil and IAR so I wanted start with another IDE and after successful "blinky" example try to port/tweak some of them. I didn't think that startup code will do anything board specific :-/

[lpcxpresso_supp]

We don't claim to support the use OpenOCD/STLinkV2 for debugging with LPCXpresso IDE. Thus I am afraid that if you wish to do your own integration of such debug solutions, then you do so at your own risk and we are unable to provide you with specific assistance in using such a solution.

A list of the supported debug probes can be found in the LPCXpresso IDE documentation, and also in the FAQ at:Which debug probes are supported by LPCXpresso IDE with which MCUs? I would recommend that you consider obtaining an LPC-Link2 for use with LPCXpresso IDE: LPC-Link2|NXP. This low cost probe is what LPCXpresso IDE is optimised to work best with, and these can be obtained from many distributors, either standalone or built into LPCXpresso V2/V3 boards.

But all of that aside, there is some documentation on moving LPCOpen to work on different boards available that you might want to read:

How do I port LPCOpen to a new board?

One other thing you might want to try is using the LPCXpresso IDE new project wizard to create a new simple test project. Using the wizard should allow you to create a new project which only links against the chip library, and not the board library. This should at least produce an image which should be debuggable on your board, and hopefully avoiding the fault you are seeing with your tests so far.

Regards,

LPCXpresso Support

[beloloprutek]

I have created new simple project with wizard and indeed it's possible to create one without board project link. But unfortunately BusFault still occurs :-/. I wonder if it has anything in common with probe type or if it's another kind of problem or misconfiguration. I could purchase LPC-Link2 but I'd like to be sure that it will actually solve my problem.

I am able to compile & load code via Debug button and step through startup. What I've noticed is that code disassembly in instruction stepping mode looks very weird:

	ResetISR:
00000170:   movs	r0, r0
00000172:   movs	r0, r0
00000174:   movs	r0, r0
277	SectionTableAddr = &__data_section_table;
00000176:   movs	r0, r0
00000178:   movs	r0, r0
280	while (SectionTableAddr < &__data_section_table_end) {
0000017a:   movs	r0, r0
281	LoadAddr = *SectionTableAddr++;
0000017c:   movs	r0, r0
0000017e:   movs	r0, r0
00000180:   movs	r0, r0
00000182:   movs	r0, r0
00000184:   movs	r0, r0
282	ExeAddr = *SectionTableAddr++;
00000186:   movs	r0, r0
00000188:   movs	r0, r0
0000018a:   movs	r0, r0
0000018c:   movs	r0, r0
0000018e:   movs	r0, r0
283	SectionLen = *SectionTableAddr++;
00000190:   movs	r0, r0
00000192:   movs	r0, r0
00000194:   movs	r0, r0
00000196:   movs	r0, r0
00000198:   movs	r0, r0
284	data_init(LoadAddr, ExeAddr, SectionLen);
0000019a:   movs	r0, r0
0000019c:   movs	r0, r0
0000019e:   movs	r0, r0
000001a0:   movs	r0, r0
000001a2:   movs	r0, r0
280	while (SectionTableAddr < &__data_section_table_end) {
000001a4:   movs	r0, r0
000001a6:   movs	r0, r0
000001a8:   movs	r0, r0
000001aa:   movs	r0, r0
288	while (SectionTableAddr < &__bss_section_table_end) {
000001ac:   movs	r0, r0
289	ExeAddr = *SectionTableAddr++;
000001ae:   movs	r0, r0
000001b0:   movs	r0, r0
000001b2:   movs	r0, r0
000001b4:   movs	r0, r0
000001b6:   movs	r0, r0
290	SectionLen = *SectionTableAddr++;
000001b8:   movs	r0, r0
000001ba:   movs	r0, r0
000001bc:   movs	r0, r0
000001be:   movs	r0, r0
000001c0:   movs	r0, r0
291	bss_init(ExeAddr, SectionLen);
000001c2:   movs	r0, r0
000001c4:   movs	r0, r0
000001c6:   movs	r0, r0
000001c8:   movs	r0, r0
288	while (SectionTableAddr < &__bss_section_table_end) {
000001ca:   movs	r0, r0
000001cc:   movs	r0, r0
000001ce:   movs	r0, r0
000001d0:   movs	r0, r0
295	SystemInit();
000001d2:   movs	r0, r0
000001d4:   movs	r0, r0
307	__main() ;
000001d6:   movs	r0, r0
000001d8:   movs	r0, r0
317	}
000001da:   movs	r0, r0
000001dc:   movs	r0, r0
000001de:   movs	r0, r0
000001e0:   movs	r0, r0
000001e2:   movs	r0, r0
000001e4:   movs	r0, r0
000001e6:   movs	r0, r0
326	{ while(1) {}
	NMI_Handler:
000001e8:   movs	r0, r0
000001ea:   movs	r0, r0
000001ec:   movs	r0, r0
000001ee:   movs	r0, r0
331	{ while(1) {}
	HardFault_Handler:
000001f0:   movs	r0, r0
000001f2:   movs	r0, r0
000001f4:   movs	r0, r0
000001f6:   movs	r0, r0
336	{ while(1) {}
	MemManage_Handler:
000001f8:   movs	r0, r0
000001fa:   movs	r0, r0
000001fc:   movs	r0, r0
000001fe:   movs	r0, r0
341	{ while(1) {}
	BusFault_Handler:
00000200:   push	{r7}
00000202:   add	r7, sp, #0
00000204:   b.n	0x204 <BusFault_Handler+4>
00000206:   nop
346	{ while(1) {}

and actually BusFault_Handler is the first place where something "natural" occurs. Previous lines have no sense in my opinion. But while loops in C stepping behave as they should, jumping back to check condition once again etc. But stepping into function (F5) doesn't work, it just steps over :-/

[beloloprutek]

Thank you for these links. I will check them.

As far as I remember I wasn't able to click "Next" button in wizard if I didn't select proper board project but I will check that again.