Cannot debug generated fsl_uart code that is freezing in SendDataBlocking function

[dave408]

I've been playing with the fsl_uart component, and started with my FRDM-K64F.  Using KSDK + PEx + MQX, I was able to confirm operation of UART3 with some simple loopback test code.

Now I've moved on to the FRDM-K22F.  Also using a similar configuration with KSDK + PEx + MQX, I have not been able to get my loopback code working.  I believe the only difference is that on the K22 board, I am using UART2 (PTD2/PTD3).  The specific problem I am having is that UART_DRV_SendDataBlocking hangs because the inner call to UART_DRV_StartSendData hangs.  I am unable to step into UART_DRV_StartSendData.  My initial impression is that something is misconfigured, resulting in an invalid call (e.g. wrong memory address).

If I pause execution at random times, it seems that the code is always stuck in the idle task.

I've attached my project in case anyone at FSL or elsewhere has time to import it and try it out to confirm the behavior, and hopefully offer advice for followup debugging steps.

Thank you!

Original Attachment has been moved to: RobotAxis.zip

[DavidS]

Hi Dave,

Looking at your project, it has the wrong CPU selected for the frdm-k22f Freedom board.

Please switch CPU from Cpu:MK22FN512VDC12 (a 121-pin package) to Cpu:MK22FN512VLC12 (64-pin package).

Regards,

David

Bonus:  If you want to increase the compile speed please enable "Enable parallel build" as follows....Note this is done a a project by project basis:

[dave408]

Ugh, how did I do that?  Thanks for catching that.  I had gone through the preprocessor settings and saw that the VDC12 was selected, but didn't think to go into PEx.

That makes sense, because I just created a new project from scratch and targeted the FRDM-K22F, and it worked.  In my project notes I forgot to mark down that I had been targeting a processor in my RobotAxis project, rather than the board.  That must have been it.

Thank you for your time, David.  Sorry about posting such a dumb user error-related problem.

[DavidS]

Highlight the Cpu:MK22FN512VDC12 Processor that is enabled for your Flash build, then in the Component Inspector - click the pull-down next to CPU type and change away....

Its only simple after you find the solution.

Regards,

David

[dave408]

Hmm... I think I jumped to conclusions too soon.  I made the CPU change, and it's still doing the same thing.  Would you mind peeking at this updated project?

[DavidS · Accepted solution]

Hi Dave,

Couple things found and worked around.

First, I don't know why the Task would be called prior to all of the initialization of the system complete.  I found that if I didn't add the OSA_TimeDelay() the UART2 clock gate was not yet enabled.  So that is a "workaround".

Next the configuration of your rs485:fsl_uart had callback and interrupts enabled.  That is fine if you want to be receiving the UART2 transmitted character in the Event.c rs485_RxCallback() function.  I added a GPIO toggle of the Green LED to see that I was getting into it successfully.  But if you want the UART_DRV_ReceiveDataBlocking() call to receive the character you need to disable the UART2 callback and interrupts.

The attached updated ZIP has the polling approach working.

Last observation is you have Cpu clocking left with the default configuration so the system clock is at ~20.97MHz.  I'm guessing you may want to configure the clock for higher operation by using the FLL or PLL..

Regards,

David

[dave408]

One more set of comments, regarding the changes that David made to my UART loopback code.

My original code did *not* have a delay between UART_DRV_SendDataBlocking and UART_DRV_ReceiveDataBlocking.  David commented that I should pass NULL for the timeout instead of -1.  If I have no delay and use NULL for the timeout, the receive call will immediately return before data is received, and will fail the integrity check.

If I take David's advice and add a OSA_TimeDelay(1) between the send and receive calls, the receive call correctly gets the data and the integrity check succeeds.

In my original code, without the OSA_TimeDelay(1) I could pass -1 for the timeout and the receive function would correctly block until the data was received.  However, I had to have the MQX ISR installed and renamed first.  I could run the code full speed, and when I set the breakpoint in the task, execution would halt as expected.

If I try removing the OSA_TimeDelay(1) and instead specify 100 for the receive timeout, I can single step through the code and it sends and receives properly.  However, as soon as I resume execution, the task locks up.

