S32K148 LIN Slave with Real Time Driver

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K148 LIN Slave with Real Time Driver

1,152 Views
christofhaiding
Contributor IV

Hi!

I am using the S32K148 EVB with LIN and the RTD Driver.

I am not using the AUTOSAR function but the LPUART_LIN Lib.

I looked into the Lin_lp_FrameTransfer_S32K148 example and managed to port the basic (sending/receiving) functions to my project for the slave mode, using a RX/TX callback.

But now i have several problems:

1. After receiving a single frame the state doesn't leave the state "LPUART_LIN_IP_STATUS_RX_OK"

   Is this supposed to be this way? If yes how do i determine if i read all the data?

2. When i receive a frame, I can currently see no way how to determine which ID this frame has.

    How can i identify the frame ID?

3. I copied the source from the example, and it seems the pdu size is limited to a PDU size of 3 Bytes.

    Because everytime I sent a frame with a different size (e.g. 8 bytes) I get some errors (mostly checksum errors). Is there a way to make this more flexible for different frame sizes?

4. If I try an read from the master (sending only the ID) I can see no differenze to a write from the master, how can I differentiate between a Master Read and write?

5. The older SDK (SDK 4.0.2) used a ".ldf" (LIN description file) to manage all the used IDs on the LIN Bus, is this with the Real Time drivers also possible, or do I have to setup up this IDs hardcoded?

Best regards

Christof

 

Tags (3)
0 Kudos
5 Replies

1,113 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

please see below a feedback I got from SW RTD team...

BR, Petr

===========================================

First of all, I assumed that the release he is using is RTD_4.4_S32K1XX_1.0.0.

Based on that my reply is the following on each point:
1. The Lpuart_Lin_Ip_GetStatus returns the status for the previous transfer so it is supposed to return LPUART_LIN_IP_STATUS_RX_OK until a new transfer is started.

The second parameter can be used to retrieve the data buffer received. As it is a pointer  to the driver internal buffer, the data will be lost when a new

transfer is triggered.

                "If yes how do i determine if i read all the data?" -> Before a new transfer starts, you can use the number of bytes to copy the data in your

desired memory location in a loop, as it will be lost if a new transfer begins. The time space between two frames should be

5 to 10 ms as per lin standard if I am now wrong, so it should be enough to copy/read up to 8 bytes.

2. In the user callback (Lpuart_Lin_Ip_CallbackType) there is a parameter Lpuart_Lin_Ip_StateStructType *LpuartStateStruct. The structure description is missing in the RTD LIN User Manual because it is an internal driver structure, but

I can see a necessity in describing its members that might be useful for the user who defines his callback in an application.

So, this structure has the following important members.

   uint8 CurrentPid; /**< @brief Current PID */

   volatile Lpuart_Lin_Ip_EventIdType CurrentEventId;/**< @brief Current ID Event */

The user can interrogate the CurrentEventId member and checks if its value is LPUART_LIN_IP_RECV_HEADER_OK. This means that the header has successfully been received from the Master Node and therefore the PID byte has already been stored to CurrentPid structure member.

In order to retrieve the ID from PID, you can use a mask 0x3F.

3.The answer is YES. The user can change the macro BUFFER_SIZE value to any number of bytes from 1 to 8.

This macro is used in the structure Lpuart_Lin_Ip_PduType LpuartPduInfo which is the parameter for  Lpuart_Lin_Ip_SendFrame.

This structure contains the following members:

typedef struct
{

    uint8                               Pid;     /**< @brief LIN frame identifier.*/
    Lpuart_Lin_Ip_FrameCsModelType      Cs;      /**< @brief Checksum model type.*/
    Lpuart_Lin_Ip_FrameResponseType     Drc;     /**< @brief Response type.*/

    uint8                               Dl;      /**< @brief Data length.*/

    uint8*                              SduPtr;  /**< @brief Pointer to Sdu.*/

} Lpuart_Lin_Ip_PduType;

The number of bytes in the lin frame can be configured in the application via the Dl field and can be set to any value supported by the Lin Protocol.

