Weird behavior debugging Embedded Artists LPC4088 Quickstart Board using LPC-Link-2

[lpcware]

Content originally posted in LPCWare by KiloMike on Thu Jul 02 14:07:18 MST 2015
Hi,

I am running into some weird behavior when debugging a simple "hello world" program on an LPC4088 Quickstart Board using an LPC-Link-2. The processor seems to hard fault, lock up or the LPC Link looses control of the 4088 quickstart board (I am not sure which) when I read or write certain registers. That may just be a red herring though. The problem may be happening after a fixed number of clock cycles or some fixed amount of time.

I am using:

Crossworks 2.3.5
Segger J-Link driver to connect Crossworks to the LPC4088 quickstart board via the LPC-Link-2
Embedded Artists LPC4088 quickstart board

The Segger J-Link driver/ Crossworks 2.3.5 / LPC-Link-2 tool chain works with the Xpresso LPC812 and LPC1549 dev boards that I have

I have read the FAQ on design considerations for debug (http://www.lpcware.com/content/faq/lpcxpresso/debug-design)

I have confirmed that the Segger J-Link driver is configured for SWD mode

I have a 4 kb stack allocated in my project properties.

The 'hello world' program is very simple. I am only trying to configure the PLL. The 'Setup_PLL' function is the first function called in Main. The debugger enters an unknown state when I read from the SPIFICLKSEL register. Commenting that line out just moves the point where the problem occurs to another line of code further down.


The code is as follows:

int main(void) 
{
  _u_int32 uCycleCount = 0;

  Setup_PLL();

  while( 1 )
  {
    uCycleCount++;
  }

  return 0;
}

void Setup_PLL(void)
{
  // Set-up system clock for use with a 1 - 25 MHz crystal
  SCS &= 0x0000006F;

  // Enable system clock
  if( SCS & 0x00000040 ) 
    SCS |= 0x00000020;
  else 
    return;

  // debugging code:
  _u_int32 uTemp1 = CLKSRCSEL;
  _u_int32 uTemp2 = CCLKSEL;
  _u_int32 uTemp3 = SPIFICLKSEL;
  // end debugging code

  // Ensure that the PLL is not currently the clock source
  USBCLKSEL = 0x00000000;
  PCLKSEL = 0x00000000;
  SPIFICLKSEL &= 0x0000001F;

  // Ensure the main oscillator is the PLL clock source.
  CLKSRCSEL = 0x00000001; 

  // Ensure that Sysclk is used as the input to the CPU clock divider (keeping CCLKDIV bits set to their default value).
  CCLKSEL = 0x00000001;

  // Disable the PLL.
  PLL0CON=0x00;
  pll_feed();

  PLL0CFG = 0x00000007;

  // Enable the PLL.
  PLL0CON=0x01;
  pll_feed();

  // Wait for the PLL to lock to set frequency
  while(!(PLL0STAT & PLL0STAT_PLOCK0));

  // Connect the PLL.  
  PLL0CON=0x01;
  pll_feed();

  // Set the PLL as the main clock source
  CCLKSEL = 0x00000101;

}

void pll_feed( void )
{

  PLL0FEED=0xAA;
  PLL0FEED=0x55;

}

Does anyone have any ideas?

Thanks in advance,

KM

[lpcware]

Content originally posted in LPCWare by KiloMike on Fri Jul 03 14:43:00 MST 2015

---

Quote: starblue
I've played a bit with an LPC4088 Quickstart, LPC-Link2 as CMSIS-DAP and LPCXpresso 7.8.0, with the lwip_tcpecho_freertos example.  It worked fine, including debugging.

---

Thanks, yeah. Emboldened by a new day, I looked at it on the scope this morning. Turns out that the LPC-Link-2 board has a 100K pull-up resistor on the SWDIO line while the LPC4088 quickstart board has a 33k pull-down resistor on the same line. The two fight each other when the pin is allowed to float but it still correctly toggles high/low as required.

I then went back through my code and I found the bug. I was setting the PCLKSEL register to 0x00000000, which turns off the peripheral clock so that no clock will be provided to APB peripherals. I'd misread the 4088 user manual, paragraph 3.10.6 "PLL configuration sequence" section where it explains how to switch clocks away from a PLL output before setting up the PLL.

[lpcware]

Content originally posted in LPCWare by starblue on Fri Jul 03 12:25:20 MST 2015

---

Quote: KiloMike
If the above inconsistency is the cause, then presumably others would have had difficulty getting the LPC4088 quickstart board to work with the LPC-Link-2, regardless of which compiler they are using?

---

I've played a bit with an LPC4088 Quickstart, LPC-Link2 as CMSIS-DAP and LPCXpresso 7.8.0, with the lwip_tcpecho_freertos example.  It worked fine, including debugging.

There might be an issue that the board is using more power than the debugger can provide. I didn't explore it in detail, as I will provide power externally.

[lpcware]

Content originally posted in LPCWare by KiloMike on Thu Jul 02 15:39:10 MST 2015
Reading the FAQ on design considerations for debug (http://www.lpcware.com/content/faq/lpcxpresso/debug-design) again, I wonder if it might be a hardware problem?

I have the PB1 rev of the LPC4088 quickstart board. The schematic for that board shows a 33K pull-up resistor on the HDK_MBED_SWCLK line, a 33k pull-down resistor on the HDK_MBED_SWDIO line and no pull-up or pull-down resistor on the HDK_MBED_SWO line.

This seems to be contrary to the FAQ that indicates to use a 10K-100K Ohm pull-down resistor on HDK_MBED_SWCLK and a 10K-100K Ohm pull-up resistor on HDK_MBED_SWDIO and HDK_MBED_SWO.

The FAQ does note that although a pull-down is recommended on the HDK_MBED_SWCLK line, you can alternatively use a pull-up.

If the above inconsistency is the cause, then presumably others would have had difficulty getting the LPC4088 quickstart board to work with the LPC-Link-2, regardless of which compiler they are using?

KM.