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.

CC2340R2: Issue with Migrating Program from CC2340R5 to CC2340R2

Part Number: CC2340R2
Other Parts Discussed in Thread: CC2340R5, SYSCONFIG, , LP-EM-CC2340R5

Tool/software:

Dear TI Support Team,

I am writing to seek assistance regarding an issue I encountered while working with the CC2340R2 chip. I followed the guidelines to modify the flash macro definitions, switched the chip model in SysConfig, cleared previous build information, and reprogrammed the device. The code that was functioning perfectly on the CC2340R5, continuously transmitting Bluetooth iBeacon data, fails to transmit any data on the CC2340R2.

For the hardware modifications, we replaced the chip on the LP-EM-CC2340R5 demo board with the CC2340R2. I conducted tests using SmartRF Studio 8, and the results showed successful data transmission on channels 37, 38, and 39, confirming that the hardware setup is operational.

Could you provide any solutions or guidance on configuring the project to address this issue on the software side? Your assistance would be greatly appreciated.

Thank you for your support.

Best regards

  • I have reselected the chip and resolved the issue of no data being sent. However, a new problem has emerged: the delay added in the while loop can only go up to around 190ms, and increasing it further doesn’t work. Even multiple calls to the delay function are ineffective. This code works perfectly on the CC2340r5, so the issue likely occurred during the SDK migration process. Could you provide an effective solution for this?

  • Hi, 

    I have assigned an expert to support. 

    Please provide a code snippet showing the way you are using the device. 

    Also, it looks like you are trying to mimic Bluetooth advertising, but at the same time it seems you are not using the Bluetooth stack. Could you please explain why you have selected this approach? 

    Best regards, 

  • 这是 rfPacketTx.c

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /*
    * Copyright (c) 2013-2022, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    这是 main_freertos.c

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /*
    * Copyright (c) 2013-2022, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    This is a part of the code snippet and configuration information. Regarding the above issue, we hope to find a solution. We didn’t use the Bluetooth stack because we have higher requirements for its power consumption. We hope to achieve our functionality with lower power consumption.

  • Additionally, during testing, I discovered a peculiar issue. As mentioned earlier, we are using the LP-EM-CC2340R5 demo board. Following the adaptation guide, I set the board to CC2340R22 on LP_EM_CC2340R5. Even after changing the flash size, no functionality seemed to work. When I selected the board as CC2340R2 Development Platform and adjusted the flash size, Bluetooth data could be sent normally, but the above issue occurred. I tried to troubleshoot whether the radio transmission was affecting the delay by commenting out the send interface and replacing it with an LED, but it seems that the pins in syscfg do not correspond to the actual pins. I hope you can provide support to help us resolve these issues. Thank you!

  • Hello Wenbo Hu,

    I hope you are doing well. 

    but it seems that the pins in syscfg do not correspond to the actual pins

    -we can try to see if there is a difference by comparing what Syscfg thinks the pins are, vs what pin setup we are trying to use, reference the custom HW in the SDK documentation BLE5-Stack Quick Start Guide (ti.com)

    We didn’t use the Bluetooth stack because we have higher requirements for its power consumption.

    -We do provide a proprf PHY that can replicate BLE like packets, but without the BLE stack, and this is what you are currently using, the issue here is that your application code (delay) is not working, if you place a breakpoint at the delay what happens?

    Thanks,
    Alex F

  • Hello Alex Fager,

    I hope you are doing well. 

    I’m sorry, this issue has not been resolved, but I accidentally clicked this button with my mouse.

    I set a breakpoint at the delay function for debugging and found that the delay function entered normally while also performing thread scheduling operations. Then I replaced the delay function with vTaskDelayUntil(), and found that the same issue occurred—the maximum delay could only be 200ms. Can you provide a solution or relevant examples that work correctly?

    Alternatively, to simplify the problem, we are using the CC2340R2 chip on the LP-EM-CC2340R5 demo board. We followed the migration guide to transfer the “ti\simplelink_lowpower_f3_sdk_8_10_01_02\examples\rtos\LP_EM_CC2340R5\drivers\buttonled\freertos\ticlang” example to CC2340R2, but found it didn’t work. Can you provide operational guidance or examples related to CC2340R2?

    Thanks,

  • Hello Wenbo Hu,

    Here is a quick code snippet from rfpacketTx I modified with vTaskDelay();

    I also added in syscfg the LNA pins (under RCL).

    This helps me check the timing with a logic analyzer of ~1.3 s delay (800 ms from vTaskDelay and 500 ms from usleep)

    Can you see what the LNA pins tell you?

    Thanks,
    Alex F

  • Alex Fager, I’m glad to receive your response and appreciate the validation results you’ve provided. However, the issue I’m facing is not yet resolved. I’ll now walk you through my steps so that you can help identify the problem.

    First, I imported a CC2340R5 chip that was modified and verified based on “rfPacketTx.” Then, I clicked on syscfg, selected SWITCH, and chose “CC2340R2 Development Platform” in the board options. I also tried selecting “CC2340R22 on LP_EM_CC2340R5,” but when I chose this option, I couldn’t capture any BLE data, and importing other examples with this option didn’t work properly either.

    Next, I opened the file “lpf3_freertos.cmd” and modified the macro definition “#define FLASH_SIZE 0X40000”. Finally, I compiled the project and flashed it onto the demo board. The issue was reproduced with these steps.

    Do you see any potential oversights in my operations that might be causing the problem?

    I have attached my operation steps screenshots and the project generated according to the above steps.

    cc2340r5_ibeacon.zip

  • Hello,

    I will take a look at your described steps above! and also consult one of my team members.

    Thanks,
    Alex F

  • Thank you for your help. How was the result?

  • Hello Wenbo Hu,

    I apologize for the delay here, I should be able to give you a response sometime today.

    Thank you,
    Alex F

  • Hello Wenbo Hu,

    I got a R2 board and I am migrating the project, currently dealing with an issue where the RCL LNA pins do not seem to be working (or that the radio is not active). 

    Thanks,
    Alex F

  • Hello Wenbo Hu,

    I got the rfPacketTX project working and have modified the "delay" reference code snippet below:
    In this case I followed the migration steps from BLE5-Stack Migration Guide, but did not modify the lpf3_freertos.cmd file for reference. 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void *mainThread(void *arg0)
    {
    /* Initialize and open RCL */
    RCL_init();
    RCL_Handle rclHandle = RCL_open(&rclClient, &LRF_config);
    /* Set RF frequency */
    rclPacketTxCmdGenericTx.rfFrequency = FREQUENCY;
    /* Start command as soon as possible */
    rclPacketTxCmdGenericTx.common.scheduling = RCL_Schedule_Now;
    rclPacketTxCmdGenericTx.common.status = RCL_CommandStatus_Idle;
    rclPacketTxCmdGenericTx.config.fsOff = FS_OFF; // Turn off FS
    /* Callback triggers on last command done */
    rclPacketTxCmdGenericTx.common.runtime.callback = defaultCallback;
    rclPacketTxCmdGenericTx.common.runtime.rclCallbackMask.value = RCL_EventLastCmdDone.value;
    /* Set RCL TX buffer packet to be packet buffer */
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    rfPacketTx_LP_EM_CC2340R5_freertos_ticlang.zip

    Thanks,
    Alex F

  • Alex_Fager

    Thank you for your help. My colleagues and I will verify the engineering you provided and feedback the results to you. Thank you!

    Thanks,