BeagleBone enetEcho from StarterWare

Hi Basu,

It seems an abort is generated. Could you please tell me if the code hangs before getting the IP address or after getting the IP address ?

Regards,

Sujith

Hello Sujith,

It hangs up before getting the IP address. 

Best Regards,

Basu 

Hello,

I have the same problem. Is there already a solution.

I guess the problem is connected with the system interrupts.

Best  Regards,

Sebastian

Hi Basu/Sebastian,

 We are not observing the problem here.

Could you please tell me which release version of StarterWare you are using ?

Is the message "Acuiring IP address.."  is getting displayed on UART console?

Also, is UART echo application and enet_lwip application for BeagleBone is working for you ?

As I understand from the explanation, it seems to be an abort, but since we are not facing the problem here, could you please provide more details about the test procedure, or send a snapshot of ARM core register dump when the code hangs?

Regards,

Sujith.

Hello Sujith,

I am using version 02.00.00.05.

The uart echo example is working fine.

But there is the same problem when I try to run Enet Lwip example.

 "Acuiring IP address.."  is displayed on my UART console. If I use a static IP-Adress it will also display "EVM IP Address Assigned:" and the right adress.

But when I restart the program after an abort, the program only runs to the function IntMasterIRQEnable();.

If I don't enable the system interrupts(IntSystemEnable(SYS_INT_3PGSWTXINT0);IntSystemEnable(SYS_INT_3PGSWRXINT0);) the example runs without an abort.

Is there anything I have to take care of if I want to use it in a network?

Best Regards,

Sebastian

Hello,

I was able to solve it by making a SD card using TI utility and an app for beaglebone. It seems to work fine now. May be something in Angstrom card that I was using was blocking it?

But... when I try to tun the host app and communicate with the beagle bone app (enetEcho and associated host app), I get unreliable response. Sometimes it behaves well and sometimes it comes tx/rx errors and sometimes it hangs up.

Best Regards,

Basu 

Hi guys,

I'm bumping that problem as well.

When loaded enet_lwip or enet_echo from starterware, the console shows 'acquiring DHCP address', but then nothing happens. I have noticed, that even when ethernet

cable is plugged into the socket, neither yellow nor green LED diode turns on. It almost look as if the ethernet PHY was not initialized at all...

---> to be noted: beagleboard revision A6

any hints kindly appreciated

.d.

UPDATE: sorry guys, the issue is _not_ resolved. It appeared as the primary problem was

missing DC supply. Well, once I made this 'somehow' running, it continued to run until I replugged

again the usb and dc supply. since then I only managed to make it running once.

So i've been digging a bit more and I've found, that while my application (original enet_lwip) does not work,

the U-boot (configured for network access) _ALWAYS_ works,

and even without DC supply.

This brings me a question, what is so different between configuration of the network interface in u-boot and enet_lwip...

as I said before, the A6 revision has to have 'something' to switch to different mode due to improperly installed resistors in mode selection.

might that be the cause?

any hints appreciated.

------------------------------------------------- NOT TRUE -------------------------------------------

PROBLEM RESOLVED - at least in my case:

DO YOU SUPPLY YOUR BEAGLEBONE ONLY THROUGH USB CABLE?

well, that seems to be the cause. It seems that either the USB is not able to deliver enough current, or - there is something happening during initialization of the ethernet PHY, which disconnects CPU for a short time from the power supply, and as a result, the ethernet PHY does not get initialised.

Take whatever +5V/1A+ power supply and stick it into your beaglebone. Then you can run the echo application, and your console will pop up:

to StarterWare Application...

StarterWare Ethernet Echo Application.

Acquiring IP Address for Port 1...

PHY found at address 0 for  Port 1 of Instance 0.
Performing Auto-Negotiation...
Auto-Negotiation Successful.
Transfer Mode : 10/100 Mbps Full Duplex.
PHY link verified for Port 1 of Instance 0.
DHCP Trial 1...

