Problems with the PFE MAC debugging of the S32G274 I am currently debugging PFEMAC using my own board. Now I have encountered a problem. When I initialize the serdes in the APP program, the PFEMAC communication is normal. Since I want to start both the M core and the A core simultaneously, I need to move the serdes initialization to the bootloader. However, when I put the serdes initialization in the bootloader and remove the serdes initialization from the APP, and start the M core alone, the PFEMAC stops working properly. I wonder how else I can troubleshoot this issue? Re: Problems with the PFE MAC debugging of the S32G274 1. I checked the bootloader and APP here the PHI0 configuration is the same, also both checked under the control of the MCU; 2. Eth_43_PFE_PreInit(NULL_PTR) this function I found that no matter whether called or not are still able to communicate; M core of the APP initialization only left Eth_Pfe_Init_IRQ() ; Eth_43_PFE_Init(NULL_PTR); for (iface = 0U; iface < ETH_43_PFE_NUM_CONTROLLER_CFG; iface++) { Eth_43_PFE_SetControllerMode(iface, ETH_MODE_ ACTIVE); }, and there is also the initialization of PFE in the lwip stack static void gmacif_low_level_init(struct netif *netif). 3. The PFE MAC0 is used, and I am connecting to the switch's network cable with my laptop to see if I can ping the s32g274's IP to judge, our oscilloscope can't measure the signal waveform of the SGMII Re: Problems with the PFE MAC debugging of the S32G274 Hi, sdx111
Thank you for your response!
1. You can check if this PHI0 is configured consistently in Clock Configuration, which is the Serdes reference clock object, and if the clock is configured again in the M-core, checking the box Under the control of the MCU may configure the clock again, resulting in an impact on the initialization of the previous Serdes.
2. PFE related initialization should be checked as well. what other APP initialization configurations do you keep for the M core?
According to the manual, the call to the function Eth_43_PFE_PreInit(NULL_PTR) should be made before the clock initialization of the PFE, and if you call it after that, the M-core may have problems if it then adjusts the clock initialization of the PFE.
3. How did you perform the signal test and did you use PFE_MCA0 or PFE_MAC1? Is it convenient to test the SGMII signals before and after the SJA1110?
BR
Joey. Re: Problems with the PFE MAC debugging of the S32G274 1.When booting the M7 APP in bootloader, the clock initialization will not be kept in the M7 APP, it is just that I am debugging the PFE MAC now, and it is going to be removed in the end. 2.The .c and .h files of serdes configurations in the bootloader are copied directly from the app. 3.I have observed the same reference clock in the M7 APP through debugging the bootloader and M7 APP to observe the reference clock of serdes is the same Re: Problems with the PFE MAC debugging of the S32G274 Hi ,sdx111
Thank you for the detailed information, I understand your needs.
1. Is there a need for you to keep the clock initialization in the M7 application when the bootloader starts the M7 application?
2. Please check whether the configuration of serdes in the bootloader is exactly the same as the configuration in the M7 app before porting.
3. Between the bootloder and the M7 application, check that the Serdes reference clock is consistent.
BR
Joey. Re: Problems with the PFE MAC debugging of the S32G274 It's based on the recommendation that I put the clock and pin initialization of all peripherals into the bootloader already, and now only the PFE MAC doesn't work properly. If I change back to putting the initialization back into the app, I'm not sure if I'll get any other new problems. So I am trying to put the serdes initialization into the bootloader to make sure the PFE MAC still works, and now the phenomenon is not working properly, and want to find the cause and deal with it, which is the purpose of this thread I brought up. Re: Problems with the PFE MAC debugging of the S32G274 1. I debugged the PFE MAC all by booting the M7 separately, I didn't want to try to keep the serdes initialization in the M7 application, what I wanted to solve is why it doesn't work after moving the serdes initialization to the bootloader. Re: Problems with the PFE MAC debugging of the S32G274 Hi, sdx111
1. You can try bootloder to boot the M7 separately to rule out potential conflicts, as the recommendation is to implement clock and pin initialization in the bootloader for easy resource management, if you try to keep the initialization content in the M7 application, make sure that no conflict exists.
2. if the dual-core is activated, it will affect the A core as well
>>>The A-nucleus conflict is then preliminarily ruled out.
BR
Joey. Re: Problems with the PFE MAC debugging of the S32G274 Ran only M-core programs Re: Problems with the PFE MAC debugging of the S32G274 hi，sdx111
After initializing the serdes in the APP, and then performing the clock initialization, normal communication can be achieved.
>>>这个测试您使用的是bootloader启动的M核，还是只跑了M核程序呢？
BR
Joey Re: Problems with the PFE MAC debugging of the S32G274 After initializing the serdes in the APP, and then performing the clock initialization, normal communication can be achieved. However, in this case, if the dual-core is activated, it will affect the A core as well. Re: Problems with the PFE MAC debugging of the S32G274 hi，sdx111
Thank you for your reply.
1.After SerDes is initialized, MUX for SerDes clocks provided to PFE/GMAC has to be changed again. Because when the MUX switches the source clock, the source clock must be ready, which is the hardware limitation.
2.If you still have the clock initial in the M7 application when you use the bootloader to boot M 7 core. Could you have a test to put Serdes initial in M7 app for using the bootloader to boot?
BR
Joey Re: Problems with the PFE MAC debugging of the S32G274 I performed the clock initialization in the M7 core. After the serdes initialization, I also included the clock initialization. From the screenshot of the bootloader above, the function is SysDal_McuPlatformInitSeq(); It included the initialization of the clock, but it still didn't work. Also, I would like to know why a second clock initialization is required after the serdes is initialized? Re: Problems with the PFE MAC debugging of the S32G274 hi,sdx111
Thank you for your reply.
Do you have the clock initial in the M7 application?
After you initialed the Serdes, you should consider do the second the clock initial in the bootloader.
BR
Joey Re: Problems with the PFE MAC debugging of the S32G274 1.PFE version: 1.2.0, RTD version: 4.0.2, bootloader: 4.0.0 2.Our M7 kernel application program was developed based on the PFE lwip demonstration program and was debugged on our development board. It includes LLCE, but LLCE is for CAN. 3.Yes, currently I'm only debugging the M7. Re: Problems with the PFE MAC debugging of the S32G274 hi,sdx111
Thank you for contacting us.
Could you share more information with me?
1.What is the version of PFE/RTD/bootloader are you using?
2.What is your M7 application? is it the LLCE demo application?
3.when I put the serdes initialization in the bootloader and remove the serdes initialization from the APP, and start the M core alone, the PFEMAC stops working properly.
>>>Do you only use the bootloader to boot the M7 for the Serdes testing? not have the A core using?
BR
Joey
Re: Problems with the PFE MAC debugging of the S32G274 1. After initializing the SerDes, the SerDes clock MUX provided to the PFE/GMAC must be changed again because the source clock must be ready when the MUX switches the source clock, which is a hardware limitation. As mentioned here, the SerDes clock MUX supplied to the PFE/GMAC must be changed again, can you tell me in detail what registers are included? Re: Problems with the PFE MAC debugging of the S32G274 hi ,sdx111
Thank you for your response!
I will help you test it on my end and also discuss your issue with internal experts and will get back to you as soon as I have the results!
BR
Joey.
View full article
