Why does call to UART_HAL_SetTxInversionCmd() cause exception to HardFault_Handler?

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does call to UART_HAL_SetTxInversionCmd() cause exception to HardFault_Handler?

Jump to solution
266 Views
surrealist14
Contributor III

Hi folks,

 

I have made good progress using KSDK_1.1.0 to develop some code that implements a polled debug console and an interrupt-driven UART, but tried something today that has me baffled.  I am hoping that perhaps one of you has tried this and found a solution.  I'm using a TWR-K60D100M with IAR Embedded Workbench for Cortex-M V7.40.2.

 

Looking at the UART Tx signals with a logic analyzer, they appear to idle in the "high" state, i.e. they go low to start transmitting data.  I confirmed this by looking at a UART0 Tx output and UART3 Tx, which runs down to a convenient jumper on the TWR-SER board.

 

I have some eval hardware that I'm trying to send serial data to that appears to want the data in the opposite state, so I did some reading and found out that there are bits to allow inversion of Rx and/or Tx.  As a small code example, here is a sample initialization that would initialize UART0 and try to invert the Tx and Rx lines:

 

     uart_user_config_t uart0Config; // UART configuration parameters

     uart_state_t uart0State;        // Memory for UART driver state structure   

 

     // Set up the I/O pins required

     configure_uart_pins(HW_UART0);

 

    // Initialize the UART configuration

    uart0Config.baudRate = 115200;

    uart0Config.bitCountPerChar = kUart8BitsPerChar;

    uart0Config.parityMode = kUartParityDisabled;

    uart0Config.stopBitCount = kUartOneStopBit;

 

    // Initialize the UART driver

    UART_DRV_Init(HW_UART0, &pcCommUartState, &uart0Config);

  

    // Here comes trouble...

    UART_HAL_SetTxInversionCmd(HW_UART0, true);

    UART_HAL_SetRxInversionCmd(HW_UART0, true);

 

As soon as I try to call UART_HAL_SetTxInversionCmd(), the K60 processor appears to generate a hard fault, and I end up in the following startup code:

 

        PUBWEAK HardFault_Handler

        SECTION .text:CODE:REORDER:NOROOT(1)

HardFault_Handler

        B .

 

Does anyone know why this could be happening?  The UART documentation clearly says that there are registers with bits to invert Tx and/or Rx, but when I try to do it through the provided HAL function, I get HardFault_Handler().

 

Thanks in advance for any advice or help!

 

Scott

Labels (1)
1 Solution
123 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Scott:

Those HAL functions are expecting a UART module base address (e.g. for UART0 in K60D10 this would be 0x4006A000), while HW_UART0 (=0) is an instance number. Try using g_uartBaseAddr[HW_UART0] like this:

    UART_HAL_SetTxInversionCmd(g_uartBaseAddr[HW_UART0], true);

    UART_HAL_SetRxInversionCmd(g_uartBaseAddr[HW_UART0], true);


Regards!,
Jorge Gonzalez

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

View solution in original post

0 Kudos
2 Replies
124 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Scott:

Those HAL functions are expecting a UART module base address (e.g. for UART0 in K60D10 this would be 0x4006A000), while HW_UART0 (=0) is an instance number. Try using g_uartBaseAddr[HW_UART0] like this:

    UART_HAL_SetTxInversionCmd(g_uartBaseAddr[HW_UART0], true);

    UART_HAL_SetRxInversionCmd(g_uartBaseAddr[HW_UART0], true);


Regards!,
Jorge Gonzalez

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

View solution in original post

0 Kudos
123 Views
surrealist14
Contributor III

Hi Jorge,

Wow, do I feel dumb now.  Thank you so much for the outstanding answer.  I had gotten used to dealing with the hardware "instance" via the peripheral driver layer, and now it's very obvious that the HAL deals with the base address instead.

Although I should have picked up on this from the documentation for the HAL function, it would be nice if there was some way to catch this at compile time, perhaps by using different types for an "instance" vs. a "baseAddr".

At any rate, your answer was very fast and right on the money.  Thank you very much for the help, and a big thumbs up for the effort!

Best regards,

Scott