Internal error:Launch configuration types matching com.crt is 0.

[lpcware]

Content originally posted in LPCWare by kabirbansod on Tue Jun 09 06:44:44 MST 2015
I am trying to debug a code, can anybody tell me what this error means?

Internal error:Launch configuration types matching com.crt is 0.
Using com.crt.dsfdebug.crtmcu.launchType.

Also, on compiling contiki files for lpc1347, when i try to flash it i get  "Flash image too large for this license", the size of the file is 325 kb, is there any way to work around it?

Thank you.

[lpcware]

Content originally posted in LPCWare by kabirbansod on Tue Jun 16 06:21:54 MST 2015
Thanks a lot for all the help, the problem was because i was using printf, i have not provided libraries for dynamic memory allocation for now, so printf was jeopardising the memory values.  0:) 

EDIT: i exactly dont know how it all works but the culprit is printf.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Jun 15 10:52:31 MST 2015
When setting a program address manually, you have to ensure that the 'thumb bit' is set.
This is is bit zero (with a value of 1) so you should be using (in this specific case) 0x171.

This is covered in Joseph Yiu's Cortex guide (probably chapter 2 or 3).

Normally, "C" knows about functions and handles this transparently, but you a doing direct
manipulation and therefore have to handle this yourself.

Likewise in the register view and hard fault dump notice that the LR has the bottom bit set.
Mask this out to see what the return address actually is.

Mike.

[lpcware]

Content originally posted in LPCWare by kabirbansod on Mon Jun 15 03:06:51 MST 2015
Well not for lpc1347, there is one guy who was working on it, but he was in the process of building the port, moreover he was using an SD card whereas i don't have one on my board. 
Thanks a lot...i think that might be it, can you please tell me where i can learn more about handling such issues. Also what is USB ram, and is there anyway i can see the address mappings?

EDIT: While going through the symbols in image file (using objdump on the image file), i found that the address of protohread that needs to be run is 0x170, so while debugging i changed the address of protothread pointer to 0x170, the thread/function was loaded but again i got a hard fault :( . Is it illegal to do that?

Faults     = InvState
Fault PC   = 0x00000170
           = process_thread_hello_world_process in section .text
           = File: hello-world.c  Line: 23

Fault status registers:
IPSR       = 0x21000003: 3  (HardFault)
CFSR       = 00020000 (Configurable Fault Status Register)
HFSR       = 40000000 (Hard Fault Status Register)
DFSR       = 00000000 (Debug Fault Status Register)
MMAR       = e000edf8 [INVALID] (MemManage Fault Address Register)
BFAR       = e000edf8 [INVALID] (Bus Fault Address Register)
AFSR       = 00000000 (Auxiliary Fault Status Register)

Stacked registers:
R0         = 1000045c
R1         = 00000081
R2         = 00000000
R3         = 00000170
R12        = 000003f1
LR         = 000003d7
PC         = 00000170
PSR        = 20000000
SP         = 10001f58

[lpcware]

Content originally posted in LPCWare by LessThanZero on Sun Jun 14 23:56:45 MST 2015
I know close to zero about Contiki OS, but many thread problems are stack related (size or location). The LPC1347 has 12 KB of SRAM across three banks. Check the usage.

LessThanZero

EDIT: I thought there were known working Contiki examples on their website.

[lpcware]

Content originally posted in LPCWare by kabirbansod on Sun Jun 14 23:53:47 MST 2015
This is the program having main() function:

int main()
{
  platform_init();
  printf("Initializing\n");


  printf("Clock init done\n");

  process_start(&etimer_process, NULL);
  autostart_start(autostart_processes);                  # Error

/* Remaning Program */

}

Is it possible the the process is table is being overwritten beforehand because hello_world_process has the same values when it enters autostart_start function.  Contiki has stackless protothreads, so it mostly deals with static memory allocation, could it be possible i am doing something wrong in the linker script?

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Sun Jun 14 23:25:32 MST 2015
Perhaps because something is overwriting the processs table?

[lpcware]

Content originally posted in LPCWare by kabirbansod on Sun Jun 14 22:29:46 MST 2015
I am still not able to understand why the address of the thread is wrong. The file containing the hello_world process does gets compiled and so does all its headers. Here is the declaration of the process and thread in the file. For the definitions of macros i have added links.



PROCESS(hello_world_process, "Hello world process");                     # link 1
AUTOSTART_PROCESSES(&hello_world_process);                           # Adds hello_world_process to list of auto-starting processes.

/*----------------------------------------------------------------------*/

PROCESS_THREAD(hello_world_process, ev, data)                           # Link 2
{
/*
Hello-world program
*/
}
/*----------------------------------------------------------------------*/

Link 1: https://github.com/kabirbansod/Contiki-lpc1347/blob/master/core/sys/process.h#L307-310
Link 2: https://github.com/kabirbansod/Contiki-lpc1347/blob/master/core/sys/process.h#L273-275

The thread field of hello_world_process should have the address of  PROCESS_THREAD(hello_world_process, ev, data) but instead, it has an ASCII value! I am out of ideas on how to proceed.

[lpcware]

Content originally posted in LPCWare by starblue on Sat Jun 13 10:48:44 MST 2015
Your pointers seem to point into some ASCII strings: 0x6d697420 is ' tim' and 746e6576 is 'vent' (backwards due to little-endianness).

So check your initialization.

[lpcware]

Content originally posted in LPCWare by kabirbansod on Sat Jun 13 10:41:38 MST 2015
The process that throws error is being initialized, i get an error saying memory address not accessible, the address is 0x6d697420. I am using LPC1347 and this address should be out of range (or should it?). So is this a problem with the linker script i am using?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Jun 13 04:22:32 MST 2015
Because you have a precise bus fault, the BFAR register is showing the address that you program attemped to read.
Looks like your 'process list' contains crap at some point.

Stop in the debugger before executing the for loop and examine (a) process list itself to see if if has even been
initialised and, if so, (b) the items in the list to see if they are reasonable.
You have the contents of the BFAR register to determine if the next member is sensible or not.

This should be kinda obvious -- you have a memory fault, you are accessing memory via pointers, what is
the most likely suspect?

---

Quote:
I don't think anything can be wrong with this

---

Are you kidding me! After stupid typos, bad pointers are the NUMBER ONE "C" error. ALWAYS ask: where is this initialised (set up)?
Are the caclulations/addressing sensible?

Perhaps you should also buy yourself a good book on "C" too.

Cheers, Mike

[lpcware]

Content originally posted in LPCWare by kabirbansod on Sat Jun 13 03:28:35 MST 2015
I am just trying to port a basic led blinking program (in Contiki-OS) :(

I get the MemManage Fault Address register as invalid, i have not written any stub function for _sbrk (that is the function that handles malloc) could that be the reason? or could it be that i am using wring linker script? I assumed that if i compile the program with `--specs=rdimon.specs -lc -lrdimon` linker flag, i would not have to worry about functions in libc.  The line that FAULT PC points to (line 105) is this:

/* First make sure that we don't try to start a process that is
     already running. */
  for(q = process_list; q != p && q != NULL; q = q->next);

I don't think anything can be wrong with this, this is the values of Fault Status registers:


Faults     = PreciseErr
Fault PC   = 0x00000F92
           = process_start + 18 in section .text
           = File: ../../core/sys/process.c  Line: 105

Fault status registers:
IPSR       = 0x81000003: 3  (HardFault)
CFSR       = 00008200 (Configurable Fault Status Register)
HFSR       = 40000000 (Hard Fault Status Register)
DFSR       = 00000000 (Debug Fault Status Register)
MMAR       = 746e6576 [INVALID] (MemManage Fault Address Register)
BFAR       = 746e6576 (Bus Fault Address Register)
AFSR       = 00000000 (Auxiliary Fault Status Register)

I am currently going through the book by Joseph Yiu, but that willl take a lot of time!

[lpcware]

Content originally posted in LPCWare by whitecoe on Sat Jun 13 00:28:37 MST 2015
You could try the FAQ "Debugging a Hard Fault"  ;-)

HTH!

[lpcware]

Content originally posted in LPCWare by kabirbansod on Fri Jun 12 21:34:16 MST 2015
Thanks a lot. :) Now i am getting a hard fault (bear with me please, i am new to this) can somebody please tell me how can i debug this.
These are my register values:

