LPC-4350-DB1

[lpcware]

Content originally posted in LPCWare by JohnR on Wed Jan 04 06:27:10 MST 2012
Hi All,

Does anybody know anything about the LPC-4350-DB1 development board on LPC4350.com? The board layout page shows a board with an Arrow logo but seaching on Arrow does not turn up anything.

JohnR

[lpcware]

Content originally posted in LPCWare by sjalloq on Sat Jun 02 10:22:01 MST 2012
I've just checked my board and I have a pre-production version: ESD11487RY.  Where will the errata be for this revision?

On a separate note, what example programs have people been using with the LPCXpresso IDE?  Should I just try and modify the Hitex eval board examples?

[lpcware]

Content originally posted in LPCWare by drs on Mon May 07 09:28:46 MST 2012
It should be Rev A but you should contact Arrow to be sure. They can read the part numbers on the chip and tell you for sure.

[lpcware]

Content originally posted in LPCWare by fcarlo on Mon May 07 05:39:09 MST 2012
Is there anyone that could tell me which is the silicon revision of the uC mounted on the board?
Thanks in advance.

[lpcware]

Content originally posted in LPCWare by JohnR on Sat Apr 28 05:28:34 MST 2012
Hi sjalloq,

Just the debugger (gdb) that comes with LPCXpresso and/or Red Suite. for hardware, I use an LPC-Link card from a LPCXpresso LPC1768 board, wired into the 10-pin debug connector on the Diolan board.

John.

[lpcware]

Content originally posted in LPCWare by sjalloq on Sat Apr 28 03:03:27 MST 2012
Hi John,

what debugger are you using with the Diolan?  I'm looking for a dev board to use with the nxpUSBlib and lpcxpresso.

Thanks.

[lpcware]

Content originally posted in LPCWare by JohnR on Tue Apr 03 18:16:31 MST 2012
Arrow have nothing about the LCD board - that's why I was hoping that Diolan would respond. There are schematics and a layout already shown on LPC4350.com.

JohnR

[lpcware]

Content originally posted in LPCWare by drs on Tue Apr 03 13:17:47 MST 2012
You should ask Arrow, they are the distributors.

[lpcware]

Content originally posted in LPCWare by JohnR on Tue Apr 03 07:48:28 MST 2012
Hi All,

I now have my Diolan board and so far all is well.

My question for today - when is the LCD extension board expected to be available?

JohnR.

[lpcware]

Content originally posted in LPCWare by dima2611 on Mon Mar 26 05:02:16 MST 2012
You were right! I got so unnerved with this bug that in the meanwhile I switched to a Cortex-M4 chip from STM. On this weekend, I tested your idea and it worked! So, the reason war the disabled USB PHY.

Anyway, 2 questions remain (however, I can live with them unanswered)

1. how was it possible that I could run the program with nxpUSBlib v0.92 before? I really could!
2. why this legitimate crash did not end up in the HardFault handler?

NXP should check if it is not a core fault.

Thank you very much!

/Dima

[lpcware]

Content originally posted in LPCWare by dima2611 on Mon Mar 19 12:30:10 MST 2012
The crash was NOT because of the disabled FPU.

Maybe, it is just the lack of the exception handler routines which causes this runaway-n-crash behavior? The debugger do not know where to jump on crash.

[lpcware]

Content originally posted in LPCWare by dima2611 on Wed Mar 14 06:55:16 MST 2012
I have an idea what could have caused this problem. Maybe, the compiler generates some FPU code or uses S-registers somewhere. The FPU is, however, disabled at the startup. So, probably, it is just a "usage fault" exception. The FPU must be enabled by setting corresponding bits in CPACR register.

Yesterday, I had similar crashes with STM32F407 which is a Cortex-M4 with FPU. The ARM documentation speak generally about all CM4.
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439c/DDI0439C_cortex_m4_r0p1_trm.pdf (page 77)

[lpcware]

Content originally posted in LPCWare by dima2611 on Tue Mar 13 09:07:02 MST 2012
Maybe, it is just one of those "unaligned load" issues that cause the crash?

And if it is soooo much life-saving to have data aligned in a right way, why it is not done by the compiler or the linker?

[lpcware]

