Messages

1

NXP^TM LPC2XXX and LPC17XX / Re: Important note about LPC23xx and LPC24xxx Ethernet

« on: June 01, 2010, 04:33:19 AM »

Last year when I checked uTasker it really wasn't working yet on these MCUs.  I have found the LPC23XX to be very good MCUs for Enet.  The Enet core works flawless.  I get about 2-3 MegaBytes/sec with the lwIP stack.  Is the uTasker stack working now on these?  So what kind of TCP throughput is anyone getting with the LPC23XX and the uTasker stack?

2

µTasker general / Re: Execution PRoblem for Simulator

« on: April 06, 2009, 07:39:30 PM »

Tried your prebuilt example, it ran fine.  Call stack window on shows SHW95DLL.DLL single line entry with same adr.  This DLL is part of the Kensington mouse driver software.  I use an expert Mouse Trackball.  But it doesn't seem to bother your prebuilt exe.

3

µTasker general / Re: Execution PRoblem for Simulator

« on: April 06, 2009, 01:22:45 PM »

Your Uberwachung1 window shows this:

   ptr_TCP   CXX0017: Error: symbol "ptr_TCP" not found
   http_session   CXX0017: Error: symbol "http_session" not found
   gen_details   CXX0017: Error: symbol "gen_details" not found
   uart_reg   CXX0017: Error: symbol "uart_reg" not found
   present_HeapSize   1405
   ucLPC23xx.ucWDOG   Error: cannot display value

The debugger seems to indicate that the access violation is coming from the SHW95DLL.DLL and there is no source for that, so it only gives me machine asm.
Happens as soon as I Execute.

4

µTasker general / Execution PRoblem for Simulator

« on: April 06, 2009, 09:53:14 AM »

Trying to get the simulator running,  as per the PDF file instructions on LPC23XX.  I have Visual-6 and Wireshark.  Win2K/SP4.  It builds fine, but when I execute I get a dialog saying AppError, when I close that I get another dialog saying SHW95DLL.DLL error as shown below.  Any ideas?

5

NXP^TM LPC2XXX and LPC17XX / Re: Getting Started Issues

« on: February 16, 2009, 08:10:56 PM »

Yeah something is wrong with the LD file and/or the Startup asm.  This is what the map looks like:

.vectors        0x00000000       0x30
                0x00000000                __vectors_start__ = .
 *(.vectors .vectors.*)
 .vectors       0x00000000       0x30 Build\startup_gnu.o
                0x00000000                _vectors
                0x00000030                __vectors_end__ = (__vectors_start__ + SIZEOF (.vectors))
                0x00000001                . = ASSERT (((__vectors_end__ >= __FLASH_segment_start__) && (__vectors_end__ <= (__FLASH_segment_start__ + 0x40000))), error: .vectors is too large to fit in FLASH memory segment)
                0x00000030                __init_load_start__ = (__vectors_end__ ALIGN 0x4)

.init           0x00000030       0xec
                0x00000030                __init_start__ = .
 *(.init .init.*)
 .init          0x00000030       0xec Build\startup_gnu.o
                0x00000094                __irq_dis
                0x000000f8                end
                0x00000030                Reset
                0x000000b0                __irq_en
                0x000000c0                irq_handler
                0x00000030                reset_code

The init section should be before the vector section, I think.  Your LD file seems strange.  I don't think GCC can figure it out.  reset_code should be at 0x0.  It kind of seems to me like both the 'init' and 'vector' sections both have to be at 0x0, or vector needs to be at 0x30.  It's coming out backwards.  I'm not sure why you have these broken apart.  The code can never be run in RAM since it won't fit.

I tried putting in an .org 0x0 in the startup.s in the init section, but the linker is still forcing it up into 0x30.  The problem seems to be in the LD file.  Something's not right here.

6

NXP^TM LPC2XXX and LPC17XX / Getting Started Issues

« on: February 16, 2009, 12:22:41 PM »

I'm using an LPC2468 with GNUARM.  I got the PHY code mod'd for my PHY, and the PIN setup configured for my app PCB.  Took out the LCD define. Trying to get this started up now.

(1)  I would like to suggest that the Watchdog have a default OFF when supplied.  The first thing I had to do was track down all the places that activate the watchdog to disable it.  Does not appear to have a global define in config.h to do this.

(2) The trace starts off at 0x11C fnValidatedInit, then fnStartDefaultNetwork, then fnScan, then fnFlushSerialRx, tries to access 7FFFE2BB, then jumps to Pabt error.

0x7FFF.... is the IAP area I believe.  I have no idea why it is going there.

Any suggestions?

Chris.

7

NXP^TM LPC2XXX and LPC17XX / Re: Makefile for GNUARM

« on: February 14, 2009, 10:34:50 AM »

Yes I changed the lib to arm-elf-gcc and that fixed it.  Thanks.

I added my usual warnings, opt, and debug options.  Your code is pretty clean, but you have a number of local variables defined identical to global names.  Not good practice.  For example, take a look at fnSendHTTP_windows() in HTTP.C.  You have a function parameter defined as "ucPush", and then you define another local variable inside the routine with the same identical name "ucPush".  If you reference "ucPush" later, are you talking about the function parameter or the local variable?  This is needlessly confusing.  I get about 40 warnings most of which could be easily eliminated.

I am most interested to test your TCP/IP stack.  I had been running FreeRTOS.  I ported lwIP-1.3 over, and it has many problems/bugs.  Was not impressed.  Next I ported NicheLite-LPC.  The Niche code is extremely good, but unfortunately it appears to have it's arms tied behind its back in several places deliberately.  Interniche offered to resolve the issue if I purchased their $2400 yearly support.  Not so free after all.  More like bait and switch.

However the Niche stack code is ultra high performance, runs 90-100Mbps TCP with the LPC2468.  Virtually full line speed.  They do several things that are interesting: (a) They use dual sized DMA packet buffers (192 bytes and 1536 bytes).  IP traffic is either ARP/SYN/ACK/... small packets, or large TCP/FTP/... bulk data packets.  They prevent small packets from using up the big buffers. (b) They dynamically allocate the DMA buffers.  For example, rather than having say fixed 4-RX and 4-TX buffers, they have a pool of 8 buffers that can be used entirely for either RX or TX.  They float back and forth dynamically. (c) They have a pure ASM hand coded routine for checksum. (d) they have zero data copy.  Good stuff.  Third generation code. 

Your package seems to have a lot of bang for the buck.  A lot more coverage of different functions and utilities than I expected.  I need to study your files and figure out where everything is at, then port the pins to my product PCB, and mod the PHY code.  A couple questions:

- Does your SPI routines use DMA?
- Does you USB routines use DMA?

Thanks,  Chris.

8

NXP^TM LPC2XXX and LPC17XX / Re: Makefile for GNUARM

« on: February 13, 2009, 11:01:24 PM »

I use the make.exe that comes with GCC.  You are calling "cs" which I assume means code soucery whch I assume is some other IDE.  I already have paths into GNUARM/GCC.  The syntax and key words in your makefile appear to be unknown to gcc make.exe.  I'll play with it somemore, but I guess I'll have to create my own makefile.

9

NXP^TM LPC2XXX and LPC17XX / Makefile for GNUARM

« on: February 13, 2009, 08:40:46 AM »

Hi:

Just wondering if you already have a regular GCC Makefile, before I spend my time reinventing the wheel.  The one you have in the GNU example does not seem to work with GCC make.exe

Chris.