µTasker Forum
µTasker Forum => NXPTM LPC2XXX and LPC17XX => Topic started by: hasiptuna on April 27, 2009, 10:15:14 AM
-
Hello All,
I use LPC2388 and KSZ8721 ethernet with Olimex schematic. 100Mbit mode is working fine. But 10 Mbit mode is not working. I use uip 1.0. Missing the last two or three-pack is coming.
Thank you for your interest
-
Hi
If you are using uIP you may find support at http://www.sics.se/~adam/uip/index.php/Main_Page
Regards
Mark
-
Hello Mark,
I know that site.But This problem is not from software. MAC or KSZ8721 ,It has a problem one of them. If the software is problematic, 100Mbit Full Duplex mode is not working fine. Does it work with 10MBit mode at Olimex kit?
Regards
-
Hi
You could always try this mailing list, http://www.sics.se/~adam/uip/index.php/Mailing_list
The uTasker TCPIP stack is NOT UIP it is much more powerful, Also remember UIP is free where as uTasker requires a license to be purchased.
Are you asking if uTasker works on the Olimex board at 10M?
Regards
Martin
-
I am so sorry.I didnt know. is Utasker work 10 Mbit at Olimex?
Dribble Nibble status bit is set at 10Mbit mode.Is it problem?
Regards
-
Hi
I haven't heard of problems with 10M on the Olimex board.
As comparison, there is a binary which runs om this board here: http://www.utasker.com/SW_Demos.html
The LAN setting can be set to 10M (rather than auto-neg) to see whether it performs correctly. (Guide here: http://www.utasker.com/docs/LPC23XX/uTaskerV1.3_LPC23XX.PDF)
Note also that, if you are using a 100M hub (probably very rare however nowadays), 10M setting would not be able to work.
Regards
Mark
-
Hello All,
I found problem.Problem is at Olimex kit schematic. 22 number pin of KS8721 is wrong connection. This pin is E_CRS.This pin have to connect 9 number of KS8721.
Thank you Mark for your interest.
-
Hi
On my Olimex LPC-2378-STK board pin 22 has been broken off the KSZ8721. I wondered why that was so...
But I don't see any connection to pin 9.
In case of any difficulties this may be an important tip.
Regards
Mark
-
Hi Mark,
I wondered if you have few minutes to check if theses 2 pins are not connected together on your Olimex board. On mine, there is a small wire below the chip that I found out when I soldered the chip out. I don't understand why we need to connect these 2 pins together, the datasheet provides no explanation.
Many thanks in advance,
David
-
Hi David
Unfortunately I am on the road for another weeks and didn't pack in the Olimex board (I just have my IAR one).
I am surprised that the Olimex diagram doesn't seem to correspond (http://www.olimex.com/dev/images/LPC2378-STK-sch.gif). This still shows the connection to pin 22.
I wonder whether the trick was to connect pads 22 and 9 underneath the chip and remove pin 22?
Can anyone else with the board take a very close look at the pin/pad to see whether there is a secret wire underneath there? No idea why though...
David, I wonder whether asking Olimex might result in an explanation?
Regards
Mark
-
Hi David
I have (finally) checked my board using a magnifying glass but can't see any extra wires connected.
This is not 100% because I did it without removing the device, but I looked hard and really didn't get the impression that there was something additionally soldered under the chip.
Regards
Mark
-
Hi Mark,
I've seen your message in the Sparkfun forum today, thank you very much your help !
Yes, I saw nothing as well on my board until I decided to remove the part. The best way would be to check with a simple multimeter (when I removed the part, I didn't know where to search). I've received no reply from Olimex unfortunately. I contacted a Micrel FAE (here in France) last week, I'll transmit the schematics. He told me that this part (KS8721) is very mature and he should send me some designs quickly.
I'll ket you know about this strange issue,
Thanks again for your help.
Best Regards
David
-
Hi David
I have measured the resistance between the pad 22 and the pin 9. It is indeed 0 Ohms!
This suggests that there is also a connection underneath the chip on my board as well.
Regards
Mark
-
Hi Mark !
Ah ah, it is interesting ! This means the board and the schematics are differents. I've some problems to receive packets correctly on my design (new PCB) which is based on the schematics (LPC2378-STK). The Micrel PHY is a KSZ8721BL set up in RMII mode as well. To get some boards working, I have to connect a strap between pin 9 & 22. If I remove it, I reveive no packet at all. However, some boards doesn't work even if I connect these pins together : an error from the status descriptors for each packet received (bad length or alignement error or CRC error). When I read the buffer, I have 12/13 first-bytes of a packet correctly (example for an ARP packet : 6 bytes broadcast (0xFF) followed by 6 bytes of my source MAC address (my computer) and then... dummy bytes...). No problem to send packets though, checked with ethereal.
I received an email from Micrel yesterday :
We think the problem may be due to the strap between pins 9 & 22.
For RMII mode (see datasheet) the E_CRS signal (on customer schematic)
should connect to pin 9 RXDV/CRSDV and not pin 22 CRS. This needs to be
corrected as we believe this is the cause of the receive errors
(misalignment).
We suspect in the modification that you strapped pin 9 and pin 22
together but also cut pin 22. Pins 9 & 22 are both outputs so you do not
want them connected together (you may be lucky in RMII but certainly we
would not advise connecting the two pins).
Well OK, but it doesn't work... why ? The schematics provided by Micrel attached to the email are all designed for MII (pin 22 and pin 9 are used separetly), not RMII...
To conclude : there is something wrong either in the datasheet or with this chip in RMII mode, or with my PCB design... no reply from Olimex too... I made a small test code to check EMAC. Does someone write another one for LPC2388/78 + Micrel PHY ?
Thanks again Mark,
Best Degards,
David
-
Hello !
Ok, I finally found something : I forced the pins TXD2, TXD3 and TXEN to the ground, put 2 pull-down 1K resistors (pin 11 = RX_ER and pin 9 = E_CRSDV) and disconnected pins 22 = E_CRS and pin 9 = E_CRSDV, leaving pin 22 floating. I also use a GPIO pin from the LPC to make a hard-reset (pin 48 = PHY_RST). In LPC side, I setup EMAC pins in the PINSEL register first and then apply a hard reset. I think the pull-down resistors helps to setup the straping options properly, I don't know...
Finally, my boards seems to work with these modifications :P
However, I've no explanation about the Olimex modifications... Mark, did you have any issue in Half duplex mode with your Olimex board ? The misalignement can be explained by this.
Thanks again !
Best Regards,
David
-
Hi David
I don't remember any issues with ETHERNET on the Olimex board.
The only difference that I generally see between MII and RMII is the fact that it is necessary to set the EMAC to the correct speed (10M or 100M) after auto-negotiation (otherwise the PHY and EMAC may be set to different speeds and nothing works). This is sorted out by handling the PHY interrupt on auto-negotiation state change and using the speed read from the PHY to adjust the EMAC speed setting.
On all boards with MII this has never been necessary; even if there is no interrupt line the EMAC and PHY stay in sync at the appropriate speed. I suppose the additional lines (somehow) allow the information to be passed between the two and they sort this out themselves.
Regards
Mark
-
I don't remember any issues with ETHERNET on the Olimex board.
Would you like to have one? I have it for you.
Trying to bring UDP up on raw LPC2378STK (using Windows + IAR + Jlink) I've found that program crashes as soon as EMAC power is switched on. Immediately after power on bit is set to "1" the debugger fails to show MAC registers content and Jlink driver hangs.
However uIP web server sample project worked fine (I can ping 192.168.0.100 and can see web page in a browser) and my first guess was that it was a problem of my code. However when I tried to step through this sample I've found the same problem exactly. The only difference is that when non-stop running the sample it "works", and my program does not.
What else.
This is my second Olimex LPC2378STK. On the first one I learned that problem exists, but ignored it since there was no clear signs about where it is (random rare hangs) and it did not stop the job. Well ..., did not until the LPC2378 controller died. I had nothing to do better than to replace the chip. After then the board worked for maybe a month, then died again and I purchased the second one.
Now I have one LPC2378STK dead and a second one half-live, but with clearly defined problem.
I'll try to study the case. But if somebody here could comment this or will take time to reproduce the problem...
-
Sorry for this follow-up but I'm really upset. Please help. :'(
Situation (listed above, but more precise):
Hardware: LPC2378STK(USB powered) + J-Link + IAR.
Firmware: Any. (In particular, say uip_webserver or LCD_demo)
After "Project Download and Debug" (Run to main, Hardware reset NXP/LPC) I
* in the debugger window view Ethernet MAC registers - all OK
* in the debugger "Control block regs" window set PCONP.PCENET=1 manually (switch power On)
* go back to the Ethernet MAC registers registers: spoiled contents (many dashes etc.)
All this I do/see without program start.
Any ideas what could it be? Where to look?
---
What I did:
0) Read LPC2378 datasheet, UM, errata, forums (continue to) .. didn't help yet.
1) if I run uip_webserver it seems to work OK , but if I set a breakpoint there where PCONP.PCENET is set to "1", I see the same problem. IAR reset (program restart) doesn't help (J-link fail to halt ARM core, etc). Debugger restart helps. Hardware reset button helps too.
2) I measured JTAG signals and LPC2378 power. All seem OK: signals within 3.3v limits, 3v3 and 1v8 power OK and stable.
3) measured 5v board supply current: 250mA, increases to 255mA if I switch EMAC power (make PCENET=1). Not too bad.
4) added 2uF cercap to 1.8V core supply. Nothing changed.
5) wrote this message... HTH
thanks.
-
Hi
The first suggestions that I have that you could look at to be sure:
- 1) Make sure that the watchdog is disabled when debugging. This may be a general debug problem an not just an Ethernet problem (see http://www.utasker.com/docs/LPC23XX/uTaskerV1.4_LPC2XXX.PDF - page 19).
- 2) Are you checking the revision of the chip when configuring Ethernet?
if (EMAC_MODULE_ID == OLD_MAC_MODULE_ID) { // if original silicon the RMII mode must be set with ETH_TX:CLK
PINSEL2 |= (PINSEL2_P1_6_ENET_TX_CLK | PINSEL2_P1_0_ENET_TXD0 | PINSEL2_P1_1_ENET_TXD0 | PINSEL2_P1_4_ENET_TX_EN | PINSEL2_P1_8_ENET_CRS | PINSEL2_P1_9_ENET_RXD0 | PINSEL2_P1_10_ENET_RXD1 | PINSEL2_P1_14_ENET_RX_ER | PINSEL2_P1_15_ENET_REF_CLK);
}
else { // if newer silicon it may NOT be set
PINSEL2 &= ~(PINSEL2_P1_6_ENET_TX_CLK); // ensure disabled
PINSEL2 |= (PINSEL2_P1_0_ENET_TXD0 | PINSEL2_P1_1_ENET_TXD0 | PINSEL2_P1_4_ENET_TX_EN | PINSEL2_P1_8_ENET_CRS | PINSEL2_P1_9_ENET_RXD0 | PINSEL2_P1_10_ENET_RXD1 | PINSEL2_P1_14_ENET_RX_ER | PINSEL2_P1_15_ENET_REF_CLK);
}
3) Have you tried putting your break point a few lines after you power up the Ethernet controller? Sometimes debuggers do have difficulties in certain code and running through it and stopping afterward may help. Eg. often it is not possible to step through PLL configurations.
4) The LPC23XX doesn't actually power down peripherals by default and so, if no other code is powering the EMAC down, there shouldn't be any need to power it up. On the other hand it shouldn't harm either - but maybe you could remove any powering down (presumably somewhere in the start-up code).
5) Have you tried the uTasker project code? This is supported here in detail but not other TCP/IP stacks.
Regards
Mark
-
Hi Mark. Great comments. Thanks. (I'll study them carefully a bit later one-by one)
Now I have something to add (on what I did):
1) I replaced LPC2387 on my first Olimex board. This helped! It is working now.
Before it there was 3.3v Power supply shorted: ~2A current drawn. Reset button did not help.
Thus I (hope I) proved that LPC2387 on LPC2387-STK can be killed programmatically.
(This is a second LPC2387 chip replacement on this board and now I'm absolutely sure there was no other reason for chip to die other than long non-stop run. This is a last replacement too because the board is poor quality and will not withstand any more solderings)
2) I did what I asked to do: set a break at MAC power On instruction, did single step + view EMAC registers.
I have had the same error: registers' contents spoiled, debugger hangs, Reset helps!
The difference is that if I break few instructions after MAC power On, I can view regs and debug my code.
Thus I have 2 Olimex LPC2387-STK boards working, having the same problem, but this problem is fatal for EMAC debug on one board only.
3a) (routine job) Added 5Ohm ballast resistors to 3v3 IO power and cut off any 5V signals from the chip (I've found them 5) - in the hope to prevent chip from damage.
3b) (routine job) ordered LPC-P2378 board in the hope there will be no (or less) such a problems I had (have) with LPC2378-STK.
-
- 2) Are you checking the revision of the chip when configuring Ethernet?
if (EMAC_MODULE_ID == OLD_MAC_MODULE_ID) ...
Yes I do.
(actually, this has nothing common with my problem since Power has to be On first, any configuration afterwards)
3) Have you tried putting your break point a few lines after you power up the Ethernet controller?
Yes. And this really helps with my LPC2378-STK board #1 (re-animated one).
On the second board I can set breakpoint, can step down the code, but cannot view EMAC registers.
As soon as I select IAR EMAC registers window Segger J-link debugger hangs (falls into infinite register reading loop). Debugger restart terminates this loop ... sometimes, but not always.
-
4) The LPC23XX doesn't actually power down peripherals by default and so, if no other code is powering the EMAC down, there shouldn't be any need to power it up.
Nope, I humbly believe this is not true for EMAC.
Yes, most periferals come powered up after hard Reset, but EMAC power PCENET bit of the PCONP is "0" and power is off. Powerdown bit of the POWERDOWN EMAC register... Well, I'm not sure, probably is "0" too ("powered up"), I set it to "0" anyway, but this is of no problem.
5) Have you tried the uTasker project code? This is supported here in detail but not other TCP/IP stacks.
Not yet.
Submitted an application for the code.
(Actually I see the problem independent of the project: I upload any project, then turn EMAC power on manually, then open the EMAC registers page ... Voila: hang.)
Thanks.
-
- 1) Make sure that the watchdog is disabled when debugging. This may be a general debug problem an not just an Ethernet problem (see http://www.utasker.com/docs/LPC23XX/uTaskerV1.4_LPC2XXX.PDF - page 19).
Good paper.
I do not use LPC2378 watchdog.
What I did:
- uploaded my project to the LPC2378 (did not start it)
- turned EMAC power On manually
- opened Watchdog registers view debugger window
- made few steps forward - all ok. (I see WDMOD = 0 : not using watchdog)
- set break and run -- success.
- opened EMAC registers view window -- hang!
:(
-
Hi Sergei
You are right that the EMAC is not one of the peripherals that is powered up out of reset.
The reset state of the PCONP register is
PCONP = (PCTIM0 | PCTIM1 | PCUART0 | PCUART1 | PCPWM0 | PCPWM1 | PCI2C0 | PCSPI | PCRTC | PCSSP1 | PCEMC | PCI2C1 | PCSSP0 | PCI2C2);
Therefore you do need to actively power it up.
Regards
Mark
-
Hi Mark,
board (I just have my IAR one).
If you happen to play with your LPC2378+IAR could you please look at EMAC registers for me?
Just:
1) upload any project (do not run)
2) set PCONP.PCENET=1 manually
3) look at EMAC registers (open debugger window)
4) report result here.
I need to know if I'm unique having single problem on 2 boards..
Thanks in advance,
Sergei.
-
Hi Sergei
Although it probably doesn't help much, I can confirm some differences in behavior between the Keil MCB2300 and Olimex LPC-2378-STK when using IAR (4.2 - this is quite an old version and doesn't 'know' the LPC23XX) and J-Link.
1). Generally I can't connect the debugger to the Olimex board without first switching the processor to boot mode. Then it works but I need to modify the register 0xe01fc040 manually to get it back to FLASH mode. I can't display the MAC registers since my IAR version doesn't know the peripherals involved but I can display the registers in memory at 0xffe00000. When the power is removed from the EMAC all addresses in this range display 0x00000000. When enabled only 8 long words are displayed (although there are more in the EMAC block) and the rest are displayed as non-accessible/non-existing. The code can however read and write these addresses. Although all works correctly when the board runs normally the code gets stuck trying to initialise the PHY - it waits for the PHY to become ready but this doesn't happen correctly. I don't know why though.
2). On the MCB2300 I don't have the same connection difficulties but I still need to manipulate the MEMMAP register. It seems as though the debugger switches it to 2. Strange but I have often used this technique so don't really think about it much.
In this case the same register display occurs. I can only see the 8 first long words in the EMAC block, but the code does work normally even when started with the debugger.
3). I repeated with CrossWorks 2.0 (still using J-Link) and this could display the EMAC registers normally and also it could see them normally in a memory window. It also showed the module to read all 0x00000000 when not powered but didn't display anything as non-accessible when not.
Although this may not help much nor explain your difficulties it does suggest a difference between the behavior on the two boards with IAR (at least with an older version). If the register view is causing a hang try also to view the registers directly in memory, since this may help.
Regards
Mark
-
Mark, thanks. This helps.
Recently I ordered few more Olimex boards (This time them two are LPC-P2378).
Will continue to investigate the case whenever time permit to.
In the end I brought Ethernet/UDP up and have a lot to do with it leaving any hardware issues in the background.
(but I will. :-)
-
I'm not sure whether the following has any bearing on what you are investigating, but regarding the Micrel 8721, I've seen that there is a problem with 10MBit when using RMII. If data for transmission is being transferred to the PHY via the RMII interface at just the same time as the first ethernet traffic is arriving at the receive port then the internal FIFO pointers that shuffle the RMII (2-bit wide) data back into MII (4-bit wide) can get corrupted. The upshot is that sometimes the transmitted data on the wire is "out" by two bits. The easiest way to observe this is the 2-bit shorter preamble, but keen observers will see their data followed by two spurious bits on the end of their message on the wire.
Depending on what PHY you then link to determines whether you are even aware of the problem or not. Coupling to another Micrel PHY, or indeed just looping back masks the problem. A short preamble should not be an issue, but an incomplete byte may be. Some PHYs will simply allow each complete byte received to be forwarded, and aren't bothered that two extra bits are sent at the end of the message, while others will detect this and produce an unexpected extra byte on the received message which will then cause each and every message to be discarded downstream.
Once the fault mode has been entered, the PHY FIFOs need to be reset. The best way to avoid the problem is to not send any data on the RMII for transmission until some data has already been received,since it is the start of data RX that triggers a FIFO reset, as best I can recall.
Regards