Olimex LPC2378-STK ethernet problem

[TimC]

Hi All,
Running the latest rev uTasker v1.3 beta SP2
Had no problems with the simulation exercises, everything worked perfectly.  Double checked the changes in config.h to switch to the Olimex board and selected the LPC2378 chip.  My application.c changes worked in the simulator so they should work on the Olimex board too.

No problems compiling with CrossStudio 1.7 build 5
No problems loading with FlashMagic.

Turns out only the Thumb debug compile and JTAG load gives me the blinking LED  

Problem is: No FTP access no HTTP reply. 
My Olimex board is about 3 weeks old.

Any ideas on where I should dig to find my problem?

Thanks
Tim

[mark]

Hi Tim

The first thing to do is verify that all works when you install the reference software at http://www.utasker.com/software/software.html

This will verify that board basically works correctly.

I have tested the original build (not Beta SP2) with Crossworks 1.6 on the Keil board. Then the Beta SP1 on the Olimex board with IAR.

I will check the Beta SP2 with Crossworks 1.6 and confirm later.

Regards

Mark

[mark]

Hi Tim

I have just checked with the Beta SP2 and CrossStudio 1.6 on the Olimex board.
I works correctly with both FLASH DEBUG and FLASH RELEASE builds on my board.

Here are some notes:
1. Configuration is #define LPC2378FB144 (remove any other chips) + OLIMEX_LPC2378_STK
2. Although not a problem LCD support can be removed sinc ethis board doesn't have this (if it is left the LCD routine will be polling for the LCD to become ready, which will however not cause any problems - I tested with LCD still active).

Question:
- can it be compiler version/Crossworks version specific?
- have you verified that the board works using the hex file on the software page?
- Is the link LED lighting on the Ethernet connector?

Regards

Mark

[TimC]

Hi Mark,
I have made some progress but first to answer your questions
1. The defines: LPC2378FB144 and OLIMEX_LPC2378_STK confirmed
2. I disabled the LCD via //#define SUPPORT_LCD ... no change
Q1. Maybe a newer compiler.  we are both running old versions at this point
Q2. The hex file did not work either.  The LED never blinked
Q3. Yes I have a Link LED

