• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 217 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432E411Y: MSP432E4111Y: Problem with NDK configuration and NC_NetStart on custom board using Simplelink 4.20 SDK

Patrick Byers
Intellectual 360 points
Part Number: MSP432E411Y
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I've developed an application for the MSP432e411Y MCU using the Simplelink 4.20 SDK and a BGAEVM development board.   The application makes use of the NDK and creates a TCP server that listens for an incoming connection and then communicates via a custom telnet interface to control the A2D, PWM, and various GPIO.   Everything works swimmingly on the development board, however when I transition the program to my production test board on which this MCU resides, I get all functionality to boot up and initialize just fine, but not the network stack.

I've traced the problem so far to an issue where  NC_NetStart appears to return an error and the NDK proceeds to shut down the stack.   This is all built using the Sysconfig framework, and so these calls are handled in the ti_ndk_config.c file that is automatically generated.   

I have a complexity in that the board I am developing this for contains an external watchdog that is pulsed by this MCU.   So if I pause the system to attempt to debug through the JTAG on this board, the watchdog will timeout and send a reset pulse to the MCU.    It would be an heavy inconvenience, but not an impossible task, to neuter this external watchdog, and I may do that if I can't solve this issue.   But I was hoping that someone might have some ideas as to what might exist from a hardware standpoint (external crystal, PHY, etc) that may be a possible cause I could investigate.  

As I said, everything boots just fine on the development BGAEVM board.   

Any advice or thoughts are welcome. 

  • 0
    TI__Guru**** 184546 points

    Hi,

    Patrick Byers said:
    Everything works swimmingly on the development board, however when I transition the program to my production test board on which this MCU resides, I get all functionality to boot up and initialize just fine, but not the network stack.

    This means that there is some subtle difference on the hardware between your board and the EVM. I will suggest you compare the schematic between either the EVM or the LaunchPad and your custom board? You might want to check if you have the RBIAS pin corrected grounded through a 4.87k ohm resistor. Do you have a 25Mhz external crystal? This is a must for the integrated PHY to work. Also check the protection diode and transformer between the PHY and the RJ45. Go to section 4.1 on the MSP432E System Design Guideline for best practice on Ethernet Interface designs. 

    Patrick Byers said:
    I have a complexity in that the board I am developing this for contains an external watchdog that is pulsed by this MCU.   So if I pause the system to attempt to debug through the JTAG on this board, the watchdog will timeout and send a reset pulse to the MCU.    It would be an heavy inconvenience, but not an impossible task, to neuter this external watchdog, and I may do that if I can't solve this issue

    Yes, I would suggest you disable the external WD for easier debug. 

  • 0 in reply to Charles Tsai
    Intellectual 360 points

    Thanks Charles,

    I've reviewed the schematics of my custom board and can't see anything that would be cause for concern (though maybe I'm overlooking something).   The only big difference I can spot is that I have the RX and TX lines swapped from what is on the DEV board (they have RX of the magnetics going to the ENOTX lines and TX to RX, I have them aligned), but this shouldn't matter as the jack is autoMDIX compatible.   But, maybe that's an issue.

    I haven't done anything to source the clock to the EMAC outside of whateverf sysconfig does when I set up the EMAC and NDK Stack.  Is there something I should be doing there that somehow I overlooked?

    custom boarddev board

    Here are the remaining MCU connections.   Does anything stand out?   I've blanked out the names of signals that are proprietary, but the function labels are there.  If more information might be helpful that I didn't include I'm happy to oblige.   

    If not and nothing stands out as 'wrong', I'll probably go into verifying the board signals to ensure everything is okay there.   

    I should add that I can verify funcionality of the GPIO, PWM and ADC signals to some degree through oscilliscope and probe if I excise the NDK startup from the MCUs program.    So it really is isolated to the EMAC.   

  • +1 in reply to Patrick Byers
    TI__Guru**** 184546 points

    Hi Patrick,

     Looks good to me on the 25Mhz OSC and RBIAS. Can you show your protection diode and transformer schematic between the PHY and RJ45?

     Can you try a bare-metal (no RTOS) ethernet example and see if you have the same problem? This is to isolate if the problem is specific to NDK or not when you said NC_NetStart will return an error. 

      There are some bare-metal Ethernet examples based on lwIP stack that can be found under C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\nortos\MSP_EXP432E401Y\lwip. I will suggest you try the ethernet_with_lwip example. It is a simple webserver. First run it on your EVM and then on your custom board. If it works on your board then the problem may be related to NDK but I'm bit doubtful at this moment because you already said your application run on the EVM but not your board. This leads me to think it is a hardware level of issue. In any case, give it a try on this lwip example. 

  • 0 in reply to Charles Tsai
    Intellectual 360 points

    Here's the transformer schematic.

    I'll set up the bare metal example as you suggest and try that out.   Probably won't get to it till tomorrow but I'll let you know how it turns out. 

  • +1 in reply to Patrick Byers
    TI__Guru**** 184546 points

    Hi,

      I see two differences. The first difference is that I don't see a protection diode between the PHY and the RJ45 connector. This is important to avoid any ESD events. You could potentially damage the PHY without proper protection. Refer to the System Design Guideline app note for details. The next difference is that you use a RJ45 connector with an integrated transformer. I'm not familiar with your chosen RJ45 connector but I don't see a problem using a RJ45 connector with an integrated transformer. As suggested in my last reply, please do the experiments to determine if the problem is NDK specific or due to the hardware difference. Here are the suggestions from my last reply. 

     Can you try a bare-metal (no RTOS) ethernet example and see if you have the same problem? This is to isolate if the problem is specific to NDK or not when you said NC_NetStart will return an error. 

      There are some bare-metal Ethernet examples based on lwIP stack that can be found under C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\nortos\MSP_EXP432E401Y\lwip. I will suggest you try the ethernet_with_lwip example. It is a simple webserver. First run it on your EVM and then on your custom board. If it works on your board then the problem may be related to NDK but I'm bit doubtful at this moment because you already said your application run on the EVM but not your board. This leads me to think it is a hardware level of issue. In any case, give it a try on this lwip example. 

  • 0 in reply to Charles Tsai
    Intellectual 360 points

    running the LWIP baremetal example led me to the realization that I hadn't been properly flashing the user registers with a device MAC address.   After resolving that issue I was able to boot up the network using both LWIP and the NDK.    I now have other problems relating to how the system is behaving vs the experience on the development board, but I believe them to be beyond the scope of this thread.