Port 1 IP Address Assigned: 10.0.0.48

Hi all,

I still don't know, where the problem is, but I think there is some progress:

I put various debug prints into the system, and I've found, that the PHY cannot work, because the software fails _before_ the initialization

of the PHY. From unknown reasons the system hangs in pbuf.c/pbuf_alloc() when called from cpswif.c/cpswif_rxbd_alloc. It is still not clear why

it hangs (makes exception?) but when I remove the initialization of the MMU (that's the very first line 'MMUConfigAndEnable' from enet_lwip.c or enet_echo.c),

the process of booting gets much further. It actually initializes the PHY and starts to ask for DHCP  - and then it hangs on another memory allocation.

I have no clue what's going on. But it seems either as improper initialization of the memory or stack. I still don't know what kind of memory the pbuf_alloc uses. If

this is the 64kiB OCMC memory, can that be, that this memory is not properly set-up?

any help kindly appreciated

btw that reminds me: I'm using higher version of CodeSourcery than it was originally compiled with. I'm using 4.5.2 wrt to 4.3.3 (i think this was the original link). If there are some changes this could be a problem as well.

Hi all,

i've been entering more into the issue and I have some promising news. Although still not resolved, this seems to have something in common with .bss static data setup, or compiler setup for static variables.

I have described the problem here:

http://stackoverflow.com/questions/15085119/why-arm-codesourcery-compiler-does-not-initialize-static-variable-in-data-segme

Dear all, 

after a detective work I have found what is wrong with those examples. It IS THE LINKER SCRIPT which improperly declares bss segments. Then the _bss_end finishes in the middle of the BSS segment and majority of statically declared variables due to that do not get initialised to zero by init.S script.

I had to change linker script to as I have shown here: http://stackoverflow.com/questions/15085119/why-arm-codesourcery-compiler-does-not-initialize-static-variable-in-data-segme

This MAKES THE APPLICATION CORRECTLY RUNNING and INITIALISING PHY. However I still do not get any DHCP anwer. Probably because LWIP uses as well non-zero initialised static variables (one can see that there are some in .data region) and they do not get initialised neither. So I'm going to follow this.

This issue however puts my doubts, whether Texas Instruments really tested the starterware in combination with codesourcery gcc. It does not seem so. Because this error (at least on beaglebone and using codesourcery with gcc 5.4.2) is immediately visible: neither of the longer examples (including demo) does work!

I'm going to investigate more on the DHCP and post news...

Just a new link as I have renamed this subject to be more precise about the source of the error:

http://stackoverflow.com/questions/15085119/why-ti-starterware-examples-do-not-clear-correctly-bss-segment-when-compiled-usi

In any case, it STILL does not work. Using the stuff above the application nicely runs, not hanging anywhere, but it does not want now to get DHCP address. And it seems it does not send anything at all through the enet PHY even if PHY is initialised correctly. The RX/TX irq works. DMA seems to be working as well, but nothing physically pops out of the chip.

It does not seem to be a problem of .data segment variables initialization as .data is part of compiled binary and hence the variables get automatically setup during copying the application to the DDR2 memory.

Hello Friends

I have started  with Starterware on CCSv5 and i am using  BeagleBone-AM3358 as target with on-board JTAG XDS100v2.

I am trying to test  GPIO on target and for that i found gpioLEDBlink.c  in beaglebone sub-directory of Starterware.

I succeeded with building gpioLEDBlink.c in CCSv5 after resolving few undefined-symbol build errors by adding gpio.c to my project but after loading my code on AM3358 when i am hitting resume the below error is appearing on cosole.

ti.sysbios.family.arm.exc.Exception: line 176: E_dataAbort: pc = 0x800043f4, lr = 0x80006de0.
xdc.runtime.Error.raise: terminating execution

And i am sure it is crossing the main function of the project.

and its failing at gpio.c.

Any information on this please share.

Thanks