Hello TI-Team and community!
I'm trying to transmitt data without the TI-MAC. Broadcast works perfect - with address recognition disabled. But with address recognition enabled, nothing changes. No single frame is rejected. What am I doing wrong?
Here is my code:
The receiver ISR:
#pragma vector=RF_VECTOR__interrupt void Radio_ISR(void) { if (RFIF & 0x10) { // Start of frame delimiter (SFD) has been detected RFIF &= ~0x10; // delete flag P1 ^= 0x08; // invert the LED at every SFD-detection while (!(RFSTATUS & 0x04)); // wait until the whole frame has been received (RFSTATUS.FIFO) if (RFSTATUS & 0x08) { // if data is in the FIFO temp = RFD; // read the length flied T1Ch0Low = RFD; // | T1Ch0High = RFD; // | read data RFST = ISFLUSHRX; // flush the FIFO (FCS) } } S1CON &= ~0x03; // delete general RF-flags}
And here is the transmitter code:
#pragma vector=T1_VECTOR__interrupt void Timer1_ISR(void) { T1CTL &= ~0x10; // delete general T1 flag if (T1CTL & 0x80) { // T1CH2 Interrupt every 100 ms T1CTL &= ~0x80; // delete flag ADCCON1 |= 0x40; // ADC Start while(!(ADCCON1 & 0x80)); // wait till conversion is done RFST = ISRFOFF; // turn radio into Idle [1] RFST = ISFLUSHTX; // flush Tx FIFO RFD = 8 + 2 + 2; // write frame length (8 address + 2 data + 2 FCS) RFD = 0x00; RFD = 0x00; RFD = 0x00; RFD = 0x00; RFD = 0x00; RFD = 0x00; RFD = 0x00; RFD = 0x00; // write wrong IEEE destination address (is it MSB first?) RFD = ADCL; // write data RFD = ADCH; // write data RFST = ISTXON; // transmitt FIFO while (!(RFIF & 0x40)); // wait until Tx is done RFIF &= ~0x40; // delete Tx done flag P1 ^= 0x08; // invert the LED at every transmitted frame }}
If address recognition fails, RFSTATUS.FIFOP should remain low (Figure 35 in the datasheet) and the program couldn't leave the line
while (!(RFSTATUS & 0x04)); // wait until the whole frame has been received (RFSTATUS.FIFO)
but it does! Why? Could anybody help me?
Thanks a lot
mario
Should I include a Frame Control Field and a Data Sequence Number on my own, to get the address recognition to work? (The first byte of the address has to be the fourth within the MPDU???)
Hi,
I'm building now my own IEEE802.15.4 compatible frame structure. But now every single frame is rejected even when I send broadcast messages. Here ist my frame:
0B length field (11 byte)20 20 frame control field (data frame, no frame pending, no ack, not intra-PAN, short dest. address, no source address)00 sequence numberFF FF destination PAN (broadcast)FF FF destination short address (broardcast)78 0E data14 EA frame check sequence
This frame is rejected even though it's a broadcast frame. What am I doing wrong? Could somebody help me?
Mario,
Did you solve your porblem? Because it seems that I have the same problem too. Please let me know.
Eka
Yes, I solved it.
The byte-order in the frame-control-field has to be little endian and the bit-order MSB first. In the 802.15.4-standard is figured the whole FCF-word in LSB-first. The right field-order for the TI-SoCs has to be:
byte1: length (including FCF, SN, Addresses, data-length, FCS)
byte2: FCF1 (reserved(7), PAN ID Compression(6), Ack. Request(5), Frame Pending(4), Security Enabled(3), Frame Type(0-2))
byte3: FCF2 (Source Adressing Mode(6-7), Frame Version(4-5), Dest. Addressing Mode(2-3), reserved(0-1))
...followed by Sequence-Number, Addresses, Data
My old and wrong frame:
The corrected frame:
0B length field (11 byte)01 08 frame control field (data frame, no frame pending, no ack, not intra-PAN, short dest. address, no source address)00 sequence numberFF FF destination PAN (broadcast)FF FF destination short address (broardcast)78 0E data(14 EA frame check sequence) not to do on your own.
Hope this helps. ...if not, feel free to ask here. My system is running meanwhile.
What a strange way to document this FCF! I still don't get the point why they did it in thisway, do you?
Anyway, I will try it your way and let see what I can come up with. But I have one question, PANID consists of 2 bytes, so does short address. Which formatting is correct for them in the 802.15.4 frame?
PANID[15...0] = PANIDH {7..0} + PANIDL [7..0]
or
PANID[15..0] = PANIDL [7..0] + PANIDH [7..0]
or what?
Both are wrong. You have to leftshift the high-byte.
int PANID = (int)PANIDH << 8 | PANIDL;
PANID := PANIDH7, PANIDH6, PANIDH5, PANIDH4, PANIDH3, PANIDH2, PANIDH1, PANIDH0, PANIDL7, PANIDL6, PANIDL5, PANIDL4, PANIDL3, PANIDL2, PANIDL1, PANIDL0;
When PANIDH = 0xBE and PANIDL = 0xEF the PANID = 0xBEEF.
When you send the PANID (or all other addresses), you have to do it in little endian byte order:
RFD = length;RFD = FCF1;RFD = FCF2;RFD = SN;RFD = Destination PANIDL;RFD = Destination PANIDH;RFD = Destination SHORTADDRL;RFD = Destination SHORTADDRH;RFD = Source PANIDL;RFD = Source PANIDH;RFD = Source IEEEADDR0;RFD = Source IEEEADDR1;RFD = Source IEEEADDR2;RFD = Source IEEEADDR3;RFD = Source IEEEADDR4;RFD = Source IEEEADDR5;RFD = Source IEEEADDR6;RFD = Source IEEEADDR7;.....
OK, got it Mario! It seems to work fine right now. Do you use the AUTOACK feature within your radio stack?
Fine! :)
Yes, I'm using it. It saves some developing and cpu time.
I agree with you that it saves a lot of cpu cycle, but I wonder how you manage retries if somehow the destination is out of range. How many microseconds is your (safe) waiting time, considering backoffs time, collision avoidance, etc.
Thanks,