MSPM0G3507: LIN communication is disconnected midway.

Hi Donguk,

Can you check if the UART peripheral has data in its RX buffer? (assuming you're sending here)

Considering you do get the completed packet with your 35h, I don't think you're filling the next data. I believe you're in  some other spot in code. I also suggest placing a breakpoint where you're sending the data to see if the function is getting called after you activate the motor.

Regards,
Luke

Looking at the logs in PLIN communication, it seems that a checksum error has occurred. Can you tell me what the cause is and how to solve it? When I change the communication line, RX/TX data comes in without any problems.

Hi Donguk,

Can you expand further on the "when i change the communication line, RX/TX data comes in without any problems" are you only changing the pins? or are you changing something else in the process?

For a checksum error, it is a way to verify the whole data packet was received/transmitted properly. The checksum could be the total bits sent or some algorithm on the data set. This is to verify that your data was sent correctly, if you get a checksum error on this PLIN device I would check how its calculating the checksum and also if you're sending the checksum in your LIN communication.

Regards,
Luke

Hi Luke,

This means that the communication cable has been changed. The communication cable that was used previously did not receive data after a communication error occurred, but the Lin communication cable that was changed this time does not disconnect communication even when a communication error occurs.
Thanks to this, I was able to log the error. I will show you the error contents.

-> This is normal result

-> This is abnormal result (Error code "CK" = checksum error)

Looking at the LIN result with the checksum error, it seems that the TX result, which should be an 8-byte character, is 9 bytes (including the FF at the end). Can you tell me what the solution is for this?

Best Regards,

Donguk

Hi Donguk,

Is the bottom data what is getting transmitted from the MCU and the top data is what is getting sent from the PC? 

I believe the FF is supposed to be the checksum value. If you look at your good dataset the D2, 14, 32 etc. are in the same position and all the D2's have the same data, all 14s have the same data etc. 

Check what is getting sent from the MCU and you can verify if the checksum is incorrect (not all of those should be FF's).

It looks to me like the PID is not matching our available PIDs.

The response is coming from the sendLINResponderTXMessage() function, You can place a break point and check the values of the variables being used. 

Regards,
Luke

Hi Luke,

Yes, that's right. The data above is sent from the PC to MCU and the data below is sent from the MCU to PC.
I've attached a video to help you understand.

-> This is during normal operation.

-> This is during abnormal operation.

You can artificially create erratic behavior by leaving the applicationLowPriorityRun(g_pMC_App) function inside the 100ms timer interrupt of the C:\ti\mspm0 sdk_2_03_00_07\examples\nortos\LP MSPM0G3507\motor_control_pmsm_sensorless_foc\sensorless-foc DRV8329 example code instead of executing it every 100ms inside the while(1) of main.c.

For some reason, if you run applicationLowPriorityRun(g_pMC_App) within the timer interrupt, it will conflict with the LIN interrupt. However, even if you move applicationLowPriorityRun(g_pMC_App) to the while(1) statement, you should still resolve the checksum error that occurs intermittently while the motor is rotating.

As you can see in the video, the status of the LIN interrupt does not change when the motor enters aglin.
Could you please look at the contents of "C:\ti\mspm0_sdk_2_02_00_05\examples\nortos\LP_MSPM0G3507\lin\lin_responder"?
If you check the LIN interrupt function of the example code,

Although it is not shown in the video,

when you check DL_UART_Extend_getPendingInterrupt(LIN_0_INST) separately,

it is stuck in DL_UART_EXTEND_IIDX_RXD_POS_EDGE state,

and gStateMachine is stuck in LIN_STATE_SYNC_FIELD_NEG_EDGE state.

Please check the code and tell me why the result of DL_UART_Extend_getPendingInterrupt(LIN_0_INST) remains unchanged

I think this is a problem caused by a conflict with functions inside the interrupts (ADC, timer, lin) of the example code. Is there an example of using DMA to do LIN? I would like to see if that method solves the problem.

Best regard,

Donguk

Hi Donguk,

Thanks for the information here, it will take me some time to investigate the LIN code and attempt to replicate the scenario you listed above. Do you have the UART as highest priority? or is everything on the same priority levels.

Regards,
Luke

Hi Luke,

Timer interrupt is the highest priority and LIN, ADC use default

I put the timer interrupt above Lin's priority because the timer interrupt is interrupted by Lin.

Regrads,

Donguk

Hi Donguk,

We do have UART DMA examples uart_rx_multibyte_fifo_dma_interrupts and uart_tx_multibyte_fifo_dma_interrupts which you can use to see how the DMA connection is made.

regards,
Luke