• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 2153 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems running HostTestApp using CC2540 UART0 with Alt2 (P1)

Chris Norris
Intellectual 935 points

Other Parts Discussed in Thread: CC2540

Looking for help/advice.

I am using BTool.exe with the HostTestApp project on BlueGiga BLE112 hardware with CC2540F128.  Using the CC2540USB configuration and communicating with USB, BTool.exe works great.

Now I want to use the physical serial port.  I changed to the CC2540EM Master configuration.  I performed modifications in _hal_uart_isr.c similar to those described in http://e2e.ti.com/support/low_power_rf/f/538/p/99676/349193.aspx#349193 to change the UART0 to the Alt. 2 configuration.


For an interface to the PC, I'm using an FTDI chip with FTDI RTS wired to CC2540 CTS and FTDI CTS wired to CC2540 RTS.

In BTool.exe, I'm using 57600,N,8,1 setting with CTS/RTS enabled.  When the conversation with the device starts, the first command is processed, but subsequent commands are ignored (see sample output below):

Port opened at 7/14/2011 12:56:27 PM


[1] : <Tx> - 12:56:27.517
-Type  : 0x01 (Command)
-Opcode : 0xFE00 (GAP_DeviceInit)
-Data Length : 0x26 byte(s)
 ProfileRole : 0x08 (Central)
 MaxScanRsps : 0x03
 IRK  : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 CSRK  : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 SignCounter : 0x00000001
Dump(Tx):
01 00 FE 26 08 03 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 01 00 00 00

-----------------------------------------------------------------------------------------------
[2] : <Rx> - 12:56:27.658
-Type  : 0x04 (Event)
-EventCode : 0xFF (HCI_LE_ExtEvent)
-Data Length : 0x06 bytes(s)
 Event  : 0x067F (GAP_HCI_ExtentionCommandStatus)
 Status  : 0x00 (Success)
 OpCode : 0xFE00 (GAP_DeviceInit)
 DataLength : 0x00
Dump(Rx):
04 FF 06 7F 06 00 00 FE 00

-----------------------------------------------------------------------------------------------
[3] : <Tx> - 12:56:27.814
-Type  : 0x01 (Command)
-Opcode : 0xFE31 (GAP_GetParam)
-Data Length : 0x01 byte(s)
 ParamID : 0x15 (TGAP_CONN_EST_INT_MIN)
Dump(Tx):
01 31 FE 01 15

-----------------------------------------------------------------------------------------------
[4] : <Tx> - 12:56:27.814
-Type  : 0x01 (Command)
-Opcode : 0xFE31 (GAP_GetParam)
-Data Length : 0x01 byte(s)
 ParamID : 0x16 (TGAP_CONN_EST_INT_MAX)
Dump(Tx):
01 31 FE 01 16

-----------------------------------------------------------------------------------------------
[5] : <Tx> - 12:56:27.814
-Type  : 0x01 (Command)
-Opcode : 0xFE31 (GAP_GetParam)
-Data Length : 0x01 byte(s)
 ParamID : 0x1A (TGAP_CONN_EST_LATENCY)
Dump(Tx):
01 31 FE 01 1A

-----------------------------------------------------------------------------------------------
[6] : <Tx> - 12:56:27.830
-Type  : 0x01 (Command)
-Opcode : 0xFE31 (GAP_GetParam)
-Data Length : 0x01 byte(s)
 ParamID : 0x19 (TGAP_CONN_EST_SUPERV_TIMEOUT)
Dump(Tx):
01 31 FE 01 19

-----------------------------------------------------------------------------------------------
[7] : <Rx> - 12:56:27.830
-Type  : 0x04 (Event)
-EventCode : 0xFF (HCI_LE_ExtEvent)
-Data Length : 0x2C bytes(s)
 Event  : 0x0600 (GAP_DeviceInitDone)
 Status  : 0x00 (Success)
 DevAddr : C0:FF:EE:C0:FF:EE
 DataPktLen : 0x001B
 NumDataPkts : 0x04
 IRK  : A9 9C 02 FD 10 C3 85 0C 88 E0 A8 66 F2 BE 43 07
 CSRK  : BC 55 B7 B1 77 B7 1B 27 E5 8A B6 48 F7 B4 D3 C7
Dump(Rx):
04 FF 2C 00 06 00 EE FF C0 EE FF C0 1B 00 04 A9
9C 02 FD 10 C3 85 0C 88 E0 A8 66 F2 BE 43 07 BC
55 B7 B1 77 B7 1B 27 E5 8A B6 48 F7 B4 D3 C7

-----------------------------------------------------------------------------------------------
[8] : <Tx> - 12:59:07.697
-Type  : 0x01 (Command)
-Opcode : 0xFE04 (GAP_DeviceDiscoveryRequest)
-Data Length : 0x03 byte(s)
 Mode  : 0x03 (All)
 NameMode : 0x01 (Enable)
 WhiteList : 0x00 (Disable)
Dump(Tx):
01 04 FE 03 03 01 00

-----------------------------------------------------------------------------------------------
[9] : <Warning> - 12:59:22.680
Scanning Timeout...


When I probe RTS on the CC2540 with an oscilloscope, it is stuck at 1 (de-asserted) after the first command.  I have to reset the CC2540 for RTS to assert again.

I was wondering whether BTool.exe is sending commands too quickly, so I wrote a LabVIEW routine to send only a single command (GAP_DeviceInit) instead of the sequence of multiple commands that BTool.exe uses.  The CC2540 processes the single command, but RTS remains de-asserted (logic 1) so I can never send another command.


