Inconsistent Code execution on 1114/301

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

Inconsistent Code execution on 1114/301

1,115 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mark_t3 on Thu Feb 24 17:24:23 MST 2011
I’m having bizarre code execution problems.
  I have LPCxpresso board for an lpc1114/301 target and I took the system tick example.
  I replaced the main code with this. A simple toggle of the Port0_10.
  I have a scope monitoring the port pin. 



  [B][COLOR=#7F0055][FONT=&quot]int[/FONT][/COLOR][/B][COLOR=black][FONT=&quot] [B]main[/B] ([/FONT][/COLOR][B][COLOR=#7F0055][FONT=&quot]void[/FONT][/COLOR][/B][COLOR=black][FONT=&quot]) {[/FONT][/COLOR][FONT=&quot][/FONT]
  [COLOR=black][FONT=&quot]      SetGPIOOut(0,10);[/FONT][/COLOR][FONT=&quot][/FONT]
  [COLOR=black][FONT=&quot]      [/FONT][/COLOR][B][COLOR=#7F0055][FONT=&quot]while[/FONT][/COLOR][/B][COLOR=black][FONT=&quot](1){[/FONT][/COLOR][FONT=&quot][/FONT]
  [COLOR=black][FONT=&quot]            ToggleGPIOBit(0,10);[/FONT][/COLOR][FONT=&quot][/FONT]
  [COLOR=black][FONT=&quot]      }[/FONT][/COLOR][FONT=&quot][/FONT]
  }
 

The port is toggling in bursts of 6-10 toggles and then it is flat line about 80% of the time.  As far as I can tell the CPU is not running for 80% of the time.
 

If I try to step any code it just starts running and I have to manually stop it.
 

Sometimes the Debugging connection goes down with a 15 or 16 error and I have to pull the USB cable to restore it.

When the link goes down the target stops running.

  I’m running Win7 64 pro.
  I have tried running in a VM with winXP 32 but cannot get the debug connection to link up with the board.
0 Kudos
Reply
4 Replies

1,103 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mark_t3 on Fri Feb 25 15:49:52 MST 2011
Got it  :)

I was trying to use the debug pins as GPIO's.

Thanks All
0 Kudos
Reply

1,103 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Thu Feb 24 23:07:37 MST 2011
To avoid problems with function / macro just test a simple:

LPC_GPIO0->DATA^= (1 <<10);

To avoid problems with PIO0_10 use PIO3_0 :):)

Default setting of PIO0_10 is SWCLK. That's part of SWD (= Serial Wire Debug) :eek:

See IOCON_SWCLK_PIO0_10 register.

So just use another pin and check it's default function (that's always a good idea).
0 Kudos
Reply

1,103 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Thu Feb 24 20:59:36 MST 2011
First, double check your optimization setting in your project build. Set optimization to None. It's possible the debug experience is compromised by an optimization setting. If the optimization level is set to None, it's possible the debug information emitted by the compiler for the while(1) loop is insufficient.

If ToggleGPIOBit is a function (or inline function), you should be able to high-level step into the function, and this should reflect in the source display. If the problem manifests attempting a high-level step over of ToggleGPIOBit, this suggests GDB did not find an appropriate place to either set a break point, or identify a target address to terminate the instruction step. If you suspect this is the case, add a NOP instruction to the while loop after the call to ToggleGPIOBit (see below), and retest. Note that if ToggleGPIOBit is a macro, there is no usable debug information generated. GDB is unlikely to be able to do the right thing.

static inline void __nop(void)
{
    asm volatile ("nop");
}

Regards,
CodeRedSupport
0 Kudos
Reply

1,103 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by larryvc on Thu Feb 24 18:28:41 MST 2011
I don't have an LPCXpresso1114 but if you post your code it will allow others to see what it is you're doing and try it on their boards as well.

Did you write the ToggleGPIOBit routine?
0 Kudos
Reply