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.

CC2530: I want to ask to Ti engineer not forum

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, TIMAC, SMARTRF06EBK

I want to ask to Ti engineer, not forum.

How can I ask to them?

  • Hi Edan,

    TI engineers such as myself monitor each E2E forum post daily.  Your only other contact on the E2E forum has been with YK Chen who is a long-standing member of the E2E community and an expert in MCU RF communications.  Any thread you create on the E2E forum is getting the proper amount of attention from TI.

    Regards,
    Ryan

  • I implemented the function by looking at the cc2530 example.

    1) Read the voltage with the end device cc2530 (hal_adc.c).

    2) Send the read value to Router cc2530. (Basicrf.c)

    Each works properly. But mixing the above two doesn't work. No error occurs.

    <Question>

    1) Are there any examples that only have ADC and RF communication?
    The zstack example has too many unnecessary files and is intertwined, so if I remove unnecessary something, it won't work properly.

    2) can I use basic_rf.c to operate as an end device and router? someone said that basic_rf.c is only for 1:1 communication.

  • 1) No, you will need to develop this on your own.  Please further explain how "mixing the above two doesn't work" with details about what specifically does not work, debug efforts, etc.

    2) You cannot interoperate basic_rf.c with Z-Stack or any Zigbee protocol firmware.  Basic RF is indeed only 1:1 communication for simple radio functions.

    Regards,
    Ryan

  • OK,so Which example source is RF communication for EndDevice and Router? not BasicRF.

  • Z-Stack 3.0.2\Projects\zstack\HomeAutomation, any project option.  Once opened in IAR, change the build configuration to "End Device" or "Router".

    Regards,
    Ryan

  • I choose the SampleTempratureSensor-EndDeviceEB. Which file is about RF communication?

  • There is no single file for RF communication.  You can review the Z-Stack 3.0.2\Documents\Z-Stack 3.0 Developer's Guide.pdf to further understand the ZCL, APS, BDB, NWK, and MAC layers.  Typically a ZCL command will lead to AF_DataRequest which ultimately calls APSDE_DataReq.  This is a function contained within the pre-build Zigbee library which is not accessible to users, however it will make the necessary radio commands to control the IEEE MAC/PHY.

    Regards,
    Ryan

  • I can't understand Ti's support system.
    I just want a few pages document ,but all answer is 'read a book'.

    I use the CC2530F256 board. It is small 2cm*2cm. It's about 10$.
    I just use only two functions: ADC and RF. I think it's a really simple and small feature.
    put values in a few setting registers and put values in the DATA transfer register. very simple.
    However, ZSTACK 3.0 is for the SmartRF06EB board with a CC2538EM. not the CC2530F256 board. It has so many features.
    Do I need to study 94 pages of the SmartRF06EB board documentation to get the ADC and RF sources?

  • Do you require Zigbee protocol or basic RF communication?  That determines the software resource and documentation you should reference.  Either includes ADC functionality to build upon.  Z-Stack 3.0 does include CC2530 resources.  You do not need to study the SmartRF06EB board.

    Regards,
    Ryan

  • I am trying to wirelessly transmit ADC read from several CC2530s to one CC2530.

    Do I have to study Z-Stack 3.0 Developer's Guide.pdf?

  • Then this would constitute a network, and thus Basic RF is likely unsuitable.  At the risk of further confusion, SIMPLICITI or TIMAC star networks are also a possibility.

    Please understand that the CC2530 is a Legacy device with older software resources.  For an upgraded user experience, I recommend the the CC26XX devices utilizing the SimpleLink CC13XX / CC26XX F2 SDK.

    Regards,
    Ryan

  • I choose the TIMAC 1.5.2.43299\Projects\mac\Sample\cc2530\IAR Project\mac_cc2530.eww

    Normal-FFD(Coordinator),Normal-RFD(EndDevice),

    What are the files regarding PAN ID settings, data transmission, data reception?

  • The Application/msa.h file contains many User Defines such as Pan ID, short addr, packet length, etc.  Then msa.c contains the logic for the application, data transmission with MSA_McpsDataReq, and data reception through the MAC_MCPS_DATA_IND callback event.

    Regards,
    Ryan

  • Thank you very much.

    I will study msa.c firstly

  • I found the source of the loop in Timac. osal_run_system() in osal.c.

    Can I add my source there?

    My sources are below.

    P1DIR |= 0x03;
    P1_0 = 0;
    P1_1 = 1;
    halSleepWait(500);
    P1_0 = 1;
    P1_1 = 0;
    halSleepWait(500);
    uint16 adcvalue=0;
    adcvalue=HalAdcRead(HAL_ADC_CHANNEL_0,HAL_ADC_RESOLUTION_10);
    msa_Data=adcvalue//have to convert to fit the format
    MSA_McpsDataReq(msa_Data, MSA_ECHO_LENGTH,TRUE, msa_CoordShortAddr );

    if I am wrong, How can call MSA_ProcessEvent () for transfer ADC data?

  • The formal approach would be to create a new timer and event which periodically executes your code from within MSA_ProcessEvent.  Reference MSA_POLL_EVENT as an example.

    Regards,
    Ryan

  • The RF communication is not an example of a special case. This is a very common case.
    Why do you not provide example code for RF communication within MSA_ProcessEvent()?

    I've read all the documentation on Timac, but I can't find an approach like your answer, so I don't know what else to do.
    I'm not asking you to write my code.
    Please provide a sample source code for a typical, general, standard RF that runs properly on TImac.and then I can understand Timac process.

  • Hi Edan,

    I have removed some of the comments from your previous E2E response which were neither kind nor professional in accordance with the E2E posting guidelines.  Please refrain from further statements in the future.

    I do apologize that you are having difficulty to grasp the example code as provided.  Full documentation of the MSA example, including out-of-box usage and descriptions of MSA_ProcessEvent and MSA_McpsDataReq routines for further application expansion, is given in the TIMAC 1.5.2.43299\Documents\Mac Sample Application - Software Design.pdf

    There are already instances of direct MSA_McpsDataReq usage within MSA_ProcessEvent, such as the case of MAC_MCPS_DATA_IND for a packet reception echo.  The intent of my previous message was to share a means of creating a periodic timer which would regularly execute your code of interest.  TI provides the baseline example code from which developers can further implement their own functionality, and the E2E is a means of having experienced engineers engage with the community, answer questions, and help guide the development process.

    Regards,
    Ryan

  • Okay, sorry I didn't know the posting guidelines. I'll read it and follow it.
    And I have already read all the documents. Of course, I also read the Mac sample application - Software Design.pdf.

    The Mac sample application - Software Design.pdf. is a description of a function and not an example of using the functions in combination
    I need the example of the basic functions combination.

    Summarizing the answers so far, it seems that RF communication requires creating a timer that executes MSA_SEND_EVENT.

    What I need is a one-page main.c file containing these.
    There are examples with a lot of unnecessary source code, but I can't find any examples that use each of the basic functions (ADC, RF, DIO etc.).

    <Question>
    1) I am trying to develop a board with only cc2530 + aNNTENA without using an evaluation board such as SMARTRF06EBK.
        Is it right that the msa_cc2530 project of TImac example can make RF communication between cc2530s not evaluation board?

    2)I put the following line in the last line of osalInitTasks()
        osal_start_timerEx(taskID, MSA_SEND_EVENT, MSA_WAIT_PERIOD);
       Is this the same as what you said?
       I set a breakpoint on "if (events & MSA_SEND_EVENT)" in MSA_ProcessEvent().
       But the breakpoint setting is disabled so I can't check if my coding is correct.

    Thank you for your continued replies.
    I felt frustrated by the general answer rather than a direct solution.
    I'm sorry.
    It's true that if I succeed in this development, it will be because of your help.

  • 1) Peripheral modifications are controlled by hal_board_cfg.h and other HAL files (like hal_led.c and hal_key.c) contained within TIMAC 1.5.2.43299\Components\hal\target\CC2530EB.  The radio configurations are determined by mac_radio_defs.c/mac_rffrontend.c from TIMAC 1.5.2.43299\Components\mac\low_level\srf04\single_chip.  You will need to change these files in accordance with the needs of your custom hardware.

    2) This API should be in application file msa.c, likely MAC_MLME_ASSOCIATE_CNF (for end device RFD), as this would be after the device joins the Coordinator PAN and is ready to communicate.  You would use MSA_TaskId instead of taskID in this context.  Make sure your IAR Debugger options select "TI XDS" instead of "Simulator" and that you are programming the device with the application code before entering the debug session.

    Regards,
    Ryan

  • 1) I added the line below to the last line of osalInitTasks() and MSA_ProcessEvent().
    osal_start_timerEx(MSA_TaskId, MSA_SEND_EVENT, 1000);
    So the loop works fine, but the time interval is not 1000ms.
    I tried changing the time number variously, but the actual time is always approximately 10ms.

    2) I confirmed that data is being transmitted through MSA_McpsDataReq() of MSA_ProcessEvent().
    However, it is not possible to know where the data is being received.
    Even with the MAC_MCPS_DATA_IND you mentioned, MSA_McpsDataReq() is being sent, not received.

  • 1) How are you measuring the "actual" time?  What's your IAR version?  Please note that the debugger should not be used to evaluate the time in between events as the connection greatly interferes with timing.

    2) That is correct, MAC_MCPS_DATA_IND is for receiving incoming application packets.  You can use MAC_MCPS_DATA_CNF to confirm that the last transmission completed, and pData->dataCnf.hdr.status == MAC_SUCCESS would mean that a MAC ACK was received from the remote device (since status is not MAC_NO_ACK or any other faulty status).  If you want an application acknowledgement from the remote device, please refer to the "if (!msa_IsCoordinator)" statement inside of MAC_MSPS_DATA_IND, which is for the End Device to transmit back an echo message to the Coordinator upon receiving an application packet.  This echo packet would be received in the local Coordinator-side MAC_MSPS_DATA_IND.

    Regards,
    Ryan

  • 1) IAR EW8051 10.40.1
        I attached an LED to the cc2530 board.
        Led On at the start of MSA_PROCESSEVENT()
        Led Off at the end of MSA_PROCESSEVENT()
      and timer at the end of MSA_PROCESSEVENT()
      so first LED on ~ next LED on is timer's interval.

    2)below is MAC_MCPS_DATA_IND of MSA_PROCESSEVENT()
       Which variable have the received data?

    case MAC_MCPS_DATA_IND:
    pData = (macCbackEvent_t*)pMsg;

    if (MSA_DataCheck ( pData->dataInd.msdu.p, pData->dataInd.msdu.len ))
    {
    //HalLedSet (HAL_LED_3, HAL_LED_MODE_TOGGLE);

    /* Only send the echo back if the received */
    if (!msa_IsCoordinator)
    {
    if (MSA_ECHO_LENGTH >= 4)
    {
    /* Return the first 4 bytes and the last byte of the received packet */
    msa_Data2[0] = pData->dataInd.msdu.p[0];
    msa_Data2[1] = pData->dataInd.msdu.p[1];
    msa_Data2[2] = pData->dataInd.msdu.p[2];
    msa_Data2[3] = pData->dataInd.msdu.p[3];
    }

    MSA_McpsDataReq(msa_Data2,
    MSA_ECHO_LENGTH,
    TRUE,
    msa_CoordShortAddr );
    }

    #if defined (NV_RESTORE) && defined(FEATURE_MAC_SECURITY)
    /* Incoming Packet */
    for(i = 0; i < MAX_DEVICE_TABLE_ENTRIES; i++)
    {
    if (msa_deviceTable[i].shortAddress == pData->dataInd.mac.srcAddr.addr.shortAddr)
    {
    msa_deviceTable[i].frameCounter[0]++;
    }
    if((msa_deviceTable[i].frameCounter[0] % 1000) == 0)
    {
    osal_nv_write(MAC_NV_DEVICE_TABLE, 0, sizeof(msa_deviceTable), &msa_deviceTable);
    }
    }
    #endif
    }
    break;
    }

    /* Deallocate */
    mac_msg_deallocate((uint8 **)&pMsg);

  • 1) You shouldn't add to MSA_ProcessEvent directly as this routine loops from various event sources (SYS_EVENT_MSG, MSA_POLL_EVENT, MSA_SEND_EVENT) hence the constant LED toggling.  The example to use is MSA_POLL_EVENT which is started once during MAC_MLME_ASSOCIATE_CNF and afterwards each time the MSA_POLL_EVENT event is serviced.

    2) pData->dataInd.msdu.p (this is a pointer)

    E2E forum tip: Insert -> Code

    Regards,
    Ryan

  • RF Communication is working well as set by the timer from the End device to the coordinator.
    thanks for your help.
    <Question>
    1)Data sent from several End Devices is received by the Coordinator. How to distinguish which End Device sent it?
    How to read the IEEE ID of Device?
    2)What is mean the previous your reply that "E2E forum tip: Insert -> Code"

  • 1)  You can use pData->dataInd.mac.srcAddr.addr to get a unique address of the sending device which may be viable as your ID.  

    2) 

    Regards,
    Ryan

  • I sent the addr as below source, but the received data changes repeatedly.

    Fullscreen
    1
    2
    msa_Data1[12]=HI_UINT16(pData->dataInd.mac.srcAddr.addr.shortAddr);
    msa_Data1[13]=LO_UINT16(pData->dataInd.mac.srcAddr.addr.shortAddr);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    However, the below source received the same value as the IEEE ID of the smartRF flash program.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    //00 12 4B 00 13 8C B0 0C
    msa_Data1[12]=msa_ExtAddr[7];//00
    msa_Data1[13]=msa_ExtAddr[6];//12
    msa_Data1[14]=msa_ExtAddr[5];//4B
    msa_Data1[15]=msa_ExtAddr[4];//00
    msa_Data1[16]=msa_ExtAddr[3];//13
    msa_Data1[17]=msa_ExtAddr[2];//8C
    msa_Data1[18]=msa_ExtAddr[1];//B0
    msa_Data1[19]=msa_ExtAddr[0];//0C
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    <Question>
    I wanted to use printf(), so I added #include "DebugTrace.h" to msa.c.
    And I wrote printf("test\n") at the beginning of MSA_ProcessEvent().

    There are no compile errors but there is nothing in the tool output window.

  • Likely since the short address is assigned by the Coordinator during commissioning and thus dynamic, however the extended address is static to the local End Device.  Whichever suits your needs is fine.

    I'm not certain on printf support for TIMAC, but DebugTrace.h is located inside the MT folder which is supported through a serial connection such as UART.  Further investigation on your end will be necessary.  I'd recommend looking into enabling hal_uart.c/h and using HalUARTWrite.

    Regards,
    Ryan

  • I'd like to ask about ADC return value.

    uint16 adcvalue=0;
    adcvalue=HalAdcRead(HAL_ADC_CHANNEL_4,HAL_ADC_RESOLUTION_12);

    Apply 3.3v to P0.4 (ADC4).
    I expected to get 0xFFF (12bit), but the return value was 0x7FF.

    hal_adc.c : All variables returned from the functions below are unit16.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    uint16 HalAdcRead (uint8 channel, uint8 resolution)
    {
    uint16 reading = 0;
    #if (HAL_ADC == TRUE)
    uint8 i, resbits;
    uint8 adcChannel = 1;
    /*
    * If Analog input channel is AIN0..AIN7, make sure corresponing P0 I/O pin is enabled. The code
    * does NOT disable the pin at the end of this function. I think it is better to leave the pin
    * enabled because the results will be more accurate. Because of the inherent capacitance on the
    * pin, it takes time for the voltage on the pin to charge up to its steady-state level. If
    * HalAdcRead() has to turn on the pin for every conversion, the results may show a lower voltage
    * than actuality because the pin did not have time to fully charge.
    */
    if (channel < 8)
    {
    for (i=0; i < channel; i++)
    {
    adcChannel <<= 1;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi,

    What value do you have for adcRef?

    Thanks,
    Toby

  • I didn't change it so according from TImac,it is HAL_ADC_REF_AVDD.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    #define HAL_ADC_REF_AVDD 0x80 /* AVDD_SOC Pin Reference */
    #define HAL_ADC_REF_VOLT HAL_ADC_REF_AVDD
    void HalAdcInit (void)
    {
    #if (HAL_ADC == TRUE)
    adcRef = HAL_ADC_REF_VOLT;
    #endif
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Edan,

    This result should confirm that you are reading the ADC with a 12-bit resolution in 2s-complement form.  From Chapter 12.2.5 of the CC253x/4x User's Guide:

    The digital conversion result is represented in 2s-complement form. For single-ended configurations, the result can be expected to be positive. This is because the result is the difference between the input signal and ground, which is always positively signed (Vconv = Vinp – Vinn, where Vinn = 0 V). The maximum value is reached when the input signal is equal to VREF, the selected voltage reference. For differential configurations, the difference between two pins is converted, and this difference can be negatively signed. For example, with a decimation rate of 512 using only the 12 MSBs of the digital conversion result register, the maximum value of 2047 is reached when the analog input (Vconv) is equal to VREF, and minimum value of –2048 is reached when the analog input is equal to –VREF.

    Regards,
    Ryan

  • Thanks for your reply.

    According to your answer,single-ended input have the value of 0~4096,differential input have the value of -2048~2047.
    the below is CC253x/4x User's Guide:

              The single-ended inputs AIN0 through AIN7 are represented by channel numbers 0 to 7.
              Channel numbers 8 through 11 represent the differential inputs consisting of AIN0–AIN1, AIN2–AIN3, AIN4–AIN5,and AIN6–AIN7.

    The ADC reading function is uint16 HalAdcRead (uint8 channel, uint8 resolution) in hal_adc.c  .
    I used HAL_ADC_CHN_AIN4 or HAL_ADC_CHANNEL_4 as channel parameter.
    These are single-ended channels in hal_adc.h not differential channel.
    The differential channel is HAL_ADC_CHN_A0A1,HAL_ADC_CHN_A1A2 and so on.

    As a result I used a single ended channel and its maximum should be 4095 (0xFFF).
    I would appreciate it if you could let me know what I am misunderstanding.

  • My interpretation is that the ADC conversion result is 2s-complement independent of the single or differential ended configuration.  In the case of single-ended, and possible negative values are simply zeroed.  Here are some further resources https://e2e.ti.com/f/1/t/899145 

    Regards,
    Ryan

  • So, is there no way to receive the 0xFFF value with the cc2530's ADC?

  • I am not currently aware of one.

    Regards,
    Ryan

  • 1) MAC_MCPS_DATA_IND is called when incoming over-the-air IEEE packets are received which are from an associated device in the 15.4 network.
    2) The HAL_KEY_SW_1 condition inside of MSA_HandleKeys establishes the necessary startup procedure for the Coordinator.  Thus you could use this code outside the context of the key handle.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* Start the device as a direct message device and beacon disabled*/
    if (!msa_IsStarted)
    {
    /* Read IEEE Address from Info Page */
    MAC_READ_CHIP_IEEE_ADDR(msa_ExtAddr);
    /* Decide if direct or indirect messaging is used */
    msa_IsDirectMsg = MSA_DIRECT_MSG_ENABLED;
    if (msa_IsDirectMsg)
    {
    /* Start the device as an DIRECT messaging device */
    if (msa_BeaconOrder != 15)
    MSA_ScanReq(MAC_SCAN_PASSIVE, MSA_MAC_BEACON_ORDER + 1);
    else
    MSA_ScanReq(MAC_SCAN_ACTIVE, 3);
    }
    else
    {
    /* Start the device as an INDIRECT messaging device and beacon disabled */
    /* Beacon network doesn't work with polling */
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,
    Ryan

  • thank you very much
    I'll test above source instead of the SW1 button.

  • Thanks to your help, my project is going well.
    I created UART0 Interrupt RX mode using the source code of Design Note DN112.
    The Data is received using the sources below.(alphabet string data)
    I can check the received data every second by MSA_SEND_EVENT in MSA_ProcessEvent()

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    if(uartRxBuffer[0]!=0x0){
    isRequest=TRUE;
    send_uart(uartRxBuffer[1]);//send to UART0
    send_uart(uartRxBuffer[2]);
    send_uart(uartRxBuffer[3]);
    send_uart(uartRxBuffer[4]);
    uartRxBuffer[0]=0x0;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    <Question>
    However, even after send to UART0  once and waiting for more than 10 seconds,
    it is often missed in rx buffer. This is especially true if the data transferred is less than 5 digits.
    Can you help this problem?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    #define SIZE_OF_UART_RX_BUFFER 10
    unsigned short __xdata uartRxBuffer[SIZE_OF_UART_RX_BUFFER];
    unsigned short __xdata uartRxIndex;
    _Pragma("vector=0x13") __near_func __interrupt void UART0_RX_ISR(void);
    _Pragma("vector=0x13") __near_func __interrupt void UART0_RX_ISR(void){
    URX0IF = 0; //UART0 RX Interrupt clear
    uartRxBuffer[uartRxIndex++] = U0DBUF;
    if (uartRxIndex >= SIZE_OF_UART_RX_BUFFER) {
    uartRxIndex = 0;
    //IEN0 &= ~0x04;//uart0 interrupt disable
    }
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void initUART(void) //sets all configurations in UART
    {
    CLKCONCMD = CLKCONSTA & 0xB8; //clock control
    while(CLKCONSTA & 0x40);
    PERCFG&=~0x03;//Alernative 1 selected for UART0 and UART1
    P0SEL |= 0x3C;//P0.2 and P0.3(UART0)/ P0.4 and P0.5 (UART1)
    U0UCR |= 0x00; //H/w flow control disabled
    U0CSR |= 0x80;//SPI:0,UART1
    U0CSR |= 0x40;//polling:0,interrupt:1
    IEN0 |= 0x84; //UART0 RX Interrupt EA=1; URX1IE=1
    URX0IF = 0; //UART0 RX Interrupt clear
    U0GCR |= 0x08;
    U0BAUD = 0x3b; //Baud rate set to 9600 bps
    U1CSR |= 0x80;
    U1UCR |= 0x00; //H/w flow control disabled
    U1GCR |= 0x08;
    U1BAUD = 0x3b; //Baud rate set to 9600 bps
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and hal_board_cfg.h

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #if HAL_UART
    /*#ifndef HAL_UART_DMA
    #if HAL_DMA
    #if (defined ZAPP_P2) || (defined ZTOOL_P2)
    #define HAL_UART_DMA 2
    #else
    #define HAL_UART_DMA 1
    #endif
    #else
    #define HAL_UART_DMA 0
    #endif
    #endif*/
    #ifndef HAL_UART_ISR
    #if HAL_UART_DMA // Default preference for DMA over ISR.
    #define HAL_UART_ISR 0
    #elif (defined ZAPP_P2) || (defined ZTOOL_P2)
    #define HAL_UART_ISR 2
    #else
    #define HAL_UART_ISR 1
    #endif
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • However, even after send to UART0  once and waiting for more than 10 seconds,
    it is often missed in rx buffer

    Are you the RFD or FFD node type?  As RFD will likely enter power mode 2 (sleep) for which UART reception is disabled.

    This is especially true if the data transferred is less than 5 digits

    You could try sending longer padding data to this device to a length you are confident will be received, or configure the UART RX pin as a GPIO input (enabled in sleep mode) if you are not planning to receive any interpretable data and instead just want to be notified of when to take action.

    Regards,
    Ryan

  • This is FFD.
    and I set URX0IF = 1 (RX completing) if coming special character(like '\n')
    but It's not useful.
    How can set the RX complete flag?

  • I should clarify that I'm not familiar with the DN112 solution.  I'd recommend utilizing the hal_uart.c APIs instead and possibly modifying HalUARTPollIsr (among others) to fit your design needs.

    Regards,
    Ryan

  • This forum contains the adc,uart,rf of the techniques for the cc2530, so no need to read the other forums.
    Now the problem is i2c of cc2530.

    I use the I2C driver in RemoTI-CC253xDK-1.2.1

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    <hal_i2c.h>
    //P1.6 for SDA and P1.7 for SCL.
    #ifndef OCM_CLK_PORT
    #define OCM_CLK_PORT 1
    #endif
    #ifndef OCM_DATA_PORT
    #define OCM_DATA_PORT 1
    #endif
    #ifndef OCM_CLK_PIN
    #define OCM_CLK_PIN 7
    #endif
    #ifndef OCM_DATA_PIN
    #define OCM_DATA_PIN 6
    #endif
    <ms_main.c>
    int main(void){
    HalI2CInit();
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Other coding in hal_i2c.c and hal_i2c.h is unchanged.
    I use P1.6 for SDA and P1.7 for SCL. With pull-up resistance.
    According to the source coding above,return status value is all 0 ,it is ok.
    But 
    the read data is always 00. I expected 0xFF.

    The i2c slave is an eeprom (AT24c64) board.
    I tested the same eeprom board using Arduino.
    The EEPROM board is working well to read and write.

    Do you have any experience using i2c on cc2530?

    hal_i2c.zip

  • I do not have any experience using I2C on the CC2530.  Since there is no dedicated I2C peripheral hardware on the CC2530 the solution presented is a bit-banging software implementation.  You should confirm that P1.6 and P1.7 are not being used elsewhere by your code, and physically monitor the SCL & SDA lines with an oscilloscope or logic analyzer to confirm that they are being controlled as expected.  You should also compare these readings against the Arduino solution to discover the difference.  You should double-check your hardware to make sure that the lines are properly connected and that the EEPROM address is correctly assigned.  Why do you expect 0xAB to be returned after sending 0xFF?  Should you be using the a HAlI2CReceive address of 0xA1 for reading values? 

    Regards,
    Ryan

  • 0xAB is mistake I expect 0xFF.

    Of course, it use address + 1 in HalI2CReceive(address,buffer,length).

    A2,A1,A0 are all 0. And R=1, W=0

    so Write Address is 0xA0, Read Address is 0xA1

  • Since hali2cReceive -> hali2cSendDeviceAddress does not force the last bit of the address to be high, at least in the version attached, this is something you will need to account for in your code alongside my other recommendations.

    Regards,
    Ryan

  • I modified to   
    status=HalI2CReceive(0xA1, &readdata, 1);
    Therefore,It became hali2cReceive(0xA1) -> hali2cSendDeviceAddress(0xA1).
    But the result is the same.

  • This is good emphasis as to why you will need to use a logic analyzer or oscilloscope to physically monitor the pins since you are not familiar with the I2C library being used.

    Regards,
    Ryan

  • Yes,You are right.Thank you.
    It was a wiring mistake. So the I2C drivers of RemoTI-CC253xDK-1.2.1 are all working fine. I have attached the I2C files.
    Although cc2530 does not have I2C function, it has been proven that I2C can be used using the file below .
    It has been slightly modified to fit the eeprom(AT24c64)  protocol.

    Fullscreen
    1
    2
    3
    4
    5
    HalI2CInit();
    uint8 senddata[3]={0xAB,0x78,0x01};
    status=HalI2CSend(0xA0, senddata, 3);
    uint8 readdata[3]={0}; // Buffer to store read data
    status=HalI2CReceive(0xA0, readdata, 3);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    5556.hal_i2c.zip

  • 1)When the coordinator is turned on while the end device is already turned on,

    The end device cannot receive RF data from the coordinator.
    However, the coordinator is receiving RF data normally from the end device.
    I saw the coordinator transmit RF data to the end device using Packet Sniffer.
    At this time, power off and on to end device, then end device receive rf data.
    How can I restart end device by software?

    2) Conversely, the coordinator turns on first. The end device is then powered on.

    It works fine after the coordinator sends rf data 0xff times.
    so the end device received the data too late.
    Test results are always the same for the sequence numbers below.
    First 0~ff: Does not work
    Next 0: Doesn't work
    Next 1:It works fine from here

    The above sequence exists in MSA_PROCESS_EVENT.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    if (msa_IsCoordinator)
    {
    if (MSA_PACKET_LENGTH >= MSA_HEADER_LENGTH)
    {
    //Coordinator sending to devices. Use the associated list of device to send out msg
    msa_Data1[0] = MSA_PACKET_LENGTH;
    msa_Data1[1] = HI_UINT16(msa_DeviceRecord[index].devShortAddr);
    msa_Data1[2] = LO_UINT16(msa_DeviceRecord[index].devShortAddr);
    msa_Data1[3] = sequence;
    }
    MSA_McpsDataReq((uint8*)msa_Data1,
    MSA_PACKET_LENGTH,
    msa_DeviceRecord[index].isDirectMsg,
    msa_DeviceRecord[index].devShortAddr );
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



1 2