4. I am sorry but I don't understand the usecase and the question. I need more information about what "master read/write" means and what does it mean that the master is sending only the ID.

Master must send an entire header (break byte, sync byte, pid) as per Lin Standard. If you can answer this questions, please let me know and I will provide more information.

5. Currently, we don't have support for LDF files on RTD LIN driver so the IDs for the Lin frames must be defined inside the application.

0 Kudos

1,106 Views
christofhaiding
Contributor IV

Hi Petr!

Thx for the reply.

Most of the things i discovered by my self.

The key is setting the PDU inside the callback right.

For example if the ID contains data which should be written to the master the PDU must be configured that way:

uint8 SduBuf1[3U];
LinPdu.Cs = LPUART_LIN_IP_ENHANCED_CS;
LinPdu.Pid = LpuartStateStruct->CurrentPid;
LinPdu.Drc = LPUART_LIN_IP_FRAMERESPONSE_RX;
LinPdu.SduPtr = &SduBuf1[0u];
LinPdu.Dl = 3;

If the ID contains data which must be sent back to the master, the PDU must be configured that way:

LinPdu.Cs = LPUART_LIN_IP_ENHANCED_CS;
LinPdu.Pid = LpuartStateStruct->CurrentPid;
LinPdu.Drc = LPUART_LIN_IP_FRAMERESPONSE_TX;
LinPdu.SduPtr = &response[0u];
LinPdu.Dl = 2;

With this PDU configuration the function "Lpuart_Lin_Ip_SendFrame" decides wether to relay the data inside the system or to return data back to the master (at least it does it in my code).

But I have one more question.

After receiving data one time the function Lpuart_Lin_Ip_GetStatus does alway return the state LPUART_LIN_IP_STATUS_RX_OK, even after processing the received data.

I solved this by setting a variable inside the callback when getting the eventid LPUART_LIN_IP_RX_COMPLETED and reseting the variable in my cyclic programm after processing the data.

Is there another way to do this?

Regards Christof

0 Kudos

1,086 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

forwarding a feedback...

BR, Petr

Lpuart_Lin_Ip_GetStatus returns the status of the last transfer. The only way to change its return value is to trigger a new transfer. What is the customer expecting to be the return value after data is processed?

Can he provide more details about why is there needed to change the return value?

Maybe a code snippet of his “fix with setting a variable inside the callback” could be useful. I am trying to understand if our getstatus function needs improvement or not.

Is he interested in getting the NODE state(meaning that the node is in sleep,idle, sending,receinving mode which cannot be retrieved via get status)  or the status of operation?

0 Kudos

1,082 Views
christofhaiding
Contributor IV

Hi Petr!

My fix is like this:

Inside the callback:

if(LpuartStateStruct->CurrentEventId == LPUART_LIN_IP_RX_COMPLETED)
{
receiveDone =1;
}

Inside my cyclic function:

if(receiveDone == 1)
{
       receiveDone = 0;

        LpuartSlaveStatus =          Lpuart_Lin_Ip_GetStatus(Lpuart_Lin_Ip_pHwConfigPB_0_BOARD_INITPERIPHERALS.Instance, (uint8 **)&bufferpointer);
        if(LPUART_LIN_IP_STATUS_RX_OK == LpuartSlaveStatus)
       {

....

Where the variable "receiveDone" is a global variable.

I was not aware the Lpuart_Lin_Ip_GetStatus is always returning the state of the latest transfer.

The example (Lin_Ip_FrameTransfer_S32k148) is only looking for the state LPUART_LIN_IP_STATUS_RX_OK reaching once and than exiting the whole programm.

This was a little confusing.

My, really personal, assumption would haven been, that Lpuart_Lin_Ip_GetStatus would also return some kind of Idle state if the receiving was don one time and there are no data present at the moment.

But if i can get that also with the node state it's ok for me.

The only quote I have to make is that the documentation should be a little bit more detailed about this data flow.

 

 

0 Kudos

1,081 Views
christofhaiding
Contributor IV

Regards

Christof

0 Kudos