Problem on KDS with CAN_LDD driver code for FlexCAN

[Vagni]

I ported my K60-based application from CW 10.4 + MQX 4.0.2 to KDS 1.1.1 + MQX 4.1.1.

My BSP is based on PEx and my application uses both FlexCAN channels. For each of them I use a CAN_LDD driver.

But my test code on both CAN channels does not work any more.

The generated CAN_LDD driver code differs from my previous I got with CW 10.4 essentially on the SendFrame function (the FlexCAN peripheral is initialized in the same mode).

I attach my test code and the ProcessorExpert project of my BSP.

On my board one CAN channel port is connected with the other CAN channel port and my code does the following:

1. Init CAN_LDD driver on both channels in the same mode.
2. Send a packet from the first CAN port and, after 300 msec, check its reception on the second CAN port.
3. Send a packet from the second CAN port and, after 300 msec, check its reception on the first CAN port.

With my firmware compiled with CodeWarrior 10.4 and MQX 4.0.2 the test result is ok (so my hardware is good).

The test fails with my new firmware compiled with KDS 1.1.1 and MQX 4.1.1.

Some notes:

• All the other function of my KDS firmware are working properly (GPIO, UART, ADC, SPI, I2C, etc.) as with my CW firmware. So I can say my BSP library is good.
• I tried to incremet up to 2 sec the reception waiting time, but this does not fix the issue.
• All the CAN_LDD driver functions return without errors (except when ReadFrame function returns ERR_RXEMPTY).
• With my scope I see that no packet is output from both the CAN channels when I call the SendFrame function.
• My test passes only if I execute my application with the debugger and with a breakpoint set at the following line of the SendFrame function (in both drivers):

CAN_PDD_SetMessageBufferCode(CAN1_BASE_PTR, BufferIdx, TxMBCode); /* Set code for Tx buffer of the message */

This is very strange: how can the debugger breakpoint unblock the frame transmission on the CAN driver?

Can you help me to fix this issue?

Best Regards,

Alessandro

Original Attachment has been moved to: TestCAN.zip

[carlos_chavez]

Hey Alessandro,

Sorry for the the repetition, but I want to be absolutely clear on the observed behavior.  When you state the following:

    "Then I tried my new test with the CAN_Disable - CAN_Enable cycle with the same modified CAN_LDD generated code above: FAILED."

Do you mean?

  * Then I tried my new test with the CAN_Disable - CAN_Enable cycle with the same modified CAN_LDD generated code above (with StatusReg reading): FAILED.

or

* Then I tried my new test with the CAN_Disable - CAN_Enable cycle with the same modified CAN_LDD generated code above (without StatusReg reading): FAILED.

Regards,

Carlos

[Vagni]

Carlos,

I mean:

Then I tried my new test with the CAN_Disable - CAN_Enable cycle with the same modified CAN_LDD generated code above (with StatusReg reading): FAILED.

Regards,

Alessandro

[carlos_chavez]

Hi Alessandro,

Happy New Year to you!  I thought that this response had gone out prior to the Christmas Break.

I communicated with someone on our Processor Expert Team and they created a new project in KDS 2.0.0 (Test FlexCan on MK60N512LL100) without MQX based on the TestCAN.zip files and verified the functionality of the FlexCAN driver – it works properly on TWR-K60N512 target board with TWS-SER board and one external high-speed CAN transceiver.  They also have added MQXLite into this project and updated the code (the TestCAN_1_2() routine called from an mqx task; the _time_delay is replaced by _time_delay_ticks() method of mqxlite), which also works properly, so they are not able to reproduce the problem.

So the theory here is that  there might be an issue with the application that didn't present itself in the original driver but shows itself in the new version with the appropriate required updates for handling critical code, etc.  For example, it may be an interrupt vector priorities issue or an error in the application. The whole application must be analyzed on target device to find the root cause.  It may be that there still might be an issue in the FlexCAN driver itself, but it can only be reproduced in this special case.

If you can reproduce this on a TWR system, we would be more than happy to help.

Best Regards,

Carlos

[carlos_chavez]

Hello Again Alessandro,

