MSP432E401Y: Ethernet won't Sync

Hi,

  I have a few questions:

  - How does the controller board wake up the Ethernet modem?

  - Is there any way that the controller board knows the Ethernet modem has been powered up?

  - If you know the status of the modem (e.g. modem is powered up from a powerdown) can you do a software reset in your firmware on the controller board instead of hardware reset through the RST pin?

Charles,

The controller board wakes up the Ethernet modem via a relay on the board so yes, it knows exactly when the modem has been powered up.

I tried doing a software reset in assembly code by loading zero into register r2 and then "mov pc, r2", but that didn't work.  It would be helpful if you could explain how to do a software reset.

Doing a software reset is my least favorite choice because the processor is also doing other tasks that I would rather not disturb.  But, if that's my only choice I'm just going to have to do it that way.

Thank you for your response.

Hi Brad,

  I will suggest you first try peripheral reset for Ethernet EMAC and Ethernet PHY. Please find the SysCtlPeripheralReset usage below. 

https://software-dl.ti.com/simplelink/esd/simplelink_msp432e4_sdk/3.10.00.11/docs/driverlib/msp432e4/html/group__sysctl__api.html#gab8c537abe40caacd5dfa7ffdedefb6b9

  To reset the entire device in case the peripheral reset does not give you the desired result, you can call SysCtlReset(). 

https://software-dl.ti.com/simplelink/esd/simplelink_msp432e4_sdk/3.10.00.11/docs/driverlib/msp432e4/html/group__sysctl__api.html#ga7e7eaf3273efa935f7bedfd3760d11b8

Charles,

It's working by resetting the entire device so I have that as a backup but, as I mentioned, I'd rather not have to do it that way.

Now I'm trying to do the peripheral reset approach, but it's not liking the C commands I'm entering (I don't have a lot of experience with C).

For example, here are a couple of commands I tried:

SysCtlPeripheralReset( uint32_t SYSCTL_PERIPH_EMAC );
SysCtlPeripheralReset( uint32_t SYSCTL_PERIPH_EPHY );

With those I got the compilation error "error 256 type name is not allowed", then when I tried them without unit32_t it said SYSCTL_PERIPH_EMAC and SYSCTL_PERIPH_EPHY were undefined.

Can you see what I'm doing wrong?

Thank you.

Hi,

  You just need to call as below. There is no need to typecast it. 

SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC );
SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY );

If you want to typecast then you need the parenthesis. 

SysCtlPeripheralReset((uint32_t)SYSCTL_PERIPH_EMAC );
SysCtlPeripheralReset((uint32_t)SYSCTL_PERIPH_EPHY );

You need to also make sure that sysctl.h header file is included on the top of source file where you are making the SysCtlPeripheralReset call. The header file has the definition for SYSCTL_PERIPH_EMAC and SYSCTL_PERIPH_EPHY. See below snippet.

Hi,

I included sysctl.h 

I also had to add a zero to the end of SYSCTL_PERIPH_EMAC and SYSCTL_PERIPH_EPHY to make them SYSCTL_PERIPH_EMAC0 and SYSCTL_PERIPH_EPHY0 because those were the definitions in sysctl.h.

It compiled ok and I ran my program but it still didn't sync up - there was no communication.

Then I put a breakpoint at SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0 ); and I followed execution into SysCtlPeripheralReset in sysctl.c so it looks like it's executing properly, but still no communication.

Any ideas on what might be wrong?

Thank you for any further help.

My bad. I miss the 0 in SYSCTL_PERIPH_EMAC0 and SYSCTL_PERIPH_EPHY0.

I think after you reset the peripheral, you will need to re-initialize the EMAC, PHY and the software stack again. A system reset will guarantee that EMAC and PHY and the TCP/IP stack (not sure which stack you use like lwIP or NDK) is reinitialized.

Hi,

It's not clear to me how to re-initialize the EMAC, PHY and the software stack again.  I tried adding commands similar to the following below the SysCtlPeripheralReset commands because those are the commands that set up the Ethernet port in the first place, but when they executed the board crashed.

SysCtlPeripheralReset( SYSCTL_PERIPH_EMAC0 );
SysCtlPeripheralReset( SYSCTL_PERIPH_EPHY0 );

pui8MACArray[0] = ((ui32User0 >> 0) & 0xff);
pui8MACArray[1] = ((ui32User0 >> 8) & 0xff);
pui8MACArray[2] = ((ui32User0 >> 16) & 0xff);
pui8MACArray[3] = ((ui32User1 >> 0) & 0xff);
pui8MACArray[4] = ((ui32User1 >> 8) & 0xff);
pui8MACArray[5] = ((ui32User1 >> 16) & 0xff);

