Before I begin, I'm using a port of SimpliciTI v1.0.5 for CCE. I don't know if frequency agility was fully operational for that version. If not, I suppose I can just wait until SimpliciTI v1.1.0, and I'll port my code then.
The function nwk_scanForChannels in nwk_freq.c is used by end devices to locate the frequency channel on which the AP exists. The end device sequentially broadcasts packets on all its frequency channels and listens for the AP's reply. If it hears a reply, and already knows its own AP's address, it checks to make sure that the source address of the reply is that of its known AP address.
I have verified that the AP is hearing the ping requests and is sending ping replys. I have also verified that the ED is receiving these ping replys. However, when it goes to check whether or not the source address is that of its known AP, it fails. The ping reply has a source of address of {0, 0, 0, 0}. For some reason the AP doesn't seem to be inserting its source address into the reply. Is there a known reason for that?
As another side issue, the code on the ED doesn't check to make sure that the radio is on (i.e. receiver on, not simply awake) before it writes out the the ping request. It pings, then verifies that it will actually be able to hear the ping reply, should one occur. I suppose it's pretty good bet that the ED code will easily execute before the AP is ever able to send a reply. That so?
My problem was caused by stack overflow. I had just recently increased the size of my SimpliciTI data packets.
The stack overflow caused corruption of the variable sMyAddr in nwk_frame.c, causing the AP to report its own address as {0, 0, 0, 0}.
Grifcj,
Could you post the original and new stack sizes for everyone as reference?
Thanks!
Derek
Here's the important part of the memory map generated by the linker that WORKS. If you're not familiar, the .bss section stores variable and .stack section, of course, contains the stack. For the MSP430F2274, RAM starts at HEX 0x200 and ends at 0x600 (1 kb ). My stack is 128 bytes (as set by a linker directive) and reserves space down to 0x580 (128 decimal equals 0x80, so 0x600 - 0x80 = 0x580).
section page origin length input sections-------- ---- ---------- ---------- ----------------
.bss 0 00000200 00000271 UNINITIALIZED 00000200 000001a4 nwk_QMgmt.obj (.bss) 000003a4 00000030 mrfi.obj (.bss) 000003d4 00000030 nwk.obj (.bss) 00000404 00000027 nwk_join.obj (.bss) 0000042b 00000001 nwk_api.obj (.bss) 0000042c 00000014 EDInterface.obj (.bss) 00000440 0000000b nwk_link.obj (.bss) 0000044b 00000001 nwk_mgmt.obj (.bss) 0000044c 00000009 LaptopInterface.obj (.bss) 00000455 00000009 nwk_globals.obj (.bss) 0000045e 00000008 nwk_frame.obj (.bss) 00000466 00000004 rts430.lib : _lock.obj (.bss) 0000046a 00000004 : exit.obj (.bss) 0000046e 00000002 nwk_freq.obj (.bss) 00000470 00000001 nwk_ping.obj (.bss).stack 0 00000580 00000080 UNINITIALIZED 00000580 00000002 rts430.lib : boot.obj (.stack) 00000582 0000007e --HOLE--
This is a memory map from a build that had stack overflow. Notice that the queues in nwk_QMgmt increased dramatically. I had increased the maximum app payload to 46 bytes and have an input and output queue 5 frames long. For reference, the app payload on the previous working build was 26 bytes with each queue at 5 frames long.
.bss 0 00000200 0000034d UNINITIALIZED 00000200 0000026c nwk_QMgmt.obj (.bss) 0000046c 00000044 mrfi.obj (.bss) 000004b0 00000030 nwk.obj (.bss) 000004e0 00000027 nwk_join.obj (.bss) 00000507 00000001 nwk_api.obj (.bss) 00000508 00000014 EDInterface.obj (.bss) 0000051c 0000000b nwk_link.obj (.bss) 00000527 00000001 nwk_mgmt.obj (.bss) 00000528 00000009 LaptopInterface.obj (.bss) 00000531 00000009 nwk_globals.obj (.bss) 0000053a 00000008 nwk_frame.obj (.bss) 00000542 00000004 rts430.lib : _lock.obj (.bss) 00000546 00000004 : exit.obj (.bss) 0000054a 00000002 nwk_freq.obj (.bss) 0000054c 00000001 nwk_ping.obj (.bss).stack 0 00000580 00000080 UNINITIALIZED 00000580 00000002 rts430.lib : boot.obj (.stack) 00000582 0000007e --HOLE--
I was able to send one SimpliciTI message successfully, but after that, stack overflow would occur. So, the stack must have grown down past 0x53a to rewrite the address variable in nwk_frame.c somewhere around that time.
I didn't take note of exact stack sizes, although I suppose you might do that by watching the SP register. Someone is welcome to persuade me that the effort is worth it to get that information, but for me, I concluded that the stack was getting too big, so I reduced some of my variables' sizes. And now my access point works as it should.
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.