Thanks for the update.  I did hear back from our CAN Expert.  They recommended some general updates to the CANBUS_Init task to help prevent many issues difficult to debug in the future.  I will pass those on to the PEx Team.  However, I know that your code works with the code generated from the CW 10.4 PEx.  They also agreed with me in that any reading on Control/Status word from MB may unlock it, so it was good to try.  If CPU was treating a reception frame, the transmission task cannot read/write on the same MB before clearing the IFLAG due to RX frame.  However, that did not work, so we will have to continue our debug effort.

In regards to your comment, "With the modified CAN_LDD generated code my CAN test also fails after re-inserting my CAN_Disable - CAN_Enable cycle in my source code.  Very strange indeed: It seems like my CAN test works different if I add or delete some code...", do you mean that once you remove the 'StatusReg read' from the SendFrame function that your test will no longer work when you re-insert the CAN_Disable and CAN_enable back into your code?

Thanks for the reference to thread: https://community.freescale.com/message/394093#394093.  I was not aware of this.  Let me work with our PEx Team to figure out a solution for this.

Thank you for your patience,

Carlos

[Vagni]

Hi Carlos,

First I inserted the "StatusReg reading" in the CAN_LDD generated code (by PEx in KDS) and I tried my original test: FAILED.

Then I tried my new test with the CAN_Disable - CAN_Enable cycle with the same modified CAN_LDD generated code above: FAILED.

At this time, only my new test with the CAN_Disable - CAN_Enable cycle passes with the unchanged CAN_LDD generated code.

Best Regards,

Alessandro

[carlos_chavez]

Hi Alessandro,

Just following up to see if you had any results from the suggestion that Pascal made.

Have a great weekend!

Best Regards,

Carlos

[Vagni]

Hi Carlos,

Hi Pascal,

I installed CW 10.6 Evaluation for Kinetis MCU to build my application CA_TB6 with MQX 4.1.1.

The PEx project for my BSP library is the same I used with KDS 1.1.1.

I have successfully built all my MQX libraries with the CW 10.6 GCC C Compiler.

Building my application in Debug configuration outputs the following error stopping the build process:

Errors occurred during the build.

Errors running builder 'CDT Builder' on project 'CA_TB6'.

java.lang.NullPointerException

Why I get that error? What is java.lang.NullPointerException?

So, I cannot use the CW debugger.

Building my application in Release configuration is successful, instead. So I can flash the ELF file into my board and test it.

But I get the same situation as with KDS executable ELF file: all of my board functions work properly, except with my CAN test, that fails also with CW 10.6 GCC C Compiler.

So I think my issue reside on my BSP created with the same PEx project file.

But where?

Best Regards,

Alessandro

[Vagni]

I found that my CAN test is successful with KDS only if I make one CAN_Disable – CAN_Enable cycle immediately after CAN_Init on both the PEx CAN_LDD drivers.

I attached my new version of may CAN test source code.

That is very strange, because both the PEx CAN_LDD drivers have the “Enabled in init. Code” property set to YES (as in my original project with CW 10.4 + MQX 4.0.2).

The CAN_Disable – CAN_Enable cycle seems to put all the things to work properly ... Why?

Best Regards,

Alessandro

[carlos_chavez]

Hello Again Alessandro,

Can you please confirm with me whether you used the version of Processor Expert integrated with CW 10.4 or the Standalone version of Processor Expert initially?

Thanks,
Carlos

[Vagni]

Hello Carlos,

I have always been using Processor Expert integrated with the Development Suite (Code Warrior or KDS).

In my BSP porting from CW 10.4 + MQX 4.0.2 to KDS 1.1.1 + MQX 4.1.1 I cloned for my board the MQX 4.1.1 bsp_twrk60n512, generating CW and KDS projects. Then I enabled Processor Expert for the KDS project of the BSP library (in MQX 4.1.1 the BSP KDS projects of all the Tower evaluation boards are not based on a PEx project like the corresponding CW projects). Finally I replaced the ProcessorExpert.pe project file with my original ProcessorExpert.pe project file used with CW 10.4 + MQX 4.0.2, paying attention to select "GNU C Compiler" in the CPU component "Build Option Compiler".