uint32_t ui32IPAddr = 0xc0a80165;
uint32_t ui32GWAddr = 0xc0a80101;
uint32_t ui32NetMask = 0xffffff00;

lwIPInit(g_ui32SysClock, pui8MACArray, ui32IPAddr, ui32NetMask, ui32GWAddr, IPADDR_USE_STATIC);

I understand that a system reset will re-initialize everything, but I'm trying to get away from resetting the whole system.

I'm pretty sure the board uses TCP/IP.

Thank you for any more help you can provide.

Hi Brad,

  While I'm searching for other relevant clues to your problem, I find this one maybe helpful where it talks about turning off flash prefetch buffer.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/392725/link-status-of-ethernet-on-tm4c-129-platform

I wonder if the problem is related to the below errata where you will need to turn off the flash prefetch buffer before you initialize Ethernet. 

Please also refer to this post too. https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/739616/tm4c1294ncpdt-ethernet-errata-exact-workaround-for-tm4c1294ncpdt?tisearch=e2e-sitesearch&keymatch=flashconf#

Hi Charles,

No luck.  I forced prefetch off by setting bit 16 of the FLASHCONF register.  I reset PHY first then EMAC as suggested by the first link:

SysCtlPeripheralReset( SYSCTL_PERIPH_EPHY0 ); 
SysCtlPeripheralReset( SYSCTL_PERIPH_EMAC0 );

Then I forced prefetch back on by setting bit 17 of the FLASHCONF register.

After taking those three steps the Ethernet connection was still not working.  I didn't take any further steps to get it working.

One thing that is puzzling is that Gavin, in the first link, said that when he plugged the ethernet cable in first and then powered on the device it failed, but it was successful if he powered up the device first and then plugged in the cable. 

This is the exact opposite from what I'm seeing.  I my case the failure occurs when I plug in the cable after the device is powered up.

Thank you for all your help.

Hi Brad,

  After you turn off the flash pipeline and instead of just resetting the PHY and EMAC, did you reinitialize the stack. 

1. Write 1 to the FPFOFF bit to disable the prefetch buffers
2. Initialize EMAC and PHY // The initialization lwIPInit() is supposed to reset the PHY and EMAC for you if you trace the source code for the function.
3. Write 1 to the FPFON bit to enable the prefetch buffers

If the above steps do not resolve the issue, I'm not sure what to suggest other than to use the system reset. 

Hi Charles,

I set FPFOFF, ran lwIPinit(), then set FPFON and still no success. 

