DSPI command and data

[yuchenchen]

Hi there,

I'm working on a case to get the CAN but working on the PMSM motor control development kit for MPC5643xL with the MCToolbox. I've contacted the NXP technical support and they says that the board doesn't have a transceiver so I need to initialize the SBC chip through DSPI for MPC5643xL, with the MCToolbox. I got some example codes of using another microcontroller to initialize the SBC and the DSPI messages. The messages are in unit32 format. As far as I'm understanding, the data frame size is up to 16-bit for the MPC5643 DSPI module. But in c codes, the message should be a combination of the command bits and the data bits. So in this case, should I just take the lower 16 bits from the messages in the example and put the numbers to the DSPI transmit block to achieve the same result?

The problem is, in the 16-bit data, there is one parity bit (bit 8). So if it includes the 16-bit command 0000 0000 0000 0001, this parity bit should be 1 but should be 0 if not including the command.

So what is the equivalent way in MCToolbox to send the SPI data to configure the SBC?

Below are the sample codes I got for setting up this SBC. I also put the source codes in attachment. I got this project from the NXP support team. It's another microcontroller but the same SBC MC33905.

/* AFTER POWER UP SBC DEVICE IS IN INIT MODE */
DSPI_B.PUSHR.R = 0x0001DF80; /* read BAT FAIL */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00011D80; /* read mode */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00014C00; /* write Init W/D (simple W/D time out) */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00010D00; /* read init W/D */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00014E28; /* write init LIN */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00010F00; /* read init LIN */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00015A00; /* write normal mode */
ReadDataDSPI_B();
/* DEVICE IS IN NORMAL MODE */
DSPI_B.PUSHR.R = 0x00011D80; /* read device mode */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00015A00; /* W/D refresh */
ReadDataDSPI_B();
/* CONFIGURATION OF CAN/LIN */
DSPI_B.PUSHR.R = 0x000160C0; /* write CAN */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00012100; /* read CAN */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x000166C0; /* write LIN1 */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00012700; /* read LIN1 */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x000168C0; /* write LIN1 */
ReadDataDSPI_B();
DSPI_B.PUSHR.R = 0x00012900; /* read LIN1 */
ReadDataDSPI_B();

Original Attachment has been moved to: Example-TRK_MPC5634M-FlexCAN-SimpleTX-CW29.zip

[john_floros]

Attached is the output from the model code generation.

[john_floros · Accepted solution]

I was able to get the model to work on my hardware.  Please see attached model.  Please note that it is building for RAM so if you like you can change it to FLASH.

Also, I did noticed that I my board the termination resistors for can are enabled by shorting the pins on JP100 and JP101 which are close to the CAN connector J102.  These would be in addition to the pins on J2.  Please see attached picture.

Below is the messages that you should expect once you are running.

[john_floros]

Just to be clear.  Pins 2 and 4 need to be shorted and pins 1 and 3 need to be shorted on J2.

[john_floros]

Yuchen,

To initialize the SBC for CAN should only require the following commands:

[yuchenchen]

This figure shows my current integration, from top layer to bottom. Since I don't have Stateflow, I use switch case to integrate the state machine.

I have the terminate JP100 and JP101 closed, J2 pin 2 and pin 4 closed.

I manually changed the values of registers from 0x0624 and 0x0100 0x0627 and 0x0103 for CAN 0 as shown below. 

void flexcan_564xl_pin_init(uint8_t flex_can)
{
switch (flex_can) {
case FLEXCAN_0:
{
SIU.PCR[16].R = 0x0627;
SIU.PCR[17].R = 0x0103;
SIU.PSMI[33].R = 0x01;
break;
}

case FLEXCAN_1:
{
SIU.PCR[14].R = 0x0624;
SIU.PCR[15].R = 0x0100;
SIU.PSMI[34].R = 0x00;
break;
}

default:
break;
}
}

CANH and CANL are still measuring constant 2.5V and 0V respectively. Pin 2 of J2 is still measuring the non-changing signals. From the response from the NXP technical support, this signal is an error signal, means the CAN transceiver is not enabled.

One question is, I'm not connecting the CANH and CANL to any other CAN devices, I'm just probing it, is this gonna cause an issue?