Clev663 board Breaking problem

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

Clev663 board Breaking problem

2,590 Views
lim
Contributor II

Hi NXP 

i just debugged with a SDK example Basic discovery loop 

i can building a project but when i debug to the board that make a problem 

 

Break at address "0xdeadbeee" with no debug information available, or outside of program code.

 

Failed to execute MI command:
-data-disassemble -s 3735928558 -e 3735928698 -- 3
Error message from debugger back end:
Cannot access memory at address 0xdeadbeee

 

 

like that... do you have any idea about that problem?

Labels (1)
0 Kudos
Reply
5 Replies

2,544 Views
lim
Contributor II

lpc1769.PNG

 

Thank you for your helping

 

i just running the example project and displayed Basic Discovery Example 

but when i detected card ,board doesn't working...

 

0 Kudos
Reply

2,542 Views
frank_m
Senior Contributor III

I think you would need to debug into the SDK code, down to instruction level if necessary.

I do not have a CLRC663 board. But even SDK examples might contain bugs occasionally.

0 Kudos
Reply

2,563 Views
lim
Contributor II

캡처.PNG

Thank you for your replying .

i changed a debug information and it made other breaking point 

i used a SDK example i think project doesn't have problem...

 

Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)

HardFault_Handler() at semihost_hardfault.c:61 0xf092
<signal handler called>() at 0xfffffff9

0 Kudos
Reply

2,552 Views
frank_m
Senior Contributor III

> HardFault_Handler() at semihost_hardfault.c:61 0xf092
<signal handler called>() at 0xfffffff9

Now at least you got somewhere.

You can check the SCB fault registers to decode the reason, and/or single step through the preceeding assembler instructions to see where and why it faults.

 

0 Kudos
Reply

2,586 Views
frank_m
Senior Contributor III

> Break at address "0xdeadbeee" with no debug information available, or outside of program code.

The value looks suspiciously like a preset value for a stack check. Which would point to a stack overflow at runtime.

If this happens in the debugger before it stops on a breakpoint, try to disable "run to main", and start debugging at the reset vector.

 

0 Kudos
Reply