Just to be careful I checked the parameters for lwIPinit() and they were exactly the same for the original configuration (where the board boots up with the cable connected and the ethernet connection is successful), and for the second configuration (where the cable is plugged in while the board is already up and I try re-initializing the connection and it's not successful).

One more interesting thing is that when I use lwIPinit(), the board gets hung up in ip4route() which is in ip4.c.

It seems to me that I can't be the only person who has tried connecting to an Ethernet server while the client board is already powered up.  I think I'll wait a couple of days and try to rephrase the question in a new post.  Maybe I just wasn't clear in the way I asked the question.

Thank you so much for your time and the effort you made to help me.

Hi Brad,

  I'm still not sure what is the cause of the problem. Can you do some experiments?

  - Can you run the code on the LaunchPad? Can you repeat the same issue. I assume you have been running on your own custom board. 

  - Can you run the stock SDK Ethernet example? Can you repeat the same issue?

  - I believe you have the MCU setup as a client and you are connecting to a server, correct? I think after the Ethernet modem is switched off it may take some time to initialize before it can respond to client request. My understanding of your setup is that the controller board will wake up the modem and it knows when the modem is powered up. Can you add some delay after the modem is powered up. It can take time from the time you know the modem is powered up until the modem is fully initialized. I don't know the amount of delay you need. You will need to experiment if any delay will work at all. Please also use Wireshark to capture the Ethernet transactions between the MCU and the modem. If the delay of any amount does not work, then it may not be related to modem's initialization. 

  - You mentioned about the Ethernet modem. Do you have a user's guide or datasheet for it? Is this a router or a switch?

  - Can you do an experiment by connecting the MCU to a Ethernet switch instead? Once the whole setup is working, please power off the switch and then on again. I'd like to know if a switch will make a difference compared to your Ethernet modem. 

Hello Charles,

I was running the code on the MSP-EXP432E401Y launchpad.  My customer had the prototype controller board itself.

Yes, my MCU is setup as a client and the ethernet modem is a server.  I waited quite a while after the modem was powered up so I'm confident it was fully initialized.  I'm not sure how I can use Wireshark since the transaction doesn't involve a computer.  It is only between my controller board and the ethernet modem.

The unit I'm working with is a Netgear model LB1120.

The problem with experimenting with the SDK example and/or an ethernet switch is that the only way for me to know that the connection is successful is if I get some very specific data from the modem structured in a very specific manner and I wouldn't be receiving that data with these other experiments whether it was connected or not.

Thank you for your continued interest.

Hi Brad,

  I wish I could provide more insights into the problem. I will search the e2e archive again to see if anyone with similar issues. I hate to say a system reset is the only option. But will it be a viable option for you? 

Brad McMillan said:

It compiled ok and I ran my program but it still didn't sync up - there was no communication.

The user manual for the Netgear model LB1120 indicates that the connect device must use DHCP to obtain an IP address, rather than use a static IP address. E.g. from the Table 7. Quick tips for troubleshooting:

When the controller board powers up LB1120, maybe the LwIP stack needs to re-obtain a DHCP lease.

How does the program re-initialise the LwIP stack when the LB1120 is powered up?

Hi Chester,

The controller board does sync up if I reset the processor after the LB1120 is powered up and my application uses a static IP address, but I would rather use an approach that doesn't require a full reset so using DHCP might be better.

I looked at the lwip based ethernet_weather example because it operates as a client and uses DHCP and it looks like the connection is set up with the command:

     lwIPInit(g_ui32SysClock, g_sEnet.pui8MACAddr, 0, 0, 0, IPADDR_USE_DHCP);

Then I used a similar command in my application to replace the command that uses a static IP address.  When I ran my application it got hung up at line 1040 in lwiplib.c as shown here:

uint32_t
lwIPLocalIPAddrGet(void)
{
  #if LWIP_AUTOIP || LWIP_DHCP
    if(g_bLinkActive)
    {
       return((uint32_t)g_sNetIF.ip_addr.addr);
    }
    else
    {
       return(0xffffffff);
    }
#else
    return((uint32_t)g_sNetIF.ip_addr.addr); <<<<<<<<<<<< hung up here @ line 1040 in lwiplib.c
#endif
}

The values for LWIP_AUTOIP and LWIP_DHCP were both zero and I think they should be 1's.  Can you tell me how they should be set to their proper values and whether or not there any other values that should be initialized to get DHCP to work properly?

Also, in most cases the controller board will be powered up without being connected to an LB1120.  Is the board going to get hung up trying to initialize the ethernet connection when the LB1120 is not plugged in?

Thank you so much for your assistance.

Brad McMillan said:

The values for LWIP_AUTOIP and LWIP_DHCP were both zero and I think they should be 1's.  Can you tell me how they should be set to their proper values and whether or not there any other values that should be initialized to get DHCP to work properly?

The enet_lwip example in TivaWare is set to use DHCP to obtain an IP address. From comments in the enwi_lwip.c source file:

//! This example application demonstrates the operation of the Tiva
//! Ethernet controller using the lwIP TCP/IP Stack.  DHCP is used to obtain
//! an Ethernet address.  If DHCP times out without obtaining an address,
//! AutoIP will be used to obtain a link-local address.  The address that is
//! selected will be shown on the UART.

Brad McMillan said:

The values for LWIP_AUTOIP and LWIP_DHCP were both zero and I think they should be 1's.  Can you tell me how they should be set to their proper values and whether or not there any other values that should be initialized to get DHCP to work properly?

Hi Brad,

  Sorry, I missed your reply. In the lwipopts.h file you need to change these two #defines to 1. 

#define LWIP_AUTOIP                     1

#define LWIP_DHCP                       1

Hi Brad,

  Glad to hear your problem is solved. Could you please elaborate what else did you do other than to change to DHCP to resolve the syncing issue? Hope to hear your solution that may benefit others in the community. 

Hi Charles,

It turned out to be very simple.  In the initialization code I removed the statements that were setting up ethernet to use a static ip address and replaced them with:

     lwIPInit(g_ui32SysClock, g_sEnet.pui8MACAddr, 0, 0, 0, IPADDR_USE_DHCP);

Then I defined LWIP_AUTOIP and LWIP_DHCP to have values of 1 in lwipopts.h as you suggested last week.

Now whenever the LB1120 powers up it automatically synchronizes with the controller board.  I don't need to do anything from the controller board side to initiate synchronization.

Once again, thank you both.  I wouldn't have been able to solve this with out help from you and from Chester Gillon.

Brad