MC13213 and the state of Freescale's SMAC code

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC13213 and the state of Freescale's SMAC code

394 Views
MJWeston
Contributor III

Hi,

 

I'm trying to use the SMAC code from Beekit 2.0.1 (2.0.2 downloading now but I doubt it will help).  I'm having a couple of problems.  One of them was asked two years ago on this forum and I see it hasn't been resolved.  I started with the Wireless Uart code and then stripped it down and built it back up.

 

The first problem is that the very first RX packet after a reset is garbage.  The length is correct but the data is not.  I'm still trying to point down whether it is a pointer issue or what but it is right in Freescale's code somewhere (hopefully not at the hardware level!).  This problem exists for me as it did just running the WU code without modification.

 

My second problem is that I am trying to create a back and forth between two devices using packets and acknowledgements.  The problem is that after a receive and then a transmit, I cannot get back into receive mode.  Even though the interrupts seem to fire and there is code to do the transitions, I can't get it to work.  The WU code really ignores any issues with being in the wrong state which is probably why it just locks up half the time.

 

What I have found is that smacState gets returned to mSmacStateIdle_c  by the end of the call to PhyPdDataRequest().  After it returns, smacState gets set to mSmacStateTransmitting_c and then there is no way to get out of it.  This is what I see when debugging.  I know the success of trying to monitor live packets is difficult this way but I set breakpoints at spots where all the data has a chance to get in or out.  I have a board set up as an RF sniffer and the data definitely does hit the air.  The SMAC code and its states are screwy and I can't figure out how to fix it.

 

Has anyone dealt with this and resolved it already?

 

Thank you,

 

 

Michael

Labels (1)
0 Kudos
0 Replies