NDK problem of DM648 with single PHY

Would you like to reply me on this problem, TI employee?
Or would you like to ask the proper team to respond?

There are many posts in the forum about this problem, but nobody reponse.

Has someone already developed a custom DM648 board, which works stably with single PHY?

Thanks you.

There is a patch for the DM648 driver that may fix this issue:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/2_00_00/index_FDS.html

There are both Windows and Linux installers:

setupwin32_ndk-2_0_0_source_patch_1_0_0_1.exe

or

setuplinux_ndk-2_0_0_source_patch_1_0_0_1.bin

Thank you for your reply.
But the Patch you said cannot solve my problem. The patch can only solve the problem that EMC is initialized correctly.

May be my problem happen only in single PHY application.

Is there any TI employee who can help me?

I got a similar problem on my DM648 EVM board too.

When I using NDK 2.0.0 for the network connection, only PHY 1 is working correctly (PHY 0 cannot be used for network connection). Using this configuration, the progame will be hangup after a while (~10mins to 3hours). [It seem to be hangup faster if more data to be received]. I think the symptom is just like what Mr Shi said above.

However, when I change my program using a NDK 1.92 eval. version (which is released together with the EVM DVSDK CD), both PHY 0 and PHY 1 seems work normally. Since the eval NDK cannot be run over 24 hrs. I don't know if the hangup problem will also be solve or not.

 According to the above issue, I have done one more test as followed:

P.S. I have add the patch for the NDK 2.0.0 and even try the NDK 2.1, but they can't solve my problem neither.

See this post.  I think the problem might related to printf() calls in the EMAC driver ISR.   You can either comment them out or replace them with LOG_printf().

http://e2e.ti.com/support/embedded/f/355/t/68883.aspx

Regards,
-Karl-

Hi Karl,

Thank you for your advise. I have removed the printf() function call on EMAC driver source code. Now both PHY 0 and PHY 1 can be work correctly.

However, I still experience the problem hangup after a long run (~24hrs). I'm still checking the reason......

Edmond,

Do you have any further update on your issue?  You stated in the last post that you were checking further -- did anything come of that?

Dave

xiudong shi said:

hi,
I have a problem about NDK for DM648 with single PHY application, and the details as follow:

Problem:
(1) After correctly running for a few hours, the commucation will stop. There is the same problem for 100M and 1000M, Marvell PHY or Vitesse PHY.
(2) When stopped, the routine will goto a infinite loop, from SYS_Abort to UTL_doAbort, by HAL routine "CPSW_MACINVECTOR_HOSTPEND".
(3) And at this time, I always found register DMASTATUS -> RX_HOST_ERR_CODE = 0010, it means "OWNERSHIP bit not set in input buffer".
(4) Because the ethernet HAL codes is very complex, I cannot trace the routine.

Hardware:
(1) DM648 with single PHY on SGMII0.

Software:
(1) I've tested NDK1.92/1.94/2.00/2.01, found the same problem.
(2) I've tested NDK in BIOS 5.31.02/5.31.08/5.33.06/5.41.04.18, Code_Generation_Tools 6.0.8/6.1.13/7.0.3, and found the same problem.

There are many engineers to ask the similar problem in the internet. I suspect that it is a NDK bug in single PHY application, which could be found only after long time testing.
I've been puzzled about months, and I need TI's help. If needed, I can send my custom board and codes to TI engineer for test, by Fedex from China.
My email: david@machinevision.cn

I've post this problem in: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/62024.aspx?PageIndex=2
According to TI employee's advice, I post it here again.

Thank you.

I meet the same  problem as Mr xiudong shi. And I can't find the final solution here, please give me some suggestion about this . Thanks!

Please ensure that there are no printf() calls being made from within ISR context, as mentioned in the above post:

"See this post.  I think the problem might related to printf() calls in the EMAC driver ISR.   You can either comment them out or replace them with LOG_printf().

http://e2e.ti.com/support/embedded/f/355/t/68883.aspx"

Thanks,

Steve