Other Parts Discussed in Thread: LAUNCHXL-CC1352R1
Tool/software:
Hi!
I am currently implementing an application that interfaces the coprocessor in order to communicate with the sensor example (found in the SIMPLELINK-LOWPOWER-F2-SDK v8.30.01.01) with frequency hopping enabled. Both examples running on LAUNCHXL-CC1352R1 boards.
I am following this document to communicate to the coprocessor: TI-15.4-STACK-CoP Interface Guide (I know this link is outdated, but the document remains the same in the latest release of the SDK).
When the sensor starts the communication by sending a command MAC_WS_ASYNC_IND (for the Wi-Sun PAN Advertisement Solicit message). The first bytes sent are listed below.
Here you have a few examples of the messages received by the coprocessor, where DstAddrMode is in bold and italic, followed by the DstAddr in bold and underlined.
| FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, f4, 17, 24, 0, 7, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] } FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, bc, c9, d6, 0, 2, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] } FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 66, 78, cb, 0, 6, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] } |
I have two questions:
1. When the SrcAddrMode and SrcAddr is sent, everything works as expected: I receive SrcAddrMode as 0x03 (ADDRESS_64_BIT) followed by 8 bytes corresponding to the SrcAddr. Nonetheless, the DstAddrMode and DstAddr are filled with zeroes (seems reasonable since the sensor still doesn't know the destination address). The problem is that I couldn't find anywhere in the documentation describing 0x00 as a valid value for an AddrMode, possibly leading parsers to invalidate this field. Is the parser supposed to deal with it? So when an AddrMode is set to 0x00, should I always expect it to be followed by an 8-bytes Addr?
2. In the "Length" field, it says that both SrcAddr and DstAddr are 8-bytes long. Is it true even if the SrcAddrMode and DstAddrMode are set to ADDRESS_16_BIT? Or in this case the length of SrcAddr and DstAddr remain 8 bytes long?
Thank you in advance,
Guilherme Akira