I've also tried disabling CTS/RTS handshaking by making the following change in _hal_uart_isr.c:

static void HalUARTOpenISR(halUARTCfg_t *config)
{
  // TODO: CLN 13-July-2011 Think the halUARTCfg_t is instantiated in
  // the BLE stack, so don't know if I have access outside context of
  // HCI_Init(). I will override settings here unless I can find a better
  // place later.
//  config->baudRate = HAL_UART_BR_38400;
  config->flowControl = HAL_UART_FLOW_OFF;

This seemed like the most appropriate place to change the UART settings since I couldn't find where the referenced halUARTCfg_t is defined.  I assume that HalUARTOpenISR() is being called from the stack.

With CTS/RTS disabled, I see the same behavior.  Only one command over UART gets processed, then the CC2540 does not respond to further commands.

Has anyone experienced a similar issue?  Before I start debugging the UART HAL code, I want to make sure I'm not missing anything obvious.

Thanks,
Chris Norris

 

  • 0
    TI__Genius 17975 points

    Not sure the exact cause of the problem, but FYI- this is the code used by the HCI to initialize the UART port:

      halUARTCfg_t uartConfig;

      // configure UART
      uartConfig.configured           = TRUE;
      uartConfig.baudRate             = HCI_UART_BR;
      uartConfig.flowControl          = HCI_UART_FC;
      uartConfig.flowControlThreshold = HCI_UART_FC_THRESHOLD;
      uartConfig.rx.maxBufSize        = HCI_UART_RX_BUF_SIZE;
      uartConfig.tx.maxBufSize        = HCI_UART_TX_BUF_SIZE;
      uartConfig.idleTimeout          = HCI_UART_IDLE_TIMEOUT;
      uartConfig.intEnable            = HCI_UART_INT_ENABLE;
      uartConfig.callBackFunc         = hciSerialPacketParser;

      // start UART
      // Note: Assumes no issue opening UART port.
      (void)HalUARTOpen (HCI_UART_PORT, &uartConfig);

  • 0 in reply to Willis1
    Intellectual 935 points

    Hi Willis,

    Thanks for the information on the way the HCI init configures the port.  I am very curious about other internals, such as what is the criteria for the HCI layer to call HalUARTReadISR()?  Having full sources would be very nice.  ;)

    I believe that the CC2540 UART hardware is fundamentally working.  I made the following modification in the recieve ISR to intercept each byte before it's stored to the circular buffer in the HAL.  I was able to echo each character from UART0 RX on UART0 TX, so I believe that my port setup is ok.

    /***************************************************************************************************
     * @fn      halUartRxIsr
     *
     * @brief   UART Receive Interrupt
     *
     * @param   None
     *
     * @return  None
     ***************************************************************************************************/
    #if (HAL_UART_ISR == 1)
    HAL_ISR_FUNCTION( halUart0RxIsr, URX0_VECTOR )
    #else
    HAL_ISR_FUNCTION( halUart1RxIsr, URX1_VECTOR )
    #endif
    {
     
      uint8 tmp = UxDBUF;

    #if 1
      numRxInterrupts++;
    #endif

    #if 1
      // TODO: Chris N. data loopback test. Echo the received character, but
      // return before passing it to the isrCfg.rxBuf.
      HalUARTWrite(HAL_UART_PORT_0, &tmp, 1);
      return;
    #endif


    I have continued my source and register-level debug in the HAL layer.

    I removed my above debug loopback code.  I placed a counter in the recieve interrupt (numRxInterrupts shown in source above).  Before I restart the HostTest app, I set a breakpoint in HalUARTWriteISR().  I start execution then I send the GAP_DeviceInit command from the PC.  The breakpoint is hit, and numRxInterrupts is 42 which was the length of the command sent from the PC.  U0CSR.RX_BYTE is zero, so there is no character pending at the UART.  TCON.URX0IF is not set, so there is no recieve interrupt pending.  IEN0.URX0IE is still set, so I expect that future Rx interrupts will be processed.  Everything looks good so far.

    I continue execution, and the TX ISR sends the GAP_DeviceInitDone response from the BLE stack.  I probe RTS, and it is asserted (logic 0).  Still looking good.

    I zero out my numRxInterrupts counter in the watch window, and now I set a breakpoint in halUartRxIsr().  I send another command from the PC (this time it was a GAP_GetParam, but with the current failure it doesn't matter).  The breakpoint in halUartRxIsr() is never hit.  If I manually break, U0CSR.RX_BYTE is one, so there is a byte present at the reciever.  Probing RTS, it is de-asserted (logic 1), so this will block further transmission from the PC.  IEN0.URX0IE is still set, so interrupts are enabled, but TCON.URX0IF is not set, so there is no interrupt pending even though there is a byte waiting.

    So, I'm stuck at a point where I can perform my first change where I can echo characters all day long without the recieve interrupt failing, but when I allow the BLE stack to process the first command, I can't get anoter UART Rx interrupt to happen.

    I've even tried flushing out the bytes of the second command by adding this code snippet to osal_run_system() and enabling it in the debugger:
      if (fixRxJam == 1)
      {
        dummy = U0DBUF;   
      }
    I execute this code repeatedly with "set next statement", and I can eventually get the U0CSR.RX_BYTE to clear to zero, but if I try sending another command from the PC, I don't get another Rx interrupt.

    Has anyone else seen the UART Rx interrupt broken this way?

    All advice is appreciated!

    Regards,
    Chris Norris

  • 0 in reply to Chris Norris
    Prodigy 30 points

    Hi

    I was wondering if you can upload 128KB image that I can put on my BLE112

    Thanks in advance

    Yunus