MKW01 Transmitting But Not Receiving

[thiagolehrcompa]

Hello everyone,

I'm testing two mkw01 boards, and trying through Radio Utility send the default buffer to another board. I've made the test in Putty to verify if it's sending, and everything went ok.

But, when I put the another board to receive, the rxStatus appears as "rxProcessingReceptionStatus_c". I think I had initialized SMAC correctly. I tested and saw that MCPSDataIndication it's not called.

The transmitter is set to send for broadcast and both in Channel 11. Do I have to set some address?

Thanks

[EarlOrlando]

Hello Thiago,

Could you please confirm what is the SMAC version that you are using?

Since you are receiving the rxProcessingReceptionStatus_c flag, it seems that the transmission is being started (i.e. you are receiving the preamble) but you are not receiving all the packet. Maybe the sync word is incorrect, could you please confirm that it is correct (it is set in the SetDefaultValues() function)?

Assuming you are using the version 3.0.2 of SMAC (if you are using another version, the function's names change but there shouldn't be a big difference), the way to debug this issue is to put a breakpoint in the function PhyRxHandleSyncAddresEvent (file PhyISR.c). This function is called after receive the preamble. In this function you will find a line which states the next function to be executed (when the next part of the packet is received) [gpfPendingRxEvent = PhyRxHandlePHREvent;], in this case it is the PhyRxHandlePHREvent which is called after receive the sync word. Put a breakpoint in this function, if this function is not executed it would mean that the sync word is not being successfully received. Then, as you can see in the code, the next function to be called will be PhyRxHandleFifoLevelEvent, put another breakpoint here and continue debugging this way until the function PhyRxHandlePayloadReadyEvent is called to ensure that the application flow is correct. When this last function is called, the function Radio_Phy_PdDataConfirm is executed (where the event gRadio_PdDataConfirm_c is set which results in update the status to gPhySuccess_c).

For reference, I attach this figure (taken from the MKW01xxRM.pdf) where you can see all the parts of the packet.

This way to debug your system will let you know where is the problem. I hope this helps.

Best regards,

Earl.

[thiagolehrcompa]

Hello Earl,

Thanks very much for the answer, and sorry for the late to update my situation. I've followed your steps, and learned a little bit more about how to debug correctly with IAR. Yes, I'm using SMAC 3.0.2 and actually my problem was in how to initiate SMAC correctly. After some research, I realized that I wasn't doing it right.

I'll take a good look in MKW01xxRM.pdf, to see how should I configure the packets to be sent and received.

Thanks again for your time,

Thiago

[calebrust]

my problem was in how to initiate SMAC correctly

Hello,

I think I'm having a similar problem.  Do you remember what you changed or added?

[thiagolehrcompa]

Hello calebrust,

I've put these lines in order to work properly:

    DisableInterrupts();
    Platform_Init();              
    InitGlobalVariables();// Initialization of MCU and transceiver   
    LED_TurnOffAllLeds();
    SetDefaultValues();//Set Radio to default values             
    EnableInterrupts();
    (void)MLMESetChannelRequest(canal); 
    (void)MLMERXDisableRequest();
    gpSmacRxPacket->u8MaxDataLength = gMaxSmacSDULength_c;
    gpSmacRxPacket->rxStatus = rxSuccessStatus_c;

Then I've put the functions that do the communication, according to the PDF.

I hope this helps,

Thiago

[calebrust]

Thanks for the info Thiago.  My problem had a different cause related to packet contents, and a timeout.  These comments are about the Connectivity_TestApp.c example in the MKW2x IEEE 802.15.4 examples.

Because I was testing manually and my mouse clicking was on the order of seconds, I had to first remove the 80ms timeout.

//TMR_StartSingleShotTimer (RangeTestTmr, 80, RangeTest_Timer_CallBack, NULL);

Next, the packets I was trying to sniff weren't MAC 802.15.4 compliant, so I had to enable promiscuous mode prior to RXEnable:

PhyPlmeSetPIBRequest(gPhyPibPromiscuousMode_c, (uint64_t)1, 0, 0);

(void)MLMERXEnableRequest(gAppRxPacket, 0);

Then, since packets are further filtered in PD_SMAC_SapHandler(), I disabled the SMACPacketCheck() function call:

  case gPdDataInd_c:

    //if(FALSE == SMACPacketCheck(pDataMsg))  //software packet filtering, to avoid parsing errors

Note that commenting out SMACPacketCheck() is bad if you are expecting 802.15.4 packets.  In my situation I knew the packet would not contain a typical MAC header.