SAM4E16E EK need ethernet-unplug-tolerant solution

Discussion around product based on ARM Cortex M4 core.
This forum will be discontinued soon.

Moderators: nferre, ncollot

scowell
Posts: 29
Joined: Fri Feb 13, 2015 11:00 pm

SAM4E16E EK need ethernet-unplug-tolerant solution

Wed Jan 04, 2017 2:33 am

I have a project based on LWIP RAW (no OS) and SAM4E16E-EK that I need to convert. I had done a hack to endlessly loop the code until the ethernet was plugged in (see my previous posts here) but now I don't want to block forever (need some main loop stuff to happen without ethernet plugging). Has anyone already done this before I re-invent the wheel? Is it normal to write MAC-PHY apps where the thing times out, fails, and doesn't try to re-init? Thanks for any help you can provide here. Project is THIRD PARTY LWIP RAW BASIC HTTP EXAMPLE for the EK.
blue_z
Location: USA
Posts: 1560
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAM4E16E EK need ethernet-unplug-tolerant solution

Wed Jan 04, 2017 3:16 am

It's not clear what you're trying to do; there's no link to your "previous posts".

The Ethernet MAC or PHY driver should be able to detect/report when the link's state changes to up or down. I haven't bothered to look at the Linux kernel to see how this is done.
But this is typically an event with limited significance.
Since the link is typically only between your host and a switch, there could still be no hosts out there to communicate with.

At the IP message level you have to use polling and/or listen for ARP broadcasts.

Regards
scowell
Posts: 29
Joined: Fri Feb 13, 2015 11:00 pm

Re: SAM4E16E EK need ethernet-unplug-tolerant solution

Wed Jan 04, 2017 8:04 pm

>>It's not clear what you're trying to do; there's no link to your "previous posts".

Here's a link to some of our previous interactions:

discussions/viewtopic.php/p,44832.html#p44832

Indeed... hard to find. Should be available at a click. Time for improvements... hopefully. Lotta trackers and other Java nonsense on this site.

>>The Ethernet MAC or PHY driver should be able to detect/report
>>when the link's state changes to up or down. I haven't bothered
>>to look at the Linux kernel to see how this is done.

The 'no OS' info must have slipped by you. I have had to add stuff to sense when connection is dropped, in order to change a status LED. Here's a link to my previous posts, if I can find them...

http://mail.at91.com/discussions/viewto ... 24883.html

Not available when searching the site with my username... I had to rely on Google. My username never pops up if there's no reply that includes it. There's no button where I get to see my past posts. Really questioning the utility of this site/forum.

>>But this is typically an event with limited significance.
>>Since the link is typically only between your host and a switch,
>>there could still be no hosts out there to communicate with.

You miss the problem. When you run the example project, if you are not at that time plugged into any equipment, ethernet_phy_auto_negotiate() times out and burbles the error all the way back up, with any error code being discarded along the way (sometimes NULL is good, sometimes bad). The project does not attempt to re-initiate the hardware or connection, it just fails.

I originally wrote around this by blocking on the timeout... I did not have any main-loop tasks requiring attention. Now I wish to get on with other services and to be able to complete the stack initialization. When you start the example with a physical connection, then unplug/replug, there is no problem... maddening!

Has anyone fixed this? Is this just the way it is?
blue_z
Location: USA
Posts: 1560
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAM4E16E EK need ethernet-unplug-tolerant solution

Fri Jan 06, 2017 2:52 am

scowell wrote:The 'no OS' info must have slipped by you.
Not at all.
"No OS" and device drivers are not mutually exclusive concepts.
I only mentioned Linux because that's where I saw the event reporting, i.e. I didn't read about it in a datasheet..
scowell wrote:You miss the problem.
So maybe that's why I mentioned that your post is not clear?
scowell wrote: When you run the example project, if you are not at that time plugged into any equipment, ethernet_phy_auto_negotiate() times out and burbles the error all the way back up, with any error code being discarded along the way (sometimes NULL is good, sometimes bad). The project does not attempt to re-initiate the hardware or connection, it just fails.
That sounds similar to the old AT91 code in U-Boot IIRC version 1.15.
U-Boot would only fully initialize the MAC and PHY when a link could be established; otherwise the HW initialization was incomplete, and subsequently Linux would not be able to use the Ethernet port.
I simply patched U-Boot to always try to perform the full Ethernet HW initialization.
scowell wrote:I originally wrote around this by blocking on the timeout... I did not have any main-loop tasks requiring attention. Now I wish to get on with other services and to be able to complete the stack initialization.
Sounds like your "no OS" code may be too simple, and incapable of "multitasking".
It really doesn't take too much additional code to use cooperative tasks (and state machines) to implement rudimentary multitasking.
The stumbling block is typically the conversion to cooperating tasks from a conventional/competitive mindset.

Regards
scowell
Posts: 29
Joined: Fri Feb 13, 2015 11:00 pm

Re: SAM4E16E EK need ethernet-unplug-tolerant solution

Fri Jan 06, 2017 3:06 am

Jeez, the 'alt' links sent by email don't work at all for me... and the login at the bottom when you try to reply seems to be broken for me also... latest FF, with NoScript and Ghostery. Not going to enable ten trackers.

I wrote around the problem by skipping over steps 2 and 4 during the second try at an init... you have to go through the init to wake the MAC/PHY enough to be able to ask if there's drive on the differential pins... basically, on first fail, set a global var skipNow, then poll during main() time. During the second (after you find drive on the pins) init skip the first half of netif_add() down to 'if (init(netif))', then skip the first half of gmac_low_level_init() down to ethernet_phy_auto_negotiate(). You also have to add bail points for these routines all the way down so that they leave an error trail instead of bombing anonymously. Fun!

Return to “SAM4 Cortex-M4 MCU”

Who is online

Users browsing this forum: Charlessof and 1 guest