Best Regards,

Alessandro

[carlos_chavez]

Hi Alessandro,

From your earlier mention that the only difference that you observed between the drivers was in the SendFrame.  When I looked at the two generated files, the difference was that the PEx with CW had the following while PEx with KDS did not:

  if ((StatusReg & (CAN_PDD_RECEIVING_MESSAGE | CAN_PDD_TRANSMITTING_MESSAGE)) != 0x00U) { /* Are both IDLE and TX/RX bits of the status register cleared?*/

    return ERR_BUSY;                  /* If yes then error */

  }

This is reading the CAN Interrupt Flags.  Have you tried to implement this in the PEx with KDS generated code as seen in the attachment?  I believe that this may be blocking the Message Buffer.  Please let me know.

I am still awaiting a response from our CAN Expert.

Best Regards,

Carlos

[Vagni]

Hi Carlos,

I worked on my KDS project.

I manually inserted the StatusReg reading into the SendFrame function of the CAN_LDD generated code and deleted my CAN_Disable - CAN_Enable cycle from my source code, but my CAN test fails like with the original CAN_LDD generated code.

With the modified CAN_LDD generated code my CAN test also fails after re-inserting my CAN_Disable - CAN_Enable cycle in my source code.

Very strange indeed: It seems like my CAN test works different if I add or delete some code...

Any news from your CAN Expert?

Best Regards,

Alessandro

[Vagni]

Hi Carlos,

CW 10.4 is based on Processor Expert 10.2 [05.07] and the CAN_LDD code is generated with StatusReg reading.

CW 10.6 is based on Processor Expert 10.3 [05.09] and KDS 1.1.1 is based on Processor Expert 10.4 [05.10]. Both of them generate the CAN_LDD code without StatusReg reading. The new version of CAN_LDD generated code is explained in this thread: Problem with generated CAN_LDD driver code for FlexCAN .

Before manually changing my CAN_LDD generated code, I tried to ask for support on my issue (also in that thread). Now I'm going to make the change and test it. I will tell you my test result.

Best Regards,

Alessandro

[carlos_chavez]

Hi Alessandro,

So sorry for the delay, as I was out on holiday.

Thank you for this additional information.  This is really odd.  This seems to point to something getting generated slightly differently for KDS.  The CAN_Disable seems to set the module back to a default state.

I am working with one of our CAN experts to determine what is taking place.  I will have more information for you this week.

Best Regards,

Carlos

[Vagni]

Hi Carlos,

Right now I cannot compile my application with CW 10.6, because my CW license expired and my application code size is greater then 128 KB.

I should try to make another application with only my CAN test...

What I don't understand is why my test passes if I execute my application with the debugger and with a breakpoint set at the following line of the SendFrame function (in both CAN_LDD drivers):

CAN_PDD_SetMessageBufferCode(CAN1_BASE_PTR, BufferIdx, TxMBCode); /* Set code for Tx buffer of the message */

What can happen when the breakpoint stops the execution on that function call?

Maybe with that breakpoint the CAN interrupts are unblocked?

By the way, how can I explore the Kinetis peripherals registers in KDS debugger? I can only see the MCU registers...

Best Regards,

Alessandro

[trytohelp]

Hi Alessandro,

It's difficult to quickly define what/where the problem is.

I would suggest you to see if the MCU V10.6 + MQX V4.1.1 is working or not before to switch directly to KDS.

Moving your working project (MCU V10.4 + MQX V4.0.2) to an intermediate solution based on MCU V10.6 + MQX V4.1.1 will be helpful to determine what is the problem.

As the MQX V4.1.1 is used by KDS too the impact of moving will be "reduced".

There are docs explaining how to move a project from MCU V10.6 to KDS.

      Importing MCU V10.6 projects (sample, using PE and MQX) under KDS

Have a great day,
Pascal Irrle

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[carlos_chavez]

Hi Alessandro,

Sorry for the delay, but Pascal is correct.  Please let us know if your project works with MCU V10.6 + MQX V4.1.1.  This will give us a better idea to determine where the problem lies.

Best Regards,

Carlos