MCUXpresso peripherals config tool: mis-match FLEXCAN callback generated prototype and driver code

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

MCUXpresso peripherals config tool: mis-match FLEXCAN callback generated prototype and driver code

1,643 Views
jeff_rosen
Contributor II

I seem to have hit a bug in the Peripherals config tool.  When I try and use the tool configure and initialize the FLEXCAN module using "Transfer" mode and if I select "Initialization of transfer callback" and enter the Transfer function callback name of "flexcanCallback", the tool creates the following prototype in peripherals.h:

/***********************************************************************************************************************
    * Callback functions
    **********************************************************************************************************************/
    /* FlexCAN transfer callback function for the FlexCAN_1 component (init. function BOARD_InitPeripherals)*/
    extern void flexcanCallback(CAN_Type *, flexcan_handle_t *, status_t , void *);

but in fsl_flexcan.c the driver's call is as follows:

/* Calling Callback Function if has one. */
    if (handle->callback != NULL)
    {
        handle->callback(base, handle, status, result, handle->userData);
    }

Notice that the prototype has 4 parameters, but the actual call has 5 arguments.  I manually edited peripherals.h to add uint32_t parameter between the status_t and void* (4th position).  Then my code compiles and runs fine.

The KSDK shows up in MCUXpresso as version 2.4.2 and manifest version 3.3.0.  MCUXpresso is version 10.2.1_795.

Is this a bug, or have I failed to keep MCUXpresso in sync with my installed SDK?  What should I be doing to avoid this type of situation?

0 Kudos
9 Replies

1,371 Views
Lukas_Heczko
NXP Employee
NXP Employee

Hi Jeffrey,

Attached you can find patch with hot fix of the issue. To apply the patch, please copy the content of the archive into the tool's data folder:

  • Windows: c:\ProgramData\NXP\mcu_data_v5
  • Linux/Mac: /home/<USER>/.nxp/mcu_data_v5

 

This issue will be fixed in the next MCUXpresso Configuration Tools release.

 

Thank you for reporting this issue and we are sorry for the inconvenience!

 

Regards,

Lukas

0 Kudos

1,372 Views
marek_neuzil
NXP Employee
NXP Employee

Hello,

Thank you for reporting of this issue. I have logged a new ticket (MCUCM-4823) that reports the problem.

We will fix the issue.

Best Regards,

Marek Neuzil

0 Kudos

1,372 Views
krzysztofglinie
Contributor I

I seem to have same problem using MCUXpresso 10.3.0_2200 with SDK 2.5.0 manifest version 3.4.0. Additionaly when i'm using FLEXCAN_TransferSendNonBlocking method it seem that program stucks in callback function what couses microcontroler reset(I use wdt). When i'm using FLEXCAN_TransferSendBlocking everything works fine. I use bootloader via UART and compile/link code with 0x0000C000 offset. Any suggestions?

#define EXAMPLE_CAN CAN0
#define EXAMPLE_CAN_CLKSRC kCLOCK_BusClk
#define EXAMPLE_CAN_CLK_FREQ CLOCK_GetFreq(kCLOCK_BusClk)

flexcan_handle_t flexcanHandle;
flexcan_mb_transfer_t txXfer;

flexcan_frame_t txFrame;

flexcan_config_t flexcanConfig;

#define TX_MESSAGE_BUFFER_NUM (9)

uint8_t CAN0_TxBufferData[8];

volatile bool txComplete = false;
volatile bool rxComplete = false;

FLEXCAN_GetDefaultConfig(&flexcanConfig);

flexcanConfig.clkSrc = kFLEXCAN_ClkSrcPeri;

flexcanConfig.enableLoopBack = false;
flexcanConfig.baudRate = 100000U; //100kB/s
FLEXCAN_Init(EXAMPLE_CAN, &flexcanConfig, EXAMPLE_CAN_CLK_FREQ);

FLEXCAN_SetTxMbConfig(EXAMPLE_CAN, TX_MESSAGE_BUFFER_NUM, true);

FLEXCAN_TransferCreateHandle(EXAMPLE_CAN, &flexcanHandle, flexcan_callback, NULL);

txFrame.format = kFLEXCAN_FrameFormatStandard;
txFrame.type = kFLEXCAN_FrameTypeData;
txFrame.id = FLEXCAN_ID_STD(0x202);
txFrame.length = 8;

for(int i=0; i<8; i++)CAN0_TxBufferData[i] += i;

txFrame.dataWord0 = CAN_WORD0_DATA_BYTE_0(CAN0_TxBufferData[0]) | CAN_WORD0_DATA_BYTE_1(CAN0_TxBufferData[1]) | CAN_WORD0_DATA_BYTE_2(CAN0_TxBufferData[2]) |
CAN_WORD0_DATA_BYTE_3(CAN0_TxBufferData[3]);
txFrame.dataWord1 = CAN_WORD1_DATA_BYTE_4(CAN0_TxBufferData[4]) | CAN_WORD1_DATA_BYTE_5(CAN0_TxBufferData[5]) | CAN_WORD1_DATA_BYTE_6(CAN0_TxBufferData[6]) |
CAN_WORD1_DATA_BYTE_7(CAN0_TxBufferData[7]);

txXfer.frame = &txFrame;

FLEXCAN_TransferSendNonBlocking(EXAMPLE_CAN, &flexcanHandle, &txXfer);

//callback function

void flexcan_callback(CAN_Type *base, flexcan_handle_t *handle, status_t status, uint32_t result, void *userData)
{

switch (status)
{
// Process FlexCAN Rx event.
case kStatus_FLEXCAN_RxIdle:
      if (RX_MESSAGE_BUFFER_NUM == result)
      {
         rxComplete = true;
      }

      break;

// Process FlexCAN Tx event.
case kStatus_FLEXCAN_TxIdle:
      if (TX_MESSAGE_BUFFER_NUM == result)
      {
         txComplete = true;
         }
      break;

default:
break;

}


}

 

0 Kudos

1,372 Views
jingpan
NXP TechSupport
NXP TechSupport

Yes, they are same problem.

0 Kudos

1,372 Views
krzysztofglinie
Contributor I

So, does it mean that callback function for FLEXCAN_TransferSendNonBlocking should work or not in mentioned software configuration (MCUXpresso 10.3.0_2200 with SDK 2.5.0)?

0 Kudos

1,372 Views
jingpan
NXP TechSupport
NXP TechSupport

Which chip do you use?

0 Kudos

1,372 Views
jeff_rosen
Contributor II

In my case: MK64FX512VMD12

0 Kudos

1,372 Views
krzysztofglinie
Contributor I

MK64FN1M0VLL12

0 Kudos

1,372 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi Jeffery,

Yes, I agree with you. It's a bug. I'll report it.

Thank you very much!

Regards,

Jing

0 Kudos