RM46 HDK and LwIP failing to transmit or receive

on the HDK the phy should default to MII mode and the lwip example should match.

there is a DIP switch on the HDK which has an ethernet ON switch on it, you need to have this in the ON position in order to connect the MCU to the PHY

You say "on the HDK the phy should default to MII mode and the lwip example should match", but this is not actually true. Looking at the TI documentation at "processors.wiki.ti.com/.../HALCoGen_Ethernet_Driver_and_lwIP_Integration_Demonstration" you find this little note:
"The RM46xx project enables RMII by default, which works for the RM46 controlCARDs. If you're using an RM46 HDK, however,
you will need to change this setting to MII(in the PINMUX tab), and then rebuild the project."

Of course, knowing this, I made the appropriate change, but it still is not working. And of course, as I originally said, I have set the switch S2 to enable ethernet, so that is not the issue either.

I am hoping to find some other ideas on what I might look at, or what others might have had to do to get the demo code to work on the HDK.

John,

You're right about the note. I didnt' realize that. It's odd because I remember having to make major changes to test the RM46 CNCD which I thought included MII->RMII swap.

You could actually with a little effort switch the HDK phy to RMII mode. You need to change a strap resistor (populate an unpopulated pullup resistor R193 on the Phy RX_DV pin) and you need to change the oscillator Y3 to 50MHz or remove Y3 and source 50MHz from the micro.

Or you can try an RM48 example on the RM46 assuming the RM48 example is setup for MII.
Normally the RM46 can run RM48 code as-is. There's a minor difference in USB but I'm not aware of any affecting ethernet.

I guess the issue isn't that I could make changes to the board, but that the demo code is supposed to "just work", and it doesn't. I am trying to use this demo application to see if I can use ethernet on this part on the eventual boards that my company intends to build, and if I can't make the canned, stable and released demos from TI work, on the standard, released and supported demo board, what confidence can I have in some board my company is going to make? I am left to suggest to them that this processor is just not ready to be used.

So, again, I am looking for some idea on why the default, released demo code would not "just work" on the delivered HDK board, and what I can do to try and get it to work. Seems like a pretty simple problem.

John,

So I understand the statement - and we've got a problem in that we have too many variants of kit types: USB sticks, LaunchPads, Control Cards, HDKs, for this family. That makes it difficult to have canned demos supporting every permutation of board & kit just ready to download and run.

It looks like according to the HalCoGen lwIP demo website that this is the 'kit' for RM46 where the canned demo would run: www.ti.com/.../tmdxrm46cncd
Not the HDK unfortunately. Although it could be made to run on the HDK with minimal effort... it's just that this isn't a task for someone starting from 'zero' as you are (assuming you'd be ramping on the parts as well as HalCoGen and other tools all at the same time you'd be trying to make the RMII to MII swap and as a whole all those together are a big task..)

But, the lwIP demo is just a demo of an open source TCP/IP stack. It's far from ready for you to just integrate into a product. There are various critiques on this forum where people have pointed out limitations. I would suggest investigating this carefully as well... it's probably a more important concern [unless you are already an lwIP guru...] than whether the canned demo works on your kit.

Unless you're prepared to support the stack yourself (with the lwIP community help perhaps) then I'd suggest looking at commercial offerings such as:

www.hcc-embedded.com/.../tcpip-v4v6-dual
www.micrium.com/.../
www.smxrtos.com/.../ek_armr.htm

Ok now these demos are all generally listed as RM48 but RM46 is a subset of RM48 and most times the RM46 can run an RM48 binary without any changes. The exceptions would be a minor change is needed in clock config. if you are using USB, and of course the RM48 has more memory so if the demo uses > 1.25MBytes or Flash or > 192K of SRAM it may not 'fit' on an RM46. But I think these demos probably will fit on an RM46...

I can tell you I just went through an exercise of running some test code on an RM48L952PGE, RM46L852PGE, and RM44L920PGE which are three different pieces of silicon in the hercules family - and they all ran the same binary compiled for the RM46 without issue. This was just some test code but it did run an RTOS, communicated over serial, and exercised all the N2HET, ADC, MibSPI, and CAN pins on the part. Point is they were designed to be basically drop-ins for each other so with a couple exceptions if there's a demo for an RM48 it's worth trying on RM46 as it probably will just work...

I've got the E2E forum next week so I can try to make some time to give you a binary for an RM46 HDK if all else fails ... guessing it may be a slower week with the holiday.
But please do consider the question of lwIP v.s. commercial if your concerns are around support. We are able to support the MCU here - but I would not say we are capable of really supporting lwIP in any depth other than debugging the demo. So even if we get you up on the demo - as soon as you want to add a different protocol you'll be relying on community or self support (with lwIP).

-Anthony

