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.

How to setup CC2530 with TIMAC stack as coordinator?

Other Parts Discussed in Thread: CC2530, TIMAC, CC2538, Z-STACK, CC2650

I am using SmartRF05 evaluation board with CC2530 module on it. I have uploaded MAC coP firmware image to the module and able to send commands over RS232 and get response back.

Following instructions from the MAC coP Interface Guide (SWRU395):

4. Setting up a TIMAC Network

4.1 Starting a PAN Coordinator

To Start a PAN coordinator following sequence of commands can be used to the MAC-coP from the Host
via the MT interface

  1. Reset the MAC using the API : MAC_RESET_REQ
  2. Set the parameters using the API: MAC_SET_REQ
    1. Set the Short Address attributeID: ZMAC_SHORT_ADDRESS
    2. Set the Extended Address attributeID: ZMAC_EXTENDED_ADDRESS
  3. Scan the area for pre-existing PAN ID’s. send a MAC_SCAN_REQ
  4. After receiving MAC_SCAN_CNF (AREQ) determine the existing PANID’s and select a unique PAN ID to start the network.
  5. Start the MAC network using MAC_START_REQ
  6. Set the parameters: MAC_SET_REQ
    1. Allow Association: ZMAC_ASSOCIATION_PERMIT
    2. Device On All the time : ZMAC_RX_ON_IDLE, set true for coordinator

I have created next sequence of MT commands:

FE 02 22 01 01 DE (this message I have to send twice to get response FE 01 62 01 00 62, by the way, by documentation it should be FE 01 62 00 00 63)

FE 03 22 09 50 00 00 78

FE 09 22 09 E2 00 13 A2 00 40 9B 55 87 78

FE 13 22 0C 00 00 08 00 01 01 00 01 00 00 00 00 00 00 00 00 00 00 00 34

FE 23 22 03 00 00 00 00 12 34 0B 00 15 15 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2F

FE 02 22 09 41 01 69

FE 02 22 09 52 01 7A

In all cases I receive response SRSP messages from the module with status field 0x00 (success).

However, using my sniffer I don't see that coordinator actually started: no response to Beacon Request message from another device in all channels.

What am I doing wrong and how to fix this?

