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.

LAUNCHXL-CC2640R2: uart open fail

Part Number: LAUNCHXL-CC2640R2

SDK4.40, IAR8.3

C:\ti\simplelink_cc2640r2_sdk_4_40_00_10\examples\rtos\CC2640R2_LAUNCHXL\ble5stack\simple_peripheral

I have minimum change, add macro

BOARD_DISPLAY_USE_LCD=0

BOARD_DISPLAY_USE_UART=0

Display_DISABLE_ALL

then open uart:

void UartInit()
{
    UART_init();
    UART_Params uartParams;
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;//----数值模式
    uartParams.readDataMode = UART_DATA_BINARY;//-----数值模式
    uartParams.readMode = UART_MODE_CALLBACK;//-------串口读取回调模式
    uartParams.readCallback  = uartReadCallBack;//----串口读取回调函数指针
    uartParams.writeMode =  UART_MODE_CALLBACK;//-----需将串口发送也设置为回调模式,否则在串口发送回调函数中使用UART_write()会有死机风险
                                               //-----原因可能是在串口回调函数中不能执行用会导致阻塞的操作
    uartParams.writeCallback = uartWriteCallBack;//---串口发送回调函数指针,不能为NULL
    uartParams.baudRate = 9600;//-------------------波特率
    uart = UART_open(Board_UART0, &uartParams);
    if(uart == NULL){
      IOAction(IO_LED_R,1);
      return;
    }
    IOAction(IO_LED_G,1);
}

whole project zip here:

http://qpic.xuan-chi.com/uPic/simple_peripheral-testuart0.zip

test result: fail. red led lights on.

see attached picture:

  • Hi,

    I have run the same example as you using the simple_peripheral example for blestack and ble5stack. In both cases, as long as the UART display is disabled (as you have described), the UART driver is properly opened. For my tests, I have executed the same code as the one you have provided in the SimplePeripheral_init() function.

    Through these tests I do NOT manage to reproduce your issue.

    Note: For ble5stack, the predefined symbols should be added/modified within the file TOOLS/defines/ble5_simple_peripheral_cc2640r2lp_app_FlashROM_StackLibrary.opt

    Best regards,

  • how you confirm the uart open success?  LED?   are you using my project? or only copy hal.c/.h file in my project? or copy the code?

  • Hi,

    I am not able to open your project. So I have started from the simple_peripheral examples in SDK 4.40.

    I have added the piece of code you have suggested inside the SimplePeripheral_init() function.

    I have checked the value of handle "uart". It is not NULL. I then manage to use the UART properly.

    Best regards,

  • are you using CCS or IAR? have you modified IO init table?

    is there some way I can get some out of box sample for uart and spi etc?

  • I am be able to test in CCS cloud, and debug/step.

    I open the sample project (blestack5SimplePeripheral), write minimum uart open, still fail.

    snapshot attached.

    the program can not go beyond UART_open, it can not reach if(uart == NULL)

    when i step, it goes into some function in last snapshot, which I do not understand.

  • Hi,

    The test I have run before, is compiled with CCS. The out-of-the-box configuration is used for all the files except for disable UART display (in ble5_simple_peripheral_cc2640r2lp_app_FlashROM_StackLibrary.opt) and to add UART opening (in simple_peripheral.c).

    The function accessed in the last screenshot does not say much. I mean, this function is expected to be accessed.

    Here a few more things you may want to verify:

    - try to step in the UART_open function in order to identify the issue

    - try to disable code optimization to help debugging

    Best regards,

  • could you please try it in CCS cloud?

    I can not step and find any information helpful, step always lost.

    how to disable code optimization? 

  • I have installed CCS and am able to step now.

    attached snapshots, and the file

     0044.simple_peripheral.c

  • Hi,

    Optimization level can be selected by right clicking on the project > Properties > Build > Arm Compiler > Optimization.

    The file you have provided does not seem to contain UART related code.

    The first screenshot you have provided shows the fxnPtr not being initialized. This is either because the code optimizer has reorganized the code (not an issue) or the UART_config table is not properly initialized.

    I would recommend to disable the code optimization and continue stepping in the code. Make sure to leverage our debugging guide.

    Best regards,

  • step shows it fails at:

    UARTCC26XX_initIO(handle)

    looks like something else is using it.

    /* Trying to use UART driver when some other driver or application

            *  has already allocated these pins, error!

            */

            DebugP_log0("Could not allocate pins, already in use.");

  • Hi,

    Just to make sure, I have set BOARD_DISPLAY_USE_UART_ANSI to 0 in my test. Not sure if it will help.

    You have done some interesting progress. You now need to see which pin is causing the issue. To do so, you could step in the function UARTCC26XX_initIO() and PIN_open().

    You could also verify in the board files which pins are used by the UART and verify they are not used somewhere else.

    Best regards,

  • set BOARD_DISPLAY_USE_UART_ANSI to 0 makes no difference.

    have tracked down, please find the attached snapshot. but I have no idea why it happens

  • Hi,

    Ok. Based n your screenshot, the firt pin of the pin table (which should correspond to the rxPin) uses an invalid value (64). Could you please verify with the UARTCC26XX_HWAttrsV2 what is the value for this pin?

    Regards,

  • here it is what I find, everything looks no problem.

  • Hi,

    I do not manage to reproduce your issue.

    Are you sure the uartCC26XXHWAttrs structure used is the one you have showed? You could verify this by using the address of the structure as I have shown below.

    Best regards,

  • please check the snapshot attached.

  • Hi,

    Actually I don't think we should look for a UART pin with the wrong value (like 64). I have run in step by step mode and at one point I manage to have the pinId value set to 64 even if everything works as expected.

    So this idea does not seem to lead to the resolution.

    This leaves us with a potential pin conflict (i.e. an handle is already associated to the pin in pinHandleTable[]).

    Here what the table looks like for me before we open the pins for UART.

    Here what the table looks like at the end of the PIN_open() function:

    If it helps, I have managed to reproduce an issue with the UART when not resetting properly the device. When in debug, make sure to reset as followed:

    Best regards,

  • here is my test result after board reset.

  • Hi,

    Ok, then you have your root-cause. PINs 3 and 4 are already opened, hence the issue.

    Either the UART get opened somewhere else, either the PINs are used by something else. You need to identify where this happens. You can do this by setting a break point in the PIN_open code, that way you will stop as soon as the PINs get opened. Then, by stepping in the code, you should manage to find the caller.

    You're closer and closer to find the solution :)

    Kind regards,

  • thanks it is ok now. it is because at first I can not step so I open pin for LED control.

  • Hi,

    Great! Well done for completing this debug!

    Kind regards,