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 am working with a LP-AM243 for a Profinet device application developpement. Unfortunately, since the beginning, the behaviour of this board is very erratic. I suspect init error.
Everything is running fine if I flash the Profinet device demo after a cold boot with the following procedure: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_01_00_36/exports/docs/api_guide_am64x/CCS_LAUNCH_PAGE.html
If not after a cold boot, it is crashing in the phy communication. Some example cases:
- I am having this error in my console: PRU_PHY_disable1GbAdver: 0xd000c EC is fatal=1, SRC:PRU_PHY_disable1GbAdver:1701
- Sometimes the program blocks in mdio_v0.c line 100:
/* Wait till transaction completion if any */ while(CSL_MDIO_USER_GROUP_USER_ACCESS_REG_GO_EN_0x1 == CSL_FEXT(hMdioRegs->USER_GROUP[userGroup].USER_ACCESS_REG, MDIO_USER_GROUP_USER_ACCESS_REG_GO)) {}
Thus, we are quite concerned by the stability of the design for a production design.
Thanks by advance
Hi Kevin,
First of all, you are working on the AM243x LP, but you are using MCU+ SDK 08.01.00.36 for AM64x. You should have used the MCU+ SDK 08.01.00.36 for AM243x.
Secondly, have you done the steps in AM243x MCU+ SDK: EVM Setup (ti.com)? If no, you should have done it before you run your application. The SBL_NULL will do the board initialization for AM243x LP.
Best regards,
Ming
Hi Ming,
Sorry, I've copied the wrong link. I am using the SDK for AM243x because the SDK folder name is "mcu_plus_sdk_am243x_08_01_00_36" on my computer. Also, the CCS Target Configuration is named AM243x_XDS110.ccxml.
I also did the steps to flash SBL_NULL bootloader.
The weird thing is that I can run the Profinet demo application like a charm on cold boot and sometimes on hot reset but most of the time it is hanging on hot reset.
Best regards,
Kevin
Hi Kevin,
The only difference between the cold reset (POR) and warm reset is the on-chip memory reset and the peripheral resets. It sounds like the example is depending on some initial values in the memory. I will report this to our software team for further investigation.
Best regards,
Ming
Hi Ming,
Thanks a lot. Also, I've noticed that I have a different behaviour if I flash the lwip demo application and then flash back the Profinet demo. Even hitting the "SoC reset" button does not change a thing so it might be an ethernet phy init problem.
Best regards,
Kevin
Hi Kevin,
You are correct. Our software team has come back with answer: "PHYs are reset only during POR, so this is a requirement for Industrial Ethernet !" Looks like the POR (cold reset) is a must have for the Profinet code.
Best regards,
Ming
Hi Ming,
Thanks for your answer. Thus, is there something I can do to reset PHYs on startup?
Best regards,
Kevin
Hi Kevin,
You may use GPIO pin to reset the phy by software, but it will create huge delay during the start up time. Can you explain the necessity of using warm reset?
Best regards,
Ming
Hi Ming,
The only reason is because I'm too lazy to power cycle the board each time I'm loading a new program.
Best regards,
Kevin
Hi Kevin,
If the "warm reset" is not something necessary for your product, then simply do the "cold reset" (power cycling) every time is your solution, because "PHYs are reset only during POR, so this is a requirement for Industrial Ethernet !"
If the "warm reset" is something necessary for your product, then you have to use the GPIO pin to reset the phy by software
Best regards,
Ming
Hi Ming,
I did some tests today and resetting the PHYs by GPIO did not solve the problem: the program is still hanging on MDIO commands. Here is my code to reset the PHYs:
void Phy_reset() { GPIO_setDirMode(CONFIG_GPIO_RGMII1_RST_BASE_ADDR, CONFIG_GPIO_RGMII1_RST_PIN, GPIO_DIRECTION_OUTPUT); GPIO_setDirMode(CONFIG_GPIO_RGMII2_RST_BASE_ADDR, CONFIG_GPIO_RGMII2_RST_PIN, GPIO_DIRECTION_OUTPUT); GPIO_pinWriteLow(CONFIG_GPIO_RGMII1_RST_BASE_ADDR, CONFIG_GPIO_RGMII1_RST_PIN); GPIO_pinWriteLow(CONFIG_GPIO_RGMII2_RST_BASE_ADDR, CONFIG_GPIO_RGMII2_RST_PIN); for (volatile uint64_t u = 0ull ; u < 100000000 ; u++) ; GPIO_pinWriteHigh(CONFIG_GPIO_RGMII1_RST_BASE_ADDR, CONFIG_GPIO_RGMII1_RST_PIN); GPIO_pinWriteHigh(CONFIG_GPIO_RGMII2_RST_BASE_ADDR, CONFIG_GPIO_RGMII2_RST_PIN); }
The macros are defined as follow:
#define CONFIG_GPIO_RGMII1_RST_BASE_ADDR (CSL_GPIO0_BASE) #define CONFIG_GPIO_RGMII1_RST_PIN (73) ... #define CONFIG_GPIO_RGMII2_RST_BASE_ADDR (CSL_GPIO0_BASE) #define CONFIG_GPIO_RGMII2_RST_PIN (20)
I tried to call Pinmux_init() and my Phy_reset() functions right after booting (first functions of the main()) but the program is still hanging at startup on MDIO commands. Did I miss something?
Best regards,
Kevin
Hi Kevin,
I have checked with the software team on this. Will get back to you as soon as I hear anything from them.
Best regards,
Ming
Hi Kevin,
The Profinet example does need the "POR reset" right now. If you are not blocked by this requirement, we will file a low priority ticket for it and will fix it in the future releases. If you are blocked by this issue, please let us know.
Best regards,
Ming
Hi Ming,
Could you please give me some details about what I am missing in my code? Isn't it resetting the PHYs as requested? I'm just trying to understand the problem.
Also, could you give me the link to the ticket if publicly available?
Thanks a lot, it is not blocking for us but annoying to unplug the USB cable et replug it.
Best regards,
Kevin
Hi Kevin,
I did not see anything wrong with your code to reset the phys. The "warm reset" issue needs more investigation to figure out the root cause. If the "POR reset" can make the example work and it is not block you, then we will give it a lower priority. Are you OK with the suggestion of "give it a lower priority"? If yes, I will file a ticket for it. Thanks!
Ming
Hi Kevin,
I have filed a ticket for this issue and it should be fixed (or well documented) in the future MCU+ SDK release. Since the ticket system is not public available, so I will not share the link. For your reference the ticket number is MCUSDK-3668. Thank you very much for your patience. I will close this thread for now.
Best regards,
Ming