MQX Lite, KDS 2.0 & KSDK 1.1 - Serial Port Receiving Data

[wayneburnett]

Let me start by saying I am new to Freescale. Using this document How To: Create an MQX RTOS for KSDK project with Processor Expert in Kinetis Design Studio IDE I was able to get a project working with my FRDM-K64. I am now trying to get Bluetooth working with an adapter on UART4. Using PE I can I add the flsl_uart component and get it to send data to a Terminal emulator running on my PC. The problem is I can't get the K64 to receive data. Debugging it does enter the callback function when I press a key but then crashes on exit. I don't know how to configure the interrupts in PE. The warnings and tips indicate that MQX requires that an interrupt be installed and that a custom handler should be written. I can't find any information about this or even better a working example. The examples I can find appear to be for older versions of PE and I don't have the same component options.

The warning if interrupts are not turned on:

Warning: MQX OS needs install component interrupt service rountines (Install interrupt)

The hint for the handler:

Note: The routine must handle all interrupt flags correctly. The routine must be implemented in the user code, it is not generated by Processor Expert. Find external prototypes of the ISRs in the component module header file.

Thanks

Wayne

[Jorge_Gonzalez]

Hello Wayne,

Please try installing the UART4 interrupt with the next code:

_int_install_isr(UART4_RX_TX_IRQn, UART4_RX_TX_IRQHandler, 0);

There should be a file generated by Processor Expert called uartCom1.c (or the name you gave to the component). The ISR "UART4_RX_TX_IRQHandler" is already declared in this file, so you just need to install it under MQX with the code above.

This needs to be done with all the peripheral interrupts you use, specifying the IRQ number and the ISR function.

Then in this case for UART, in the file Events.c you will have a callback function. Place your own code there.

:smileyinfo: A different approach is to tell the fsl_uart component to install the ISR for you. Just change the name, since it complains about the ISR being used by MQX. I am not sure if this is a bogus error, I will continue to investigate:

If you still have problems please let us know.

Regards!,
Jorge Gonzalez

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

[dave408]

Hi Jorge, I believe that the error you refer to regarding the ISR name is somewhat bogus.  I was trying to understand more about fsl_uart today, and so I did file comparisons between a renamed file configuration and a unchecked the "Install interrupt" checkbox configuration.  It turns out that the interrupt handler is present regardless of the state of the checkbox.  It's just not installed.

That's why the error comes up when you check the "Install" checkbox -- the function has already been declared.  But when you change the ISR name, it installs the interrupt handler as expected, but the function it uses is exactly the same, just renamed.

[Jorge_Gonzalez]

Hello Dave:

I thought it was a bogus error by the time I replied, but it is not. The error only appears with MQX_KSDK projects, because the installed handler cannot have the same name as the one in startup_<device>.s. This is explained in the document I posted about interrupts and also in a document by colleague Martyn Hunt:

Interrupt handling with KSDK and Kinetis Design Studio

How To: Using Interrupt Handlers in MQX with KSDK

For a Non-RTOS project, installing the interrupt simply saves the vector (function pointer) in RAM, but the ISR name can be exactly the same.

Regards!

Jorge Gonzalez

[dave408]

Thanks for the info, Jorge, now I see what you are saying.  I think my "findings" were wrong because I probably checked the box and tried to generate the code with the default, original ISR name.  When you do this and then uncheck the box and regenerate, it leaves the function in the generated code.  So when I changed the name and saw that the function remained, I assumed that the ISR had been there all along, when it was really the one in the .S!  Thank you for clearing that up for everyone.

[wayneburnett]

Hi Jorge,

Thank you for responding to my request. I had tried your suggestion but still didn't have much luck.I have attached a sample test project. I am trying to turn the blue led on when an ASCII "1" is received and turn it off when a "0" is received.

I have inserted some simple code into the Rx Callback function to handle an incoming byte. I expect there is a way to simply use the call back function to process the incoming data? I just can't find any information on how to do this.It seems like Rx Buffer should factor into this as well.

Thanks

Wayne

[DavidS]

Hi Wayne,

Attached is ZIp with your original project, my modified project, and picture of frdm-k64f120m with J199 pins 3-4 jumpered.  I used J199 for the UART4 loop back.

Please compare the projects for modifications.

I changed the clock setting to use Clock Configuration 1 (Max achievable clock frequency).

I used the 2 tasks.  One to transmit to UART4 and the other to receive from UART4 at 9600 baud.  The Debug Console is operating at 115200 baud.

The coding isn't perfect but it does test the proper operation of the UARTs.

Regards,

David

[wayneburnett]

Hi David,

Thank you for taking the time to answer and test this. It appears that your approach revolves around UART_DRV_ReceiveDataBlocking(). I had managed to get something similar working using the non-blocking equivalent. I was hoping to get some answers about the Rx Callback function that gets created in Events.c? I expected this function to be called when a byte was received regardless of whether or not the system was expecting one. In many of my other bare metal projects I implemented interrupt driven rolling buffers with head and tail pointers. Is your approach considered standard practice for MQX? Should I rely on MQX to do all the heavy lifting with respect to the interrupts and stick with using UART_DRV_ReceiveDataBlocking or UART_DRV_ReceiveData?

I would still however like to better understand the role of the callback function and Rx Buffer. Can you point me to some documentation that explains this?

Thanks

Wayne

[DavidS · Accepted solution]

Hi Wayne,

The previous project was meant only to test the hardware to verify that the UART4 could send and receive data.

The updated attached project has the call back working and toggling the blue LED.

Using PE I turned on the UART Rx Interrupts and defined a buffer to use for receiving the data.

The simplified test now has one task to toggle a data value from 1 to 0.  The code sends the data out to UART4 using PE UART_DRV_SendDataBlocking() function call and in Events.c you can see where the uartBluetooth_RxCallback() has been modified to use the received char to toggle the LEDRGB_BLUE defined LED.

Regards,

David

[wayneburnett]

Thank you very much David. This was exactly what I was looking for. I hope this helps others.

I think a lot of my issues were related to the definitions and references for Rxbuff.

-Wayne