I'll have to do some throughput tests, but having a 1ms interbyte delay is going to have significant effects on my data throughput.  I'll probably have to play with ticks a little to see if the results are reliable.  Otherwise, I might have to enable the MQX interrupt.

[DavidS]

I'm off to chase Easter bunnies.

Mid May for next release.

And yes I too will look into the timeout stuff.  I was surprised adding various delays into the UART_DRV_ReceiveDataBlocking() didn't help.

Regards,

David

[dave408]

Hi David, when issues like this come up, do they go into a central bug tracking system, or are each of the FSL employees responsible for maintaining their own list, depending upon the severity of the problem?  Just curious.  I'm not sure this issue is super critical, but it would be good to eventually understand what causes the problem.  Thanks!

[DavidS]

Hi Dave,

My apologizes for delayed response. I got run over by a bunny ;-)

The Community site is great for posting and asking for help.  It is monitored by various levels of Freescale technical resources.  When one of use thinks an issue is a bug, we will enter it into an internal system.

Alternatively if you think you have found a bug, you can formally log it by going to http://www.freescale.com/support .

Then look for "Create Service Request".

This will input your service request directly into the internal database to allow tracking and resolution.

We suggest only doing the later approach as last resort and use the Community as much as possible.  The answers here help everyone.  Answers in the internal database are somewhat lost.

Regards,

David

[dave408]

p.s. DavidS is there any chance you could take a peek at one of my posts, where I am having the most trouble, but haven't had any responses yet?  I've been unable to find any related topics here in the forum.

Assistance needed with lwIP + PEx + KSDK

Thank you!

[dave408]

Hi David, thank you for the tip!  I'll try to stick with the community forum as much as possible.  It has been quite a good resource for me while I have been learning about the Kinetis tools.

[dave408]

Have fun!  Have a great weekend, and thank you for all of your help today.

[dave408]

Awesome!  It is the OSA_TimeDelay that makes everything magically work.  Is this a bug in the framework?  I don't have to do that for the K64F, which is interesting.  This project also has more components than my K64F test application, so maybe that's related.  For now, I'm fine with the time delay, but it would be good to understand how / if it can be fixed in the framework so the delay isn't necessary. 

I take it that a good debugging strategy when things don't work is to check SIM_SCGC4 in the task that's using the peripheral, and ensure that the corresponding clock is enabled?

[DavidS]

General rule is if you get a hardfault, look to see if the module you are accessing has the module clock disabled in the SIM_SCGCx registers.  That is usually the culprit.

I will have to do additional testing to determine if the workaround for K22F is a errata or not.

Are you using the most up-to-date tool chain and have done "updates"?

Regards,

David

[dave408]

Ah, it was a hardfault?  I didn't think it was since it seemed that other code was still executing.  I should definitely put in the hard fault handler code, then.

What's interesting is that I ran my original code, and I checked SIM_SCGC4 before and after the OSA_TimeDelay, and the UART2 gate clock was enabled in both cases.

As far as I know, I'm using the latest tools.  KDS 2.0, KSDK 1.1, the Eclipse Update mentioned in the user manual, and the MQX task aware debugger update.  I haven't checked recently for any other updates.

By the way, do you have any idea when in Q2 KSDK 1.2 is coming out?  For me, I don't think it's critical anymore since I've proven basic operation of most of the K64 peripherals that I need (I'm just starting on the K22), but it would be nice to know if anyone at FSL knows.  :smileyhappy:

[dave408]

David, thank you *very* much for taking a look at my project.  I'm going to try out your changes shortly.  However, I'd like to mention something that I had found when trying to understand the different fsl_uart settings.  My loopback tests on the K64F were set up the same way -- blocking send/receive calls in addition to the interrupts and rx handler.  In that setup, my call to ReceiveDataBlocking actually received the transmitted character, despite the ISR and rx callback executing.  Since I don't need the ISR and callback, in the K64F project I have disabled them.  But I did it to get a better feel for what happens when the settings for the PEx component are changed.  That's also how I had determined that the "error" reported when the MQX interrupt is installed is a false error.

Thanks again, I'll report back with my results.

[dave408]

Yup, I did that, thanks.  It just annoys me because I went into the preprocessor definitions to make the change, but the one that's literally been staring me in the face in the Components tab went unnoticed!  :smileyhappy:  Great, now I can move on to more debugging!  I feel like I am getting close.