Faults     = PreciseErr
Fault PC   = 0x00000F92
           = process_start + 18 in section .text
           = File: ../../core/sys/process.c  Line: 105

Fault status registers:
IPSR       = 0x81000003: 3  (HardFault)
CFSR       = 00008200 (Configurable Fault Status Register)
HFSR       = 40000000 (Hard Fault Status Register)
DFSR       = 00000000 (Debug Fault Status Register)
MMAR       = 746e6576 [INVALID] (MemManage Fault Address Register)
BFAR       = 746e6576 (Bus Fault Address Register)
AFSR       = 00000000 (Auxiliary Fault Status Register)

Stacked registers:
R0         = 10000460
R1         = 00000000
R2         = 00000000
R3         = 746e6576
R12        = 000003f1
LR         = 00000c1b
PC         = 00000f92
PSR        = 81000000
SP         = 10001fb8

Thanks a lot!

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 12 08:06:31 MST 2015
http://www.lpcware.com/content/faq/lpcxpresso/using-printf

[lpcware]

Content originally posted in LPCWare by kabirbansod on Fri Jun 12 07:54:46 MST 2015
Thanks a lot! :). But i am still not able to run my program! It is compiling without any errors but i cannot see the LEDS blinking. Can you tell me how can i direct printf statements to console? It has been mentioned in other posts that i will have to use semihosting library, how can i check which library am i using?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Jun 12 03:32:07 MST 2015
- Select the project
- File->Properties
- C/C++ Build/MCU Settings
- choose LPC1347
- Build your project

Before debugging the first time, you will need to create a Debug configuration (for 'normal' projects, LPCXpresso will create this when you press the Debug button - it will not do this for Makefile projects)
- right-click on the project
- Debug As...->Debug configurations
- select C/C++ (NXP Semiconductors) MCU Application
- press the New Launch configuration button (1st one in the button bar)
- On the Main tab, Browse the project for your executable

Once this is setup, you will be able to Debug (including pressing the Debug button on the Quickstart panel)

[lpcware]

Content originally posted in LPCWare by kabirbansod on Fri Jun 12 02:57:38 MST 2015
I am trying to port Contiki to lpc1347, i add the project as a "C/C++ Makefile project with existing code, how do i conform it to be NXP LPC1347?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jun 09 07:03:23 MST 2015
1. Internal error:Launch configuration types matching com.crt is 0.

The error means that the debugger does not recognise your project type. You need to make sure your project is set to be an NXP LPC1347.

2. Flash image too large for this license

This means that the size of the image is >256k. You need to purchase on LPCXpresso Pro license to remove this restriction.
However, an LPC1347 has 64k of Flash. Therefore, even if you purchased an LPCXpresso Pro license, you would be unable to use your application on and LPC1347. I suggest you look to reduce the size of your image to <64k.