I get it - I know all about the problems of multiple kits, unsupported software from somewhere else, etc. I have used LwIP before with other processors, so I am not new to what it can and can not do. For my initial needs, if I could get a packet in and out, that is enough - I don't have need for high speed or high throughput at this point, and I already have the code for LwIP for the other protocols I need (a little telnet, a little UDP).

I don't get to pick my processors. I get what the hardware guys give me. In this case, they gave me the RM46 HDK board to start with, which at $200 was not a bad price (if it works). The only part number I can find on the box is "TMDXRM46HDK". Came with a cool little flashlight :)

Also, I realize there are other choices for lots of things (I may eventually need more RTOS to do what I am trying, and so we probably will buy something then) but at the moment, all I really need to do ping a packet in and out, and I can then use this to bring up some test code.

Using the debugger, I can actually stop it at hdkif_transmit() and look at the packet going out, and I can stop in hdkif_tx_inthandler() and see that the board thinks it sent something, but as far as I can tell, nothing is going out. I am looking for ideas on what I can look at - is it a speed thing (10/100/1000)? Is it a polarity thing? Is it related to being in little endian mode (this one is suspicious, because the default code allows for a static IP, but if enabled, spits the address it is using out reversed in the display, as 44.2.168.192 instead of 192.168.2.44 as expected). I am not a hardware guy, so hooking up scopes and looking at pins is not in my bag of tricks, but I can do any kind of debugging that works from the JTAG debugger.

Or is it something in the HalCoGen that is screwing it up, when I regenerate because of the change from RMII to MII, because of version differences? I have looked at the file differences between the original code and the new code after running HalCoGen, and the changes are many, but often cosmetic (uint16_t instead of uint16, for example), so deciding if something is actually different is tricky. So, I ran HalCoGen on the original project, unchanged, and saved it all, and then again on a copy, where I changed the RMII to MII, and looked for differences, and found far fewer, but they all seemed normal for the change. Nothing jumps out at me.

If it helps, I can include, upload or whatever the outputs or any files, for your own comparisons. I will be working next week on this, so with a little luck maybe we can find the issue and move on. Thanks for listening to me, anyway.

Hi John,

Thanks for using our device!  Just trying to make sure you're expectations for our (lack of) ability to support lwIP much are set right ;)

So I tried the RM48 example on my RM46 HDK without any mods and it worked fine.

What I did:

 - install fresh halcogen / lwip demo lwIP_Demo_v03

 - import into clean workspace the project 'Build-RM48'

 - rebuild, download to board..  (changed emulator to XDS100v2 in CCXML file because I used the onboard USB)

 - checked the xds100v2 UART connection as on COM13.   Opened Putty to COM13 9600 N81

 - ran the code after programming

  - forgot the Switch for ETHERNET_ON so I flipped it, and pressed the warm reset button while the board was running in CCS.

 

Then on my browser:

Ok so I'm sure this isn't satisfactory as you will want to get to the point where you have a HalCoGen project specifically for the RM46 instead of the RM48..

But since it does work as-is please try it - that way we can make sure there isn't any issue on your local network between the PC and the board ... [because it looked like you'd already gotten pretty 'far' along..]

Best Regards

-Anthony

I love it when I can't get something to work that should, and everyone else has no problems! It means it is my fault somewhere and I have a prayer of fixing it!

The most notable thing is that I did "almost" the same thing, except I picked the RM46x folder instead of the RM48x folder, because I guess I thought I had a RM46L852 on this board, so naturally I used the one that had the same numbers.

However, I am nothing if not flexible. So, I will start over again, with a new run, a fresh install, and try the RM48x branch, and see what it does.

For the record, the code appears to be running just fine, but I am getting no packets in or out. Makes me think some setup has picked the wrong interface or something. I guess that is why I am grateful to have someone with the same board setup running this too, so I can believe it is my configuration that is bad, and not some great global conspiracy to drive me crazy.

I have a whole bunch of meetings on this board and project coming up, so it might take me until later this afternoon to try it, but I will send another email out as soon as I know something. Thanks for the help - if nothing else, this kind of help is what will keep me advocating for this part, even when I am having trouble.

Hi John,

Ok keep me posted.

BTW how are you monitoring the 'no packets out' .. are you looking w. Wireshark or are you just not seeing some specific interrupt or callback as expected?

sure - wireshark on my windows PC, tcpdump on my Linux system. Of course, there are always issues with things like switches, so I also have a peer to peer adapter to clip onto the ethernet wires to connect directly to the other machines, but I get the same results with and without the adapter, with and without the switch. Nobody seems to be seeing any packets. But the TX interrupt gets called, so the chip thinks something is happening.

Anyway, I will get back to you later today when I have a chance to run this thing again.

ok, this works! But I can't determine why.

