DP83640: FreeRTOS plus UDP project help - RM46L852

Hello,

I believe this may be a software issue, as if the PHY can be accessible via registers and links up and communicates fine outside of the application. Unfortunately, this forum is more for PHY HW based issues, and thus it would be our recommendation to check out this issue with the team responsible for driver. What is the intention with using DP83640 vs some of our newer PHYs which have RMII and do 10/100Mbps?

Sincerely,

Gerome

Hello Gerome

Thank you for your response.

I am new to this board and this MCU for that matter, and I need to test out the peripherals on this board including ethernet. If there is an example networking project for the RM46L852 using DP83640 that you can share with me, it'll be really helpful!

Sincerely,

Karan

Hi Karan,

I would advise checking in with the RM team on this. Allow me to reassign.

Sincerely,

Gerome

Hi Gerome

Sure, thanks!

Sincerely

Karan

Hi Karan,

To operate phyter in RMII interface, please follow the modifications suggested in below two threads:

(+) TMS570LC4357: MII and RMII design with LWIP - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) TMS570LC4357: Configure the RMII mode on the network port, and no ping using lwip-1.4.1 - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

And for Free RTOS based ethernet example you can refer below example:

(5) [FAQ] TMS570LC4357: Examples and Demos available for Hercules Controllers (E.g. TMS570x, RM57x and RM46x etc) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi Jagadish,

    May I ask if it is necessary to modify MPU related permissions?

Because in RMII mode, when calling the output interface of EMAC, no signal was detected on TX_EN TXD_0 TXD_1

Thanks!

RongPeng Que said:

 May I ask if it is necessary to modify MPU related permissions?

I think we no need to do any MPU related modifications unless we have cache. But for this device there is no cache so i think no need to do any MPU related modifications.

In cache devices we will get coherence issues with the default configurations, so there we will do some changes to MPU settings.

Hi Jagadish,

 Thank you for your support.

    I am using the official routine : git://git.ti.com/hercules_examples/hercules_examples.git

Build-RM46 can compile and burn normally with Static IP, VCC and reset default to high level.

SCH is as follow(RMII design):

Problem : No signal was detected on TX_EN TXD_0 TXD_1，how to modify it？

Thanks！

Hi Rongpeng Que,

My Apologies for the delay in the reply.

I verified your schematic, and it looks fine for me except i am doubting on RESET_N connectivity.

Looks like you connected this pin of PHY to the MCU G1 pin, and default state of this pin looks pull down, so are you writing logic-high on this pin?

But still it should not be issue for transmitting data out on TXD_0 and TXD_1. Can you please give your complete project for the verification? If you are using Hercules examples, please tell me exactly which application you are using because there are separate examples for launchpad and HDK, so exactly which example you are using?

--
Thanks & regards,
Jagadish.

Hi Jagadish,

   This is a testing project that has been changed from the official routine.

   TI_LwIP_by_RongPeng.rar

Thanks!

Hi,

Thanks for the project, i am on sick leave yesterday and now i will go through your project and will try to provide my update by tomorrow.

--
Thanks & Regards,
Jagadish.

Hi Rongpeng Que,

Just now i found one issue with your schematic, 

I think we are connected 50-Mhz crystal between X1 and X2 right?

But according to PHY datasheet, for RMII slave mode we should connect 50Mhz oscillator source only and we should not connect crystal in RMII slave mode.

I think it will not generate clock from 50Mhz crystal in RMII slave mode. Maybe this is the reason in our HDK boards (which can support both RMII and MII mode), we gave oscillator source provision instead of just crystal like as below. 

If we gave crystal, then for MII mode it will be fine but for RMII mode crystal will not be useful for this purpose we gave oscillator source provision to compatibility for both MII and RMII modes.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

    Thank you for your analysis.

My hardware design is not compatible with MII, so a 50M crystal oscillator is provided for RMII slave mode.

The values of PHY registers can be obtained through mdio, as follows

register=[0x0] reg_value=[0x3100]  
register=[0x1] reg_value=[0x78ed]  
register=[0x2] reg_value=[0x2000]  
register=[0x3] reg_value=[0x5ce1]  
register=[0x4] reg_value=[0x1e1]  
register=[0x5] reg_value=[0xdde1]  
register=[0x6] reg_value=[0xf]  
register=[0x7] reg_value=[0x2801]  
register=[0x8] reg_value=[0x0]  
register=[0x9] reg_value=[0x0]  
register=[0xa] reg_value=[0x0]  
register=[0xb] reg_value=[0x0]  
register=[0xc] reg_value=[0x0]  
register=[0xd] reg_value=[0x0]  
register=[0xe] reg_value=[0x0]  
register=[0xf] reg_value=[0x0]  
register=[0x10] reg_value=[0x4815]  
register=[0x11] reg_value=[0x0]  
register=[0x12] reg_value=[0x2c00]  
register=[0x13] reg_value=[0x0]  
register=[0x14] reg_value=[0x10]  
register=[0x15] reg_value=[0x0]  
register=[0x16] reg_value=[0x100]  
register=[0x17] reg_value=[0x21]  
register=[0x18] reg_value=[0x0]  
register=[0x19] reg_value=[0x8021]  
register=[0x1a] reg_value=[0x904]  
register=[0x1b] reg_value=[0x0]  
register=[0x1c] reg_value=[0x2]  
register=[0x1d] reg_value=[0x6011]  
register=[0x1e] reg_value=[0x83e]  
register=[0x1f] reg_value=[0x0]