Content originally posted in LPCWare by drs on Mon Mar 12 20:39:12 MST 2012
My mistake. The calls are:

USB_Init()->HAL_USBInit()->HAL18XX_USBInit()-> line 71:

    /* Turn on the phy */
    LPC_CREG->CREG0 &= ~(1<<5);

[lpcware]

Content originally posted in LPCWare by dima2611 on Mon Mar 12 16:32:34 MST 2012
__LPC18xx__ and USB_HOST_ONLY are defined as it is done in the example for LPCXpresso.
Since USB_HOST_ONLY is defined, USB_CAN_BE_DEVICE is undefined by the precompiler.

The only place where HAL_USBConnect(1) could be called is USB_Init_Device() which is not available in USB_HOST_ONLY mode.

[lpcware]

Content originally posted in LPCWare by drs on Mon Mar 12 09:54:36 MST 2012
The only other thing that I can think of which would cause this problem is if the PHY was not powered up. The bootloader for this part powers down the PHY on startup. But in the v0.92 release it is powered back up in HAL18XX_USBConnect() which should have been called before the line you are USB_ResetInterface().
Is it possible that __LPC18XX__ is not defined in your build?

[lpcware]

Content originally posted in LPCWare by dima2611 on Sun Mar 11 17:16:57 MST 2012
Hi drs,

please take a look. A possible reason is a simole register access...

http://www.lpcware.com/showthread.php?t=2988

My findings are way discouraging. I hope I have a bad chip.

/Dima

[lpcware]

Content originally posted in LPCWare by dima2611 on Mon Mar 05 12:16:31 MST 2012
The point is that I can step through the programm a bit. If I comment the USB initialization leaving all other stuff there, the debugger does not fail. So, it is not the wire speed's relation to the clock. It is some nasty relation in the HW.

[lpcware]

Content originally posted in LPCWare by drs on Mon Mar 05 11:49:25 MST 2012
Don't get discouraged. If it worked before with no hardware changes then it should work again. Unless you caught the dreaded "stop working on Monday morning" virus.

Sometimes the USB driver gets into a funny state and has to be reloaded. Sometimes the IDE leaves behind a zombie process that has to be killed.

Try:
unplug the JTAG USB cable
kill the IDE application
kill the wedged IDE process in task manager (lpcxpresso.exe *32)

If this doesn't work then power cycle the building...

[lpcware]

Content originally posted in LPCWare by dima2611 on Mon Mar 05 10:21:32 MST 2012
Hello all,

It got good before turning really bad.

I replaced the flash memory on the board with the same type used by Hitex. And then, I could download some programms in it and debug with Red Probe Plus. So far so good.

Now, (I did not touch it over the weekend) the whole setup seems "infected" with a nasty "lost debugger connection" virus. I keep getting the "Target error from status-poll" message in the original Mass storage host example as soon as the USB host gets initiated. I tryed lowering the wire speed down to 150 kHz. No help. Another simple LED blinky programm gets debugged just fine. The reasons for this fault described here (http://support.code-red-tech.com/CodeRedWiki/StatusPoll) make me think the whole thing is highly sensitive to smallest deviations of the design from the "ideal". It means for me, even if I would succeed using the original Hitex board, I would fail trying to clone it.

This is not the kind of tools I could rely on. I'm thinking of ending my Odyssey (I still could need a HS-USB and some floating point capabilities).

I'm sad.

[lpcware]

Content originally posted in LPCWare by dima2611 on Thu Mar 01 14:33:58 MST 2012
Maybe, you just need a correct driver. Maybe, the flash memory which is mounted is all wrong. I did a simple chip erase test with an example supplied with LPCXpresso 4.2. It took 13 (!!!!) seconds (I observed D6 pin which gets toggled when the chip is busy). It think it was just a timeout for whatever reason.

Anyway, I ordered the same memory as with Hitex boards from Farnell. It is pin-compatible but a bit different. I will try it tomorrow with flash drivers supplied by Code Red for LPCXpresso 4.2. You can find drivers for Keil here (Tools/Flash/Keil_Binaries):

http://www.lpcware.com/content/nxpfile/lpc4350apdlzip

Beware: you must replace the flash itself with the correct type. I will tell you if I would succeed tomorrow.