• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 1215 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.

Program behaves differently when debugging (IAR Workbench)

Paul Klapperich
Prodigy 170 points

I'm using the ez4300-RF2480 kit and a slightly modified ZASA demo app. There's one key location that, if I set a break point there, allows the application to run flawlessly. However, if I don't, the application fails under certain conditions. Here's the steps:

1. Modify the application to tick on 1ms timerA interrupts instead of the default 1s. This includes adding "000" to all the timing constants, which need to request ms ticks instead of sec ticks from halTimerSet( ... ). Set APP_DATA_CNF to FALSE.

2. Modify mtTx( ... ) to filter for "SRCE_REPORT" packets (0x0001) and interpret data as ASCII. Perhaps not important, but I set the baud to 115200 and have it wired through my own RS232 driver.

3. Set "APP_REPORT_INTERVAL 100" to cause the source devices to transmit data ever 100ms instead of the default 10sec. This is where the problems start. As low as 250ms seems to work pretty reliably if you don't continue to step 4.

4. In "AppExecHost()" set a breakpoint on the line for "appSrceData()". This is the first time appSrceData() is executed. Subsequent times run from appExecHal() due to the HAL_EVT_TIMER_APP flag that was just enabled in AppExecHost().

Run in debug mode with hardware breakpoints and only the breakpoint in line 4. When the program breaks, press F5 to resume. Note the green LED on the sink (coordinator) and red LED on the source blink approx every 100ms (104ms in my case). You should also see data streaming to hyperterminal if you're connected. You can even power off the source and power it back on. What's it's re-established the network it will immediately begin receiving packets at a rate of 10Hz..

5. Clear the breakpoints and reset the source device. Initialize as normal, either disconnected from the computer or in debug mode without the breakpoint mentioned in 4.

The device will connect and the red LED on the source will flash at a rate of about 10Hz, but the green LED on the sink (coordinator) will only blink ONCE. Only the first packet streams out the UART to hyperterminal as only the first packet made it through for some reason.

So there's the big question. Why does it work in 4 (with the breakpoint) but not in 5 (without the breakpoint). Does the zaccel have some "settling time" after initial configuration before you can send packets? But that doesn't seem right, as the first packet makes it through (or, if not the first, a packet early on) but none of the others do. But where else could the problem be located?

--Paul

 

Edit An alternate breakpoint location that provides valid behavior is on "appSetPoll();" in appExec().

  • 0
    Prodigy 160 points

    end devices need a transfer time for protocol, are you quite sure 100 mS its enough time to receive a frame from an end device, how many ED's are you using? and how long is each frame?

    are you sure that your coordinator is fast enough to send data to PC in 100 mS with no data bytes lost coming from end devices??

  • 0 in reply to ilogic
    Prodigy 170 points

    So far just 1 end device, and I have a payload of 2 bytes (temperature and battery voltage). Even with overhead from the Zigbee protocol itself, this should only be about a dozen bytes, which should easily fit in 100ms at 250kbps.

    The coordinator is running the same software and same target board as the end device (MSP430F2224 with Zigbee Accel chip). As I said in my initial post, everything works perfectly with the breakpoint in position. The program stops at the breakpoint, I press F5, and packets stream to the PC at 10/second. If I don't set the breakpoint, the end device blinks the green LED at 10Hz, signalling that it should be transmitting, but the coordinator doesn't seem to receive any. Were it a throughput issue, I don't think it would function when the breakpoint is present.

    I've actually found that it functions fine if I don't run the "appSetPoll()" function. This sends the ZB_NV_POLL_RATE and ZCD_NV_RESPONSE_POLL_RATE commands to the CC2480 Zigbee Accelerator. Since I have APP_DATA_CNF set to FALSE (end-to-end acknowledgments disabled), this would normally set both of these poll rates to 0, disabling them. I believe the problem I'm experiencing is related to the functioning of the Z-Accel. Probably there's a response I need to wait for that the demo code currently doesn't, and the breakpoint delay allows enough time to transpire. Not running appSetPoll() must also delay communication with the Z-Accel long enough, (or perhaps the issue is related to the reset issued in appSetPoll?)

     

  • 0 in reply to Paul Klapperich
    Prodigy 160 points

    hi Paul...

    i've been working with ZASA software in order to build my own control software for cc2480, and your settings are all right.. however...  i think your problem comes from a timing issue.

    have you tried to put a delay just before to start data transmision to PC??

    when using no breakpoints.. state machine send first data frame before it doesn't receive?, with breakpoint, program reaches mtTx function (RPC response or zigbee polling complete in  zaccel.C), so it is possible, that software works well til that point, for the first time it receives data from end device

     

     

**Attention** This is a public forum