UPD: Edited list with sequence of operations according to original documentation

  • Hi,

    I've looked into the sample application code (not the NPI but the standalone application for the processor) and read a little bit more about the coordinator setup.

    After looking at your sequence here are some things that I found:

    • You should try sending the SYS_RESET_REQ in order to make sure your system is reset properly. And then send your MAC_RESET_REQ. You should receive a notification that your system was reset
    • I don't know if it's a typo, but your MAC_RESET_REQ command seems to be missing a byte.
    • Then you set your PAN ID after your reset (and you don't set your short address). The set PAN ID command should be done later during your start sequence.
      1. So you should first set your extended address
      2. Set your short address
      3. Send your scan request
      4. read the data received from the scan and use that information to define your pan id to make sure you don't use an exisiting one
    • In your active scan, there a few parameters that probably need some tweaking:
      • You scan the channel 11, so I hope that's the channel that you are sniffing.
      • you specify 0 for the max number of results. This means you get 0 results. (the sample application uses 5)
      • The scan duration might also be too short (the sample application uses 3).
    • In your start request, there are a few parameters that probably need tweaking
      • Check the results of your scan to set the Pan ID to something that you know is not used (you might check with your sniffer if you get a beacon with that PAN id)
      • The beacon order and super frame order given in the documentation is in decimal value (i.e. 15 = 0x0F)

    In terms of troubleshooting,

    • you can also try reading the mac address and short address using the GET_REQ command to make sure that you have written the values properly.
    • stop your program after the Scan request so you can see if the beacons are sent and received. There is no point in going any further until you actually get this working.
    • (this last step is more of a sanity check because you should see the scan request with your sniffer). In order to make sure that your radio is working, you could just force your cc2530 to become a coordinator (short address, extended address, pan id) followed by a start request. then send some data to see if the data is sent on the correct channel.

    Let us know what you get with those suggestions.

    Regards,

    Michel

  • Hi Michel,

    Thanks for prompt and verbose response. Seems I've made some mistakes.

    SYS_RESET_REQ is not mentioned in the MAC coP Interface Guide, but I found it in ZNP Interface Specification. I believe there is already some similar internal procedure called in firmware as I receive FE 06 41 80 01 02 00 02 06 03 C3 frame in RS232 each time I press reset button on the development board. Anyway I added command mentioned above.

    You are right, there is mistake in MAC_RESET_REQ. It had wrong length and FCS. Fixed. Now it is FE 01 22 01 01 23. However, there is some not clear information in the MAC coP Interface Guide as there is length value 0x02 mentioned, while frame contains only one 1-byte attribute:

    With all tweaks I got next sequence:

    Reset

    FE 06 41 80 01 02 00 02 06 03 C3 (first frame appeared immediately after reset)

    FE 01 41 00 00 40 (SYS_RESET_REQ SREQ)

    FE 06 41 80 02 02 00 02 06 03 C0 (SYS_RESET_REQ SRSP)

    FE 01 22 01 01 23 (MAC_RESET_REQ SREQ)

    FE 01 62 01 00 62 (MAC_RESET_REQ SRSP)

    FE 03 22 09 53 00 00 7B (MAC_SET_REQ ZMAC_SHORT_ADDRESS SREQ)

    FE 01 62 09 00 6A (MAC_SET_REQ ZMAC_SHORT_ADDRESS SRSP)

    FE 09 22 09 E2 00 13 A2 00 40 9B 55 87 78 (MAC_SET_REQ ZMAC_EXTENDED_ADDRESS SREQ)

    FE 01 62 09 00 6A (MAC_SET_REQ ZMAC_EXTENDED_ADDRESS SRSP)

    FE 13 22 0C 00 00 08 00 01 03 00 05 00 00 00 00 00 00 00 00 00 00 00 32 (MAC_SCAN_REQ SREQ)

    FE 01 62 0C 00 6F (MAC_SCAN_REQ SRSP)

    At this point using sniffer I see Beacon Requests are been sent (from my observations most likely the source is CC2530, but not sure 100%) and my other device configured as PAN coordinator (XBee) is responding with Beacon.

    However, I don't see any data appear in RS232. I expect AREQ: MAC_BEACON_NOTIFY_IND.

    FE 23 22 03 00 00 00 00 12 34 0B 00 0F 0F 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2F (MAC_START_REQ SREQ)

    FE 01 62 03 00 60 (MAC_START_REQ SRSP)

    Just after this command I see next

    FE 02 22 09 41 01 69 (MAC_SET_REQ ZMAC_ASSOCIATION_PERMIT SREQ)

    FE 01 62 09 00 6A (MAC_SET_REQ ZMAC_ASSOCIATION_PERMIT SRSP)

    FE 02 22 09 52 01 7A (MAC_SET_REQ ZMAC_RX_ON_IDLE SREQ)

    FE 01 62 09 00 6A (MAC_SET_REQ ZMAC_RX_ON_IDLE SRSP)

    At this point using sniffer I see that CC2530 is not responding with Beacon frames to Beacon Request from my other device configured as end device (XBee).

    Seems it is working better now, even if Beacon frame doesn't contain Beacon Payload. Any ideas why?

  • Hi,

    I am learning this stuff with you so bear with me while we figure this out together. You'll probably have to play around with the settings until you get what you expect.

    You do not get AREQ: MAC_BEACON_NOTIFY_IND because your scan request max number of results is set to a non-zero value. Instead, you should be getting a MAC_SCAN_CNF (see Section 5.3.25). I have misread the documentation, so if you do set the max number of results to 0, you would be getting the BEACON_IND messages for each beacon response. I would try this to see if you do get a different behaviour.

    As for the beacon response, I couldn't find code that would indicate whether BEACON_PAYLOAD and BEACON_PAYLOAD_LENGTH are set (I just skimmed over the code).

    In the sample application, the init sequence uses the SET_REQ with these Pib attribute IDs:

    ZMAC_BEACON_MSDU (beacon payload): 0x45

    ZMAC_BEACON_MSDU_LENGTH (beacon payload length): 0x46

    And here are what values in the sample application code:

    uint8         msa_BeaconPayload[] = {0x22, 0x33, 0x44};
    uint8         msa_BeaconPayloadLen = 3;

    And before you send the START request, try to wait for the MAC_SCAN_CNF (if you use non-zero max results value) or MAC_BEACON_NOTIFY_IND (if you set the max results to 0).

    I haven't looked at the other messages that you send, but let's try getting the beacons and start request working first.

    Again, let us know what you come up with.

    Michel

  • Hi,

    Unfortunately, today I realized that source of Beacon Requests is different (I don't know where it is exactly, but seems it is not CC2530). In any case, I don't receive neither MAC_BEACON_NOTIFY_IND, nor MAC_SCAN_CNF, even if I see Beacons from XBee in the sniffer. Tried with zero and non-zero max results. Also tried all channels. No difference. Seems like it is not actually scanning. Any ideas how to troubleshoot?

  • Hi,

    Can you try compiling and uploading the Sample application firmware first?
    The Sample application project is located here (if you installed TI-MAC in its default location):
    C:\Texas Instruments\TIMAC 1.5.2.43299\Projects\mac\Sample\cc2530\IAR Project (the version might be different)

    You should be able to see your CC2530 sending and receiving packets. If you don't, it might be hardware related. But try posting your issue (about the sample application) on the forums to see if you can get it resolved.

    I will later test with CC2538 modules (they use Cortex-M3 instead of 8051) to see if I can get it working with the CoP code.

    On a side note, I see that you are talking about Xbee module. Ti already provides a Z-stack for zigbee protocols on its website. You should still be able to see packets sent and received, so it's not really an issue (yet).

    Michel
  • Hi,

    I tried to compile sample application as well. Makes no difference. Following your recommendations I have created separate request on this topic.

    By the way, using ZMAC_BEACON_MSDU and ZMAC_BEACON_MSDU_LENGTH I managed to tweak beacon payload according to requirements of 3rd party device I want to communicate with. And even got Association request in RF media using sniffer:

    However, I didn't get ZMAC_ASSOCIATE_IND in serial interface. Seems this is common issue to above one.

    As for XBee, I just have some experience working with it and in this case it was only convenient tool for testing basic functionality of MAC layer. In the project I am working on right now I need to do integration with 3rd party product based on TIMAC stack and seems CC2530 with MAC coP image is the right choice.

  • I am not sure I understand the situation.

    You said that you do not see the beacon requests, yet, your screenshot shows a beacon payload sent from the PAN_ID specified in your previous posts.

    1. Was a beacon request sent from the CC2530?
    2. Is the beacon payload shown on the screenshot sent from your CC2530? (i.e. the CC2530 responds to beacon requests)

      When you say that the sample application does not work.

    3. What does not work?
    4. Did you compile the FFD configuration to set your CC5230 as coordinator?

    I didn't read the user guide for the sample application of the CC2530, but in the CC2538, when you start the application, you should see a blinking LED. Then when press the buttons or move the joystick (this starts the coordinator), you should see scan requests and beacon payloads sent back (the sample app sends scan requests on each channel until it finds an "empty" one). Once the coordinator is set up, the LED stops blinking. Is that the behaviour that you are getting?

    I will try to follow your other thread to find out what is the problem


    Regards,

    Michel

  • 1. No, the Beacon Request was sent from 3rd party device this time.

    2. Yes, I skipped scanning procedure and just started coordinator on CC2530 with specifically configured Beacon Payload.

    3. Sorry, I misunderstood you and compiled image for MAC coP from sources in "C:\Texas Instruments\TIMAC 1.5.2.43299\Projects\mac\MAC-coP\CC253x\MACcoP.eww". Behavior was the same as with pre-compiled image.

    4. Now I've compiled project from "C:\Texas Instruments\TIMAC 1.5.2.43299\Projects\mac\Sample\cc2530\IAR Project\msa_cc2530.eww" and device behavior matches with the one described by you above (see capture below). First Beacon Request is sent by CC2530 with Normal-FFD image when it is still in scanning mode, second Beacon Request is sent by 3rd party device, shorter beacon belongs to CC2530 with Normal-FFD image, when it is already established network, longer - CC2530 with MACcoP image. However, I didn't see any frames in RS232 and any response to MT commands. As I understand MT interface is not present in this project.

    I also tried network of 2 CC2530 with FFD and RFD devices, they are successfully creating network, joining and exchanging data.

  • So we know the hardware is working.
    I'm really at a loss as to what could be wrong.

    Unfortunately, the CoP is only compatible with the CC2530 device so I cannot perform tests on my side.

    If your device is sending back a beacon payload, it seems like the low-level MAC layer is working. So it's as if the messages don't reach the higher level MAC layer.
    Have you tried adding the MAC_INIT command (I have doubts about this, but the SYS_RESET_REQ might not reset the MAC layers properly)?

    Here is what the doc says.
    5.1.1 MAC_INIT
    Description:
    This API initializes the MAC subsystem. It must be called once when the software system is started and before any other MAC API is called. This is called up within MAC coP automatically on the MAC coP statup in the main function. So this is not required at first start up from the Application.

    This might be overkill, but can you try breaking in the code to see whether data is received in the MAC layer?
    Look for this function (in the mac_rx.c file. should be in MAC/Low Level/mac_rx.c):
    inline static void rxStartIsr(void)

    This might break very often (try checking with all your devices turned off except to CC2530) but at least you'll know that you radio is configured and we need to find the right commands to send to make it work.
  • I tried to call and not to call MAC_INIT_REQ. No difference. Probably this action is redundant.

    I did the debug. I see that static void rxStartIsr(void) is called each time, when Beacon Request or Beacon appears in the air, and structure pRxBuf is populated with corresponding bytes as far as I can decode. For example:

    Beacon:

    pRxBuf content (PAN ID matches with value from available coordinator):

    However, I am not able to trace program flow after following call statement:

    as macRxCompleteCallback(pRxBuf) is defined in library:

    "C:\Texas Instruments\TIMAC 1.5.2.43299\Projects\mac\Libraries\cc2530\IAR\bin\Lib\macLib_cc2530-Banked.lib"

  • I have made some progress.

    I was able to get a CC2650 which also has the Mac CoP firmware (the CC2538 doesn't).  I had to fiddle around to get the firmware to compile and load without errors.

    After compiling and loading onto my device, I had the same behaviour as you did so I figured that there must be a problem in the firmware itself.

    I cannot get anything sent out (BEACON_REQUESTs or data).

    And I didn't get any feedback beside the responses to the commands.

    But I found this thread:

    To get the callbacks forwarded to your host (PC), you need to enable them.

    Here is the command:

    FE 03 27 06 FF FF 01 23

    This will enable all callbacks (you can select which callbacks you want).

    After sending the Scan request, I finally got a response (but the beacon request was not sent)

    Can you check if you can get the beacon ind or SCAN_CNF answer when you have another Coordinator sending its beacon?

    The only problem that remains: how do to get the data to be sent out?

    The thread mentioned the Z-Stack ZNP documentation. It seems that not all available commands are listed in the MacCoP documentation. Try downloading the Z-Stack and read what additional commands could be used to enable the TX.

    Michel

  • Hi Michel,

    First of all, thanks for your prompt responses.

    UTIL_CALLBACK_SUBSCRIBE did the job. Now upon sending ZMA_SCAN_REQUEST I can see Beacon Request is been sent in the RF media and corresponding frames in serial interface, ZMAC_BEACON_NOTIFY_IND and ZMAC_SCAN_CNF. Strange that this info was not added to documentation, it is kind of important one.

    Right now I am trying to associate 3rd party end device with coordinator on CC2530. In response of ZMAC_ASSOCIATE_IND I send ZMAC_ASSOCIATE_RSP. However, it doesn't come out in the air, and I get ZMAC_COMM_STATUS_IND with ZMAC_TRANSACTION_EXPIRED (see below corresponding Z-Tool log). Warning about unsupported or unformatted message applies to received Data Request packet. Probably I need to find the way how to make this process real-time (right now I am sending messages in Z-Tool manually). In the log below I sent association response late, however even if I tried to send it in between separate association and data requests, it didn't work. Seems TX messages are not buffered long enough for polling interval. I don't see other possible reasons.  

    Start Time: 10/7/2016 06:52:18 PM

    <RX>06:52:23.11 COM15 ZMAC_ASSOCIATE_IND (0x4281)
    DeviceExtendedAddress: .0...... (0xC2, 0x30, 0x02, 0xFE, 0xFF, 0x83, 0x0A, 0x00)
    Capabilities: 0x80
    KeySource: K.@.U..4 (0x4B, 0x00, 0x40, 0x9B, 0x55, 0x87, 0x12, 0x34)
    SecurityLevel: 0x00 (NO_SECURITY) (0x0)
    KeyIdMode: 255 (0xFF)
    KeyIndex: 0x12

    *** WARNING ***
    Unsupported or unformatted message received. Raw data:
    0C 42 91 03 00 0A 83 FF FE 02 30 C2 12 34 01

    <RX>06:52:23.6 COM15 ZMAC_ASSOCIATE_IND (0x4281)
    DeviceExtendedAddress: .0...... (0xC2, 0x30, 0x02, 0xFE, 0xFF, 0x83, 0x0A, 0x00)
    Capabilities: 0x80
    KeySource: K.@.U..4 (0x4B, 0x00, 0x40, 0x9B, 0x55, 0x87, 0x12, 0x34)
    SecurityLevel: 0x00 (NO_SECURITY) (0x0)
    KeyIdMode: 255 (0xFF)
    KeyIndex: 0x12

    *** WARNING ***
    Unsupported or unformatted message received. Raw data:
    0C 42 91 03 00 0A 83 FF FE 02 30 C2 12 34 01

    <RX>06:52:24.1 COM15 ZMAC_ASSOCIATE_IND (0x4281)
    DeviceExtendedAddress: .0...... (0xC2, 0x30, 0x02, 0xFE, 0xFF, 0x83, 0x0A, 0x00)
    Capabilities: 0x80
    KeySource: K.@.U..4 (0x4B, 0x00, 0x40, 0x9B, 0x55, 0x87, 0x12, 0x34)
    SecurityLevel: 0x00 (NO_SECURITY) (0x0)
    KeyIdMode: 255 (0xFF)
    KeyIndex: 0x12

    *** WARNING ***
    Unsupported or unformatted message received. Raw data:
    0C 42 91 03 00 0A 83 FF FE 02 30 C2 12 34 01

    <TX>06:52:25.52 COM15 ZMAC_ASSOCIATE_RSP (0x4250)
    ExtAddr: ..K.@.U. (0x00, 0x12, 0x4B, 0x00, 0x40, 0x9B, 0x55, 0x87)
    AssocShortAddress: 0xABCD
    AssocStatus: 0x00 (SUCCESSFUL_ASSOCIATION) (0x0)
    KeySource: ........ (0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
    SecurityLevel: 0x00 (NO_SECURITY) (0x0)
    KeyIdMode: 0x00 (NOT_USED) (0x0)
    KeyIndex: 0x00

    <RX>06:52:25.54 COM15 ZMAC_ASSOCIATE_RSP_RESPONSE (0x6250)
    Status: SUCCESS (0x0)

    <RX>06:52:33.4 COM15 ZMAC_COMM_STATUS_IND (0x428D)
    Status: ZMAC_TRANSACTION_EXPIRED (0xF0)
    SrcAddrMode: 0x02 (ADDRESS_16_BIT) (0x2)
    SrcAddr: ........ (0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
    DstAddrMode: 0x03 (ADDRESS_64_BIT) (0x3)
    DstAddr: ..K.@.U. (0x00, 0x12, 0x4B, 0x00, 0x40, 0x9B, 0x55, 0x87)
    DevicePanID: 0x3412
    Reason: 0x00
    KeySource: 4.4..... (0x34, 0x12, 0x34, 0x00, 0x00, 0x03, 0x05, 0x00)
    SecurityLevel: 0x00 (NO_SECURITY) (0x0)
    KeyIdMode: 193 (0xC1)
    KeyIndex: 0x03

  • Glad this is resolved. Or at least the original problem is solved...

    If you are running a Linux machine, there is a Linux sample application in the installation folder that would run with the MacCoP

    C:\Texas Instruments\TIMAC 1.5.2.43299\Projects\mac\TI-MAC_LinuxSampleApp (on my computer).

    BTW, once you have confirmed that everything is working, you can click on Accept Answer on my previous post to let other people know this was resolved and hopefully this answer can help others if they want to use the MacCoP firmware.

    Let us know how everything works out.

    Regards,

    Michel

  • I have written Z-Tool script for real-time communication, but problem persists. Created new topic as this one can be considered as resolved:
    e2e.ti.com/.../547361