• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 420 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems with FREQUENCY_AGILITY and nwk_scanForChannels; SimpliciTI v1.0.5

grifcj
Intellectual 360 points
Other Parts Discussed in Thread: SIMPLICITI, MSP430F2274

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?

  • 0
    Intellectual 360 points

    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}.

  • 0 in reply to grifcj
    Intellectual 490 points

    Grifcj,

     

    Could you post the original and new stack sizes for everyone as reference?

     

    Thanks!

    Derek

  • 0 in reply to DerekC
    Intellectual 360 points

    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.

    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------

    .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.