Progress:
One time I was able to get a connection to the FTP server and after moving the WEB files I got an error. Do not remember what the error was. I tried many times to get it to work after that but no FTP connection.  The only other difference during the success was the LCP2378 LED started blinking right away and then the FTP worked. Every other time the LED stays lit for about 15 seconds after reboot then starts to blink.
Don't know if it matters but a lot of time is spent here:
    while (fnReadMII(DP83848_BASIC_CONTROL_REGISTER) & PHY_SOFTWARE_RESET) {// wait until reset completed

Hope we can get through this
Regards
Tim

[mark]

Hi Tim

Q1. Maybe a newer compiler.  we are both running old versions at this point
I don't expect a problem with the compiler due to Q2.

Q2. The hex file did not work either.  The LED never blinked
If the LED never blinks it can have 2 reasons.
1. The code is hanging before the LED is configured (I think that the LED lights when the port has not been configured). This could be related to fnReadMII() since if the code hangs waiting for the PHY to respond the watchdog may fire after 2s and then it will try again. (however the code does give up after a short wait andn return which would probably mean the watchdog will not fire and at least the LED will blink)
2. The code is not starting - the chip is in ISP mode (due to the ISP input '0' at reset or because the vector table has not been validated) The test version must be loaded with FLASH Magic since it will insert a check sum in the vector table so that ISP will let the code start. It can not, for exampel, be loaded with CrossStudio since this doesn't set this and so the code will never start.

Q3. Yes I have a Link LED
The PHY will generally boot to a mode where it can autonegotiate. This mena sthat the link LED may light even if there is no SW on the board. This is therefore possibly not so relevant...


Assuming it is not a startup problem (ISP / loading) there may be a communication problem with the PHY. I would check the board carefully - in fact on my board there was a missing pin on the Micrel chip (probably broken off when producing the board!) but it did still operate correctly...

With the debugger you may be able to determine whether the PHY is returning sensible values when it is read.

Regards

Mark

[TimC]

Mark,
I have been able to get the Olimex board to successfully run about 10 times.  Each of those 10 times the LED blinked without waiting.  Usually the board would start successfully after I paused the debugger then restarted without reload OR stopped the debugger then did a restart without a reload. I could not come up with a clear pattern that determined the success, however with every success I was using the JTAG to load and the thumb debug configuration.

The ISP load with Flash Magic has not worked but neither has the thumb release configuration via JTAG.

Once the board had started everything worked and was solid, running for hours, FTP, HTTP and web pages also Telnet worked.

I also ran all the projects that came with CrossStudio for the LPC-2378 without problems, sadly there is no Ethernet project to test.

I don't know what to determine from fnReadMII just that if I can complete the read I am ok.

I checked the board for any bad solder points but did not find any.
My feeling it's the PHY startup that my board can not get past, or mabe a hardware version issue??

Is there a project somewhere that does a simple PHY test?

Regards
Tim
 

[mark]

Hi Tim

My feeling is that the PHY is not always starting in the correct mode. There were difficulties with the ATMEL and the Micrel (see http://www.utasker.com/forum/index.php?topic=161.0 ) but this was due to the fact that the ATMEL has active pull-ups on its GPIOs out of reset. It is necessary to actively drive the lines and command a second PHY reset.

The LPC23XX doesn't have pull ups (as far as I am aware) and so the PHY address and mode are defined purely by the hardware on the board. The PHY address is 0x01 as defined by the pull-up/pull-downs in the Micrel itself.

There are some other pins which define the operating mode which are very important. There is one (I don't remember what it is called but I did once have a problem with it) which defines the clock source for the chip; whether its local oscillator is stopped or used for the bus clock. This again is determined by pull-up/down. None of this can be influenced by the LPC23XX on the Olimex board because the Micrel Reset input is connected to the LPC23XX reset input and this can not be driven.

I am wondering whether the PHY clock is not always starting (?) or a mode is not always being latched reliably. I have to admit that I can't image how the use of the JTAG would influence this.

It may be an idea to remove all PHY related code to see what happens then. The PHY initialisation is not absolutely critical because it will normally power up to at least do something (the RMII mode is for example controlled by R16 on the Olimex board) - it would at least not be able to hang waiting on the PHY.

In order to test the PHY communication I would try to read the PHY identifier from every possible PHY address (0x01..0x1f) in a loop - this would require modifying the read routine to allow the PHY address to be passed as a variable rather than being fixed. This may for example show if the PHY address which is being assigned is 'jumping' around.

As mentioned above, the PHY address can not be influenced by the SW and is purely HW related. Presently I don't see that there is any error in the code which would make the interface unreliable. On my Olimex board I can't detect any problems since it starts always with every build.

My hope is that you can completely remove any PHY initialisation and live with the situation. I also wonder whether this problem will be found on other boards or if it is restricted to yours?

Regards

Mark

[seulater]

Tim, i had the same problem with it booting up. i know that the reset button does not fix this. however if you power the board off then back on it will work properly.

[olimex_man]

Hi.
After my problems with the new version of IAR (thanks Mark for the advice thats a problem with the newer version, without it I would still wonder what I´m doing wrong) unfortunately I´m having the same problem that is mention in this topic:
After flashing the hex files to the board (tried the hex files from the homepage and my own compiled) no http or ftp activity. The UART activity works fine, I can read it, change the config an so on. But trying to connect to the board with the web browser is not working.
All config are correct (IP-Adress, Gateway and so on) and I think the hardware is also ok, because the uIP example from IAR works fine.
At the moment I´m without any idea (still a beginner).
Thanks for any help.

Regards
Martin

[mark]

Hi Martin

I am a little worried at the moment because it seems that some boards work fine and others not.

There are cases with the Olimex (as yours) and also a known case with Keil boards (2 actually - the strange thing being that they have LPC2368 rather LPC2378 on them - my board have all LPC2378).

Presently I have the project on-line on my Olimex board at http://demo.uTasker.com and this runs well.

It is to be noted that the chips have had a number of bugs but the standard workarounds have been used. It is possible that different versions of the chip have different behaviour. At the moment I am a bit stuck without a reference HW with the problem...

I expect that it could be something to do with the PHY not being correctly recognised, which can be tested with a debugger:
fnConfigEthernet() in LPC23XX.c.

Do you have some help at your college to try some debugging? If you run the uTasker simulator and step through the code in parallel with the target debugger it is quite easy to see what is expected - so that possible differences are easily recognised.

Regards

Mark

[mark]

Hi Martin

Could you please also see whether there is a difference when you try using a 10M or 100MHz LAN? The MAC/PHY is set to autonegotiate and there is a doubt that there may be a problem with this and it doesn't work correctly (or always correctly) when connected to a 10M network. I will be testing this later on today - if it does turn out to be a configuration problem it will be possible to solve this issue quite quickly (I hope that it has something to do with this rather than errors in teh device...).

Regards

Mark

[olimex_man]

Hi Mark.
Thanks for the fast answers.
I tried using different LANs, no effect.

Debugging is at the moment a "little" problem for me, because the only possibility is GCC/Eclipse and the Olimex ARM-USB-OCD. No one here can help me with this tools. Would need some configuration files for debugging. Gonna try it on the weekend.

Regards.
Martin

[olimex_man]

Hi.
Debugging does not work. Read many entries in forums, tried all the hints. But after working for two days with the config files for openocd and gdb I have no more ideas.
And without debugging I can´t test where the problem lunching uTasker is.
Anyway, many thanks for you help.
If in future you find the problem, post it here please. Thanks.

regards
Martin

[mark]

Hi Martin

As you have just experienced yourself, the GNU tools - although they can work (and well) - can require a lot of work and research to actually get working. This is their major drawback and often it is still much cheaper (for professional users who's costs per day amount to high percentages of a license fee cost) to go for a commercial compiler.

I would however suggest that you look at Rowley Crossworks - this is GNU based but works "out-of-the-box" also with just about any debugger (like Olimex ARM-USB-OCD or wigglers). Generally you will need a debugger (not just because of this issue). You can get a free 30 day evaluation from Rowley http://www.rowley.co.uk/ and a personal license will cost £75.

As soon as I have more info about a solution to the known problem I will let you know.

Regards

Mark

PS. Don't forget that you can still work with the uTasker simulator to develop and test your own projects.

[olimex_man]

Hi Mark.
I downloaded crossworks evaluation version and gonna test now utasker with this. Debug works fine, test it with one of the crossworks examples.
Thanks for help.
Now I try to find the problem with the uTasker ethernet on my board.

Regards
Martin