• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 56 subscribers
  • Views 586 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ZigBee stack and cc2538 GPIO issue

Ran Xu1
Prodigy 60 points
Other Parts Discussed in Thread: CC2538, Z-STACK

Hi,

 We are doing some stuff using CC2538 and an external device. The CC2538 is supposed to operate the 2.4GHz network. In the meantime, it also controls the use of external device through SPI interface. A PIN (i.e. pc7) of cc2538 is connected to the external device to allow interrupt from the external device to cc2538. The external device shares the same power source with CC2538 (two AA battery)
The developed software seems ok if cc2538 works with IEEE 802.15.4 stack.
However, when we migrate the software from IEEE 802.15.4 to ZigBee, unexpected problem occurs. If the function of :
ZDApp_event_loop ()
is enabled, the interrupt line, which is pc7, will generate countless interrupt to cc2538, and the system stops working. 
My question is, does PC7 on cc2538 have certain internal relationship with ZigBee stack, and the relationship forbids the use of PC7 as interrupt line when ZigBee stack works?
The development tool I am using is IAR 7.20.1.7307
The Zigbee stack is included Z-Stack Home 1.2.0
Debug tool XDS100V3
When problem occurs, the debug interface stops at 
void FaultISR(void)
which is defined in startup_ewarm.c

Any suggestion is very much appreciated!

 

  • 0
    TI__Mastermind 36375 points

    Ran, 

    I looked at our various reference designs, none of them use PC7 for anything so I doubt the Zigbee stack has any special flags for PC7.

    If the execution lands in FaultISR(void) that actually means the interrupt happened but there where no service routine attached at the time of issuance, therefore the Zigbee stack will error out in its FaultISR().

    I think you need to find where the ISR is defined in your code, enable, connect it to the correct pin and try again.

    Regards,
    /TA

  • 0 in reply to TA12012
    Prodigy 60 points

    Thanks for your reply. The situation is, if I only run with 802.15.4 stack, or run ZigBee without enabling "ZDApp_event_loop ()", the system works well, which means my external device should be connected to the correct line.
    The problem does confuse me as I am unable to have a deep insight of Z-Stack

  • 0 in reply to Ran Xu1
    Genius 3135 points

    Hi, 

    I thought I should just share my experiences concerning the FaultISR() condition. ZStack will direct program execution to this function if you have memory  mis-management issues:

    If you are using osal_mem_alloc(), osal_mem_free(), MT_TransportSend(), MT_TransportAlloc(), or any array index which is incremented by your code in some way, make absolutely sure that your code is not unintentionally trying to access undeclared memory, or memory beyond a specified range, either by reference, or directly or even just trying to read such a location. 

    We had big problems with our project, where we constantly ended up at FaultISR(),  we eventually discovered many problems with our memory management, sorted them out, and this resolved our issue. We use the above mentioned functions extensively, and all the problems involved them!

    Use IAR's memory map extensively to make sure that the memory is doing what you expect at the expected location.

    Hope this helps.