It shows that the PHY is in RMII slave mode.

Returning to the previous question, does the state of PHY affect the output of MAC?

Thanks!

RongPeng Que said:

My hardware design is not compatible with MII, so a 50M crystal oscillator is provided for RMII slave mode.

Can you please confirm whether you provided crystal or oscillator source?

The below is the Oscillator source:

As you can see it will take power supply, and it will have the internal oscillator circuit so it can directly generate the clock without using the oscillator circuit present inside the DP83640 PHY IC.

The below is the using only Crystal:

Here crystal doesn't take any supply, and it will use the internal oscillator circuit in the DP83640 PHY IC to generate the clock.

Now if you verify your schematic, you are using crystal not an oscillator source right?

It doesn't take supply and its connectivity same as we discussed for crystal circuit.

And what DP83640 PHY datasheet is saying that we cannot connect crystal in RMII slave mode, and we can only connect oscillator source which can generate 50Mhz clock. This is because the internal oscillator circuit in the PHY is not capable of generating 50Mhz clock from crystal.

As you can see same datasheet mentioning for only RMII master mode we can use either crystal or oscillator source, any one of them can be used. But they didn't mention this either crystal or oscillator source to the RMII slave. So, in RMII slave we must go for oscillator source instead of crystal.

You can get PHY register values, because MDIO doesn't depends on the above clock, but RMII communication will not work if you use 50Mhz crystal.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Can you please confirm whether you provided crystal or oscillator source?

=》Okay, I understand what you mean. I'll have the hardware engineer confirm this question again.

Thank you very much!

Hi Jagadish，

Can you please confirm whether you provided crystal or oscillator source?

=》It is oscillator.

And PHY can output a clock of 25M at CLK_OUT(PIN 24).

Thanks!

Hi RongPeng Que,

RongPeng Que said:

It is oscillator.

But in your schematic i didn't see any oscillator. I could only see the crystal.

RongPeng Que said:

And PHY can output a clock of 25M at CLK_OUT(PIN 24).

Instead of CLK_OUT, can you please directly measure the clock on X1 pin? If you are using 50-Mhz oscillator source, then we should get the same clock on X1 pin.

If it is 50Mhz clock on X1 then our ethernet communication should work without issues, if it is 25Mhz then we should need to replace the 50Mhz oscillator source.

--
Thanks & regards,
Jagadish.

Hi Jagadish，

    I measured with an oscilloscope that both X1 and X2 have a clock signal of 50M.

Thanks!

Hi RongPeng Que,

RongPeng Que said:

    I measured with an oscilloscope that both X1 and X2 have a clock signal of 50M.

Then it is fine.

And i also verified your pin mux settings, they also look good.

My suggestion would be that, instead of directly trying out FreeRTOS based UDP example. My suggestion would be first try EMAC loopback example in the HALCoGen:

Here you can find step-by-step procedure and code for implementing this example:

Once above example executed successfully, then you can execute below LwIP demo.

If the above example also executed successfully then we can try it out FreeRTOS UDP code.

--
Thanks & regards,
Jagadish.

Hi Jagadish，

    EMAC loopback demo work well. But LwIP demo Running abnormally,MAC did not output any information to PHY.

Thanks!

Hi RongPeng

I am getting error while trying to import your project:

Please reattach it.

--
Thanks & regards,
Jagadish.

Hi Jagadish，

Please try again by following the steps below

Thanks!

Hi RongPeng,

I think i found one issue with your project:

I think here you need to change the order of the data,

Because, if you verify the definition of the lwIPInit function, they are assuming ipAddr, netMask and gwAddr bytes will be in reverse order(because of little endian device) that is the reason they are changing the order of these addresses at below highlighted lines:

As you can see here we are type casting 2 byte array and sending right, so while calling the lwIPInit function the bytes order will be LSB first and MSB last.

so that is the reason they are interchanging the bytes in definition of lwip function.

so please either change the bytes order before transmitting to the function as below:

or else don't call the htonl function for ip addresses, as you already sending them in right order:

--
Thanks & regards,
Jagadish.

Hi Jagadish，

   Thank you for your reminder.

These are the logs after changing:

But in the official routine uses IPADDR_USE_DHCP, but due to my use of IPADDR_USE_DHCP to allocate IP, code will stop in  hdkif_transmit, as shown in the screenshot below

So I can only choose to run the program with a static IP address.I tried using the device as a client or server but there is still no data output from the MAC to the PHY.

Thanks!

HI RongPeng,

RongPeng Que said:

These are the logs after changing:

These logs look like fine.

what about these logs? Are they due to static IP?

Also, can you please try to increase the below DHCP try "count" value from 10 to 100

--
Thanks & regards,
Jagadish.

Hi Jagadish，

    what about these logs? Are they due to static IP? =>Yes,They due to static IP.

For IPADDR_USE_DHCP mode,Whether I change the "count" to 100 or 1000, its performance remains the same. Stop here in hdkif_transmit function

/* TODO: (This is a workaround) Wait for the EOQ bit is set */
    while (EMAC_BUF_DESC_EOQ != (hdkif_swizzle_data(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ));

Thanks!

Hi RongPeng,

This looks same issue as ours:

(+) TMS570LS3137: TMS570LS3137PGE with MINIMAL LwIP and MII switch - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Is it possible to try the workaround given here?

--
Thanks & regards,
Jagadish.