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.
Hello,
I have a custom board who's design is based on TM4C1294NCPDT. The Ethernet section of the board is based on the Launchpad design. The Ethernet differential output pins are connected to a Pulse Jack with integrated magnetics. The RBIAS pin is grounded through a 4.87Kohm, 1% resistor.
Now in my design, I have connected the Ethernet linking and activity LEDs (EN0LED0 and EN0LED1 )to pins PK4 and PK6 respectively( which in case of Launchpad they are connected to pins PF0 and PF1),so I changed the LED configuration of pins in TCP echo example in init_EMAC function. I can see the linking LED continuously glowing whenever I connect the Ethernet cable and also the activity LED blinks when there is some Ethernet RX/TX activity and I get following messages in console,
ss in flash
Starting the TCP Echo example
System provider is set to SysMin. Halt the target to view any SysMin contents in ROV.
Service Status: DHCP : Enabled : : 000
Service Status: DHCP : Enabled : Running : 000
but it does not shows any network added and the IP address.
An arbitrary MAC address (F5-DC-EA-90-10-F2) is programmed into the MCU using the Flash Programmer per TI documentation as well as referring the e2e thread https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/476635/1717385#1717385.
However, when I dump the TCP echo example from the TI-RTOS, the MCU does not get the TCP/IP address from the DHCP server in my network. The application shows DHCP enabled messages on the console and waits for the IP address.. However here, I suspect it does not pick up the programmed MAC address to broadcast the DHCP...If it is so how do I check this and how do I solve this issue?.Does it requires any changes on the software side or in example code to get IP address from DHCP for a custom board?
FYI:
CCS version: CCS_6.1
Tivaware: TivaWare_C_Series-2.1.3.156
TI-RTOS: tirtos_tivac_2_16_01_14
Board: ek-tm4c1294xl Launchpad.
Charles Tsai said:1. Can you run some non TI-RTOS ethernet examples on the custom board with your arbitrary MAC address?
Steering the (overly) inspired to KISS - good that.
And "wireshark" provides the means to perform a "meaningful test" upon (one limited aspect) of user's code (at a time) - again "focused guidance" (likely Successful/Inspired) guidance - from KISS.
Charles Tsai said:It will be good if he has another board to confirm if multiple boards are having the same problem.
Indeed - that IS the (only) SANE way to "fly" - is it not? (once again KISS arrives to poster's rescue!)
That said - has this poster not (already) generated (at minimum) 4-6 such "In case of CUSTOM Board" posts?
And - as some HERE (ahem) have (already advised) "HAS NOT THE TOO SOON MOVE - FROM LPAD TO "CUSTOM BOARD" - CLEARLY PREMATURE - contributed to & caused much WASTE of Time/Effort?
Is not the "Purpose of the LPad - to fully/properly confirm that, "ALL IS WELL - PRIOR TO IMPLEMENTING ANY CUSTOM BOARD?" Are we to accept that "such has been done - properly & completely" - prior to poster's "Washing Up - onto this (and 3-4 other) rock-strewn shores?) (yet using that "custom board" as an effective "flotation device" ... proving that it IS, "Good for something!")
Is this (clearly) marked "MCU Forum" to switch - at poster's will - to "Pcb Design Basics?" Is it not true that even the "disguise of the same basic question" - presented across multiple (so similar) threads - all target the SAME, "Component and/or Pcb Design basics?" (devouring MORE of the forum's rare/restricted assets!)
Investing the time & effort to "INSURE THAT THE LPAD PERFORMS AS DESIRED - and ONLY THEN "fully/properly" deploying the LPad's key/critical components & design elements - is the "Surest Path to success!" (and displays (some) respect for those here who DO NOT invite such rushed/over-challenge...)
The MAC address is read from flash and made available to the stack with a call to InitEMAC() in the dev kits. The function is pretty simple and you can hard code the numbers stored in macAddress[] to eliminate memory values as a possible cause of failure.
Not calling the function at all could be your problem.
The missing "Network Added:" output makes me think your problem is code related. I think it gets printed out regardless of if you botched the hardware (which hopefully isn't the case).