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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

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

1,744件の閲覧回数
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 件の賞賛
9 返答(返信)

1,472件の閲覧回数
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 件の賞賛

1,473件の閲覧回数
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 件の賞賛

1,473件の閲覧回数
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 件の賞賛

1,473件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Yes, they are same problem.

0 件の賞賛

1,473件の閲覧回数
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 件の賞賛

1,473件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Which chip do you use?

0 件の賞賛

1,473件の閲覧回数
jeff_rosen
Contributor II

In my case: MK64FX512VMD12

0 件の賞賛

1,473件の閲覧回数
krzysztofglinie
Contributor I

MK64FN1M0VLL12

0 件の賞賛

1,473件の閲覧回数
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 件の賞賛