Background:
We want to achieve the communication between MPC5746R(252Pins) and MPC5744P(257Pins) using Zipwire on our hardware, but the communication doesn't work well as we expected.
Hardware Configuration:
The power configuration of MPC5746R and MPC5744P and the LFAST connection between them are showed in Table1 and Fig.1 respectively. We use MPC5746R and MPC5744P as zipwire master and zipwire slave respectively.
Table1. The power configuration of MPC5746R and MPC5744P
Power Configuration | |||
MPC5746R | MPC5744P | ||
Pin | Power | Pin | Power |
VDD_LV | 1.25V | VDD_LV_CORE | 1.25V |
VDD_HV_IO_JTAG | 3.3V | VDD_LV_PLL | |
VDD_HV_IO_FEC | VDD_HV_FLA0 | ||
VDD_HV_IO_MSC | 5V | VDD_LV_LFAST | |
VDD_HV_PMC | VDD_LV_NEXUS | ||
VDD_HV_ADV_SD | VDD_HV_PMU | 3.3V | |
VDD_HV_ADV_SAR | VDD_HV_OSC0 | ||
VDD_HV_IO_MAIN | VDD_HV_IO | ||
|
| VDD_HV_ADV0/1 | |
|
| VDD_HV_ADR0 | 5V |
|
| VDD_HV_ADR1 | |
Fig. 1. The LFAST connection between MPC5746R and MPC5744P
Process:
The debugging process is as follows:
1.Software migration
We only find two examples about Zipwire called "zipwire_master_mpc5746r" and "zipwire_slave_mpc5746r" which are offered by S32 Design Studio. Hence, the example "zipwire_slave_mpc5746r" should be migrated into MPC5744P, the detailed migration process is as follows:
a) Import a new example “hello_world_mpc5744p” in S32 Design Studio (Fig.2) and add some new components (edma, interrupt_manager, clock_manager and osif, zipwire not available for MPC5744P) using SDK exactly as "zipwire_slave_mpc5746r"(Fig.3) .
Fig. 2. “hello_world_mpc5744p” example in S32 Design Studio
Fig. 3. "hello_world_mpc5744p" components (Left) and "zipwire_slave_mpc5746r" components (Right)
b) Configure the five LFAST pins and enable the LFAST0_CLK and SIPI0_CLK using SDK, then generate processor expert code.
(a)
(b)
Fig. 4. The configuration of five LFAST pins (TX and RX in (a) and CLK in (b))
c) Copy all documents about zipwire (Fig.5) and mian.c from "zipwire_slave_mpc5746r" project into “hello_world_mpc5744p” project.
Fig. 5. The copied documents about zipwire from "zipwire_slave_mpc5746r" project
d) Correct all errors after building the modified “hello_world_mpc5744p” and modify the expression of SIPI register and some interrupt vectors about SIPI, such as replacing "SIPI" with "SIPI_0", "SIPI0_IRQn" with "SIPI_Read_1_IRQn", "SIPI1_IRQn" with "SIPI_Read_2_IRQn", etc.
2.We use the example "zipwire_master_mpc5746r" as zipwire master program and download it into MPC5746R without any modification. As the programs show, in the stage of LFAST initialization of MPC5746R, the ICLC frame can be sent successfully. There is an ICLC frame with the payload 0x31, which is captured by our oscilloscope, in Fig. 5.
Fig. 5. An ICLC frame with the payload 0x31(the differential voltage between TXP and GND in Channel 1, the differential voltage between TXN and GND in Channel 2)
3.We use the modified example "hello_world_mpc5744p" as zipwire slave program and download it into MPC5744P, then check the waveform of LFAST reference clock sent by MPC5744P. As Fig.6 shows, the frequency of the clock, which is set as 20MHz, looks normal, but the voltage amplitude of the clock signal isn’t what we expected. The voltage range of the clock signal is from 1V to 3.3V.
Fig. 6. The waveform of LFAST reference clock
4.We connect MPC5746R with MPC5744P and check the running condition of two programs. Unfortunately, the zipwire slave program in MPC5744P stops when waiting for TXEN bit to set through ICLC frame from master. In order to make sure slave has every chance to set this bit, we modify the zipwire master program in MPC5746R to make the ICLC frame with the payload 0x31 be sent continuously every 10us without collision, but the zipwire slave program still stops in the same place.
Fig. 7. The description of TXEN bit of LFAST_MCR register
Pre-analysis:
According to the phenomenon in the debugging process, we perform the following analysis:
1.According to our power configuration (Table 1), we find that the IO power supply of two MCUs, namely VDD_HV_IO_MAIN in MPC5746R and VDD_HV_IO in MPC5744P, is different. It means that that the 3.3V high- level voltage sent by MPC5744P may not be judged as high-level by MPC5746R. We wonder if this power configuration affects the normal SIPI communication.
2.As the above phenomenon shows, the voltage amplitude of the clock signal looks abnormal, we suspect that the lowest voltage is around 0V. And we want to know whether it leads to the failed communication.
Up to now, we only find the two possible reasons and don’t know whether the communication can be achieved after solving them. It will be appreciated if someone can give us some suggestions about what should be checked next and how to deal with this problem.
