µTasker Forum
µTasker Forum => NXPTM LPC2XXX and LPC17XX => Topic started by: TimC on January 31, 2008, 02:14:55 AM
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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.
-
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
-
Martin
Great - Rowley is certainly a great solution for using GCC without the investment needed to get everthing working. It has probably the widest debugger support available and also included optimised libraries and very good support!
Regards
Mark
-
Hi Mark.
I found something. I run the debugger and the simulator and compare every statement and the written values in fnConfigEthernet() ....no differences.
BUT
ulPhyIdentifier = fnReadMII(DP83848_PHY_IDENTIFIER_1); // check that the PHY is working correctly by reading its identifier
ulPhyIdentifier <<= 16;
ulPhyIdentifier |= fnReadMII(DP83848_PHY_IDENTIFIER_2); // check that the PHY is working correctly by reading its identifier
if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) {
return; // if the identifier is incorrect the phy isn't resonding correctly
}
at this point the target failed the if-instruction and returns. So, as you thought, its a problem with the PHY.
-
Martin
If you ignore the PHY check it may then run correctly. However, can you say what value is being read from the PHY?
Regards
Mark
-
I removed the PHYcheck and it works now. Great. Thank you for the help.
But one more thing is strange:
It is not working every time. Sometimes it return in the following statement:
while (fnReadMII(DP83848_BASIC_CONTROL_REGISTER) & PHY_SOFTWARE_RESET) {// wait until reset completed
if (--i == 0) { // quit if no response
return;
}
}
So it is necessary to restart a few times.
However, can you say what value is being read from the PHY?
The expected value is 0x20005C90. Is that right? The debugger shows that the value that is being read is 0x00221610.
Regards
Martin
-
Martin
The Olimex board uses a Micreal KSZ8721BL as PHY. I think that your project may be set up to use the DP83848 as is on the KEIL board - check that you are using the define OLIMEX_LPC2378_STK, and not KEIL_MCB2300 (in config.h). Check also that you have at least service pack 1 installed since the Olimex board was not supported in the orginal release.
You say that you are reading 0x00221610 - the Micrel part has the ID 0x00221619 (are you sure about the 0 at the end?)
The number is read from two registers and has the following meaning:
- 0x002214 is the OUI (Organisationally Unique Identifier) belonging to Micrel b0000000000100010000101
- 0x21 (overlaps with the end of the OUI) b100001 and is the manufacturer's model number - ie the KLZ8721BL
(the above is then 0x0022161x)
- then follows a 4 bit revision number b1001 = 0x9 according to the latest data sheet, giving the ID which is checked for.
If you are really reading a 0x0 at the end it means that the chip must be rather old!!
There is however something which needs to be improved. If you look in the check it is like this:
(ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER
The idea of the PHY_MASK is to mask out the revision number when comparing, but the Olimex project uses this set to 0xffffffff, so it will not accept PHYs with changed revisions. The reason for this is probably the Micrel data sheet where the text to the revision numer if misleading:
Revision number : 4 bit manufacturer's model number.
This is not a model number and so could change!!
If your code is really checking against 0x20005C90 it is expecting the NATIONAL DP83848 identifier (from Keil board). Otherwise they are however more or less equivalent.
If the reset command is sometimes failing you could try increasing the wait time allowed:
i = 1000000; -> i = 10000000; to see whether it is a timing issue or not.
If it still sometimes fails it is probably some communication unreliability rather that the wait limit being critical.
Good luck
Regards
Mark
-
Hi.
You say that you are reading 0x00221610 - the Micrel part has the ID 0x00221619 (are you sure about the 0 at the end?)
You are right, it is a 9. Don´t know where i saw the 0.
But the other thing is strange. As you see
/#define _LPC21XX // specify LPC21XX subset
#ifdef _LPC21XX
#define IAR_LPC210X
#define TARGET_HW "IAR LPC210X Card"
#else
#define OLIMEX_LPC2378_STK
#define TARGET_HW "OLIMEX_LPC2378_STK"
#endif
I changed the value in config.h. Nevertheless the checking value is 0x20005C90.
I´m using uTaskerV1.3_beta-LPC....thought this is the last release?
If the reset command is sometimes failing you could try increasing the wait time allowed:
i = 1000000; -> i = 10000000; to see whether it is a timing issue or not.
If it still sometimes fails it is probably some communication unreliability rather that the wait limit being critical.
I increased the wait time, but it still sometimes failed. So it is not a problem with the wait limit. Any idea about that?
Thanks
Martin
EDIT:
I downloaded the ServicePack 3 and I see my version is not the newest one. Sorry for that. Thought all the time my version is the newest one. My fault. So i gonna test it with the new files.
EDIT 2:
ok, it works. And the chekcing works now to. Of course it does, now it is expecting the right value.
But the problem with the reset command in
while (fnReadMII(DP83848_BASIC_CONTROL_REGISTER) & PHY_SOFTWARE_RESET) {// wait until reset completed
if (--i == 0) { // quit if no response
return;
}
}
is still there.
EDIT 3:
The problem only occurs while debug sessions or after a board reset (with the reset button). When I unlink the power supply and connect to the board, ist starts without any problems. Every time. But this other users in this forum topic reported too.
Regards
Martin
-
Hi All
I would like to thank Fabrizio for some feedback that he sent me concerning his experience with the Olimex LPC2378-STK and the PHY addressing.
First of all he explained to me the way that he ensures that the PHY is always detected:
In extern void fnConfigEthernet(ETHTABLE *pars)
#ifdef OLIMEX_LPC2378_STK // MICREL PHY KSZ8721
fnInit_KS8721PHYADDRESS();
#endif
//_______________________________________________________________________
// See Micrel PHY KS8721 Users Manual on "Strapping Option"
// KS8721 Internal Pull-Up/Down can be overridden from attached Hardware.
//_______________________________________________________________________
void fnInit_KS8721PHYADDRESS(void)
{
unsigned long ulPhyIdentifier;
unsigned long PhyAddr;
for(PhyAddr=1; PhyAddr < 32; PhyAddr++)
{
ulPHY_ADDR = PhyAddr << 8;
ulPhyIdentifier = fnReadMII(DP83848_PHY_IDENTIFIER_1);
ulPhyIdentifier <<= 16;
ulPhyIdentifier |= fnReadMII(DP83848_PHY_IDENTIFIER_2);
if ((ulPhyIdentifier & PHY_MASK) == PHY_IDENTIFIER)
return;
}
}
where
static unsigned long ulPHY_ADDR = PHY_ADDRESS_;
This variable is used in the PHY communication routines rather than a fixed address value.
He identified that the value found was not always constant but changed between 0x01, 0x09 and 0x19
This is due to the fact the LPC23XX ports have weak pull ups coming out of reset and the PHY has also internal weak pull ups/downs. The exact value is therefore not reliable since it floats around 1.5V.
The recommendation therefore (when hardware can be modified or can still be defined) is to use external pull ups / downs of around 4k7...10k to ensure the state out of reset and the address that the PHY actually assumes.
In the Atmel project the same effect is known and solved by commanding a subsequent reset of the PHY during configuration and actively driving the state temporarily: see http://www.utasker.com/forum/index.php?topic=161.0
Since the reset of the PHY is connected to the reset in line of the LPC23xx on the Olimex board this is not possible in this case. By controlling the PHY reset line from a port would allow this to be achieved though...possibly also via the RSTOUT...?
Regards
Mark
-
Hi Martin
Are you sure that the IP settings in the demo match your network?
It is often helpful to do the same test using the simulator since this will allow you to verify this without having hardware involved which can sometimes have a difficulty causing the real problem.
It is to be noted that there are quite often some problems with particular cards and there are some workarounds that have been devised. For example see the following (toward the end of the thread there is something which can be tried - but it does involve rebuilding the project)
http://www.utasker.com/forum/index.php?topic=170.0
Regards
Mark