I took the zip file and copied it into a folder, renamed it, then got it to build (had to fix an include path because of the renamed folder), and it ran and worked. But I can't find anything in the HALCoGen files to explain why this works and mine doesn't.

I will reinstall (again) from the original zip file downloaded from the net, follow the directions in the PDF to set it up for MII instead of RMII, and then compare the results to the working one I have from you. Perhaps then I will have some clue as to what needed to be set to get it to work, and that will help me when I go to target the new board that the hardware folks are going to be producing.

Hi John,

Super!

We could also do a 'DIFF' on the DIL files (yours and mine) and we'll probably find the difference quickly if it's something in HalCoGen.

Oh, diff is my friend.

At this point, I have to say that the build is "fragile". I have a build that works, and one that doesn't, but there are NO source code differences. Kind of weird.

I am looking for other differences, but so far nothing jumps out at me. I noticed in the properties that the file I got from you is specifying compiler 5.0.4, which I don't have, so it is using 15.12.1.LTS, which I have selected in the other image. Other than that, I can't find anything. Any yet, the one I build from your files works, and the one I build from mine does not.

I will keep looking tomorrow, starting again from scratch so I can see where the differences come in.

Yes the build is extremely fragile; which itself may be an understatement.
There are many individual files and folders that need to be clicked on in the project explorer and
selected for 'exclude from build' .. I think there are some duplicates of the same file and possibly including
the wrong one could be a recipe for a problem that wouldn't show up w. a DIFF.

Well, there are 3 files, .ccsproject, .cproject, and .project which I imagine purport to control what the project contains. I have looked at these, and ccsproject has no differences (a drive letter change is all), project has no real changes (again, a drive letter change is all), and while cproject has a number of differences, they all appear to be compiler related, where you are using TMS470_5.0, and I am using TMS470_15.12 (really, 5.0.4 vs 15.12.1.LTS), but of course, since I don't HAVE 5.0.4, the build system swaps in 15.12.1.LTS anyway, so in reality, the 2 builds ARE using the same compiler!

There also is a makefile, at the top level of the Debug folder, but the only significant different there is that in the non-working side, a stack and heap size are referenced in the compiler options line (both set to 0x800). The order of some of the other options is slightly different, but otherwise the are all present, except for these 2. Is that significant? I tried turning it off, but there was no change in the working status - still no packets.

I kept looking, checking the properties tab on the project and such, and I eventually discovered a reference to "ORIGINAL_PARENT_LOC" for some include files, pointing back to the original LwIP directory. I updated these (not an easy thing it turns out) to be sure that all include files were coming from the sub-directories of the current project, did a clean build, and voila! It works.

Fragile. That is all I can say. Finding some of these dependencies is not easy, and changing them is not straight-forward. I guess that is a function of Eclipse.

One last thing - the original code has a commented out section that says

    /* Uncomment the following if you'd like to assign a static IP address. Change address as required, and uncomment the previous statement. */
    /*
    uint8 ip_addr[4] = { 192, 168, 2, 44 };
    uint8 netmask[4] = { 255, 255, 255, 0 };
    uint8 gateway[4] = { 192, 168, 2, 254 };

but if I simply replace the 192.168 address with a real address, it comes out backwards. I suspect there needs to be a htonl() call before passing these values to lwIPInit(). Might be something to consider putting in a note in the code, or on the web page.

Good feedback John, I'll log this.

Did you see this thread: e2e.ti.com/.../509588
from Szilard Lovas .. if you are interested in lwIP on this platform it might be good to connect with him.

Very interesting John,

I've been chasing identical symptoms with both the 2.0 and 3.0 versions of the LwIP demo code, but on a TMS570LS12. I also get a single Tx interrupt, and no Rx interrupts. Poking around project properties, I don't see any reference to "ORIGINAL_PARENT_LOC"...what I have is:

If  you don't mind, could you elaborate a bit on where you found the"ORIGINAL_PARENT_LOC" and what you did to fix them?

Thanks,

Chuck 

Chuck,

You might have a look here: processors.wiki.ti.com/.../Projects_and_Build_Handbook_for_CCS

Since lwip installs in by default in some folder c:\ti\hercules\... but that's not usually the CCS workspace folder, you would normally import the projects from the lwIP installation into your workspace. When you do this I think the default is not to make a copy of all the sources but to point back to them and these variables or linked resources get set during import for that purpose. WIki explains better.

The normal names are PARENT_LOC and ORIGINAL_PROJECT_ROOT, it may just be that John got them mixed up a bit in his post.

I have written an article here on e2e a while ago on that example v3, and all the steps required to port it to another member of the Hercules family. It includes all HALCoGen and CCS steps (with the necessary build excludes), also MII switch and interrupt settings.

This is for the TMS570LC43 / RM57, but although PINMUX positions may be different, and clock settings will need a check, all config steps should be included.