RF230BB: Delete the redefine RF230_CONF_FRAME_RETRIES

Since the define of RF230_CONF_AUTORETRIES have the same
means with RF230_CONF_FRAME_RETRIES. So unity the define.

Signed-off-by Zhong Hongbo <bocui107@163.com>
Solve FreakZ issue:Router cannot Join Network Started by Coordinator

http://www.fuxis.org/zblog/post/10.html

Issue replay
Program RavenStick#1 with all debug swicthes enabled.
Plug RavenStick#1 and run putty or anyother alternate terminal tool for Command-line interface access.
Input "zs c" to start a ZigBee network.

Program RavenStick#2 with default firmware (that is FreakZ_v075).
Plug RavenStick#2 and run putty or any other alternate terminal tool for Command-line interface access.
Input "zs" to start a router. This stick will try to scan channels(actually only one channel will be looked since the channel mask is configed as following in "freakz/constant.h".

From MAC layer perspective, the router should send "Beacon Request" command frame to locate exist coordinators within its POS.
On receipt of this "Beacon Request" command frame, the coordinator should reply with a "Beacon" frame to indicate its Pan description.

The issue is because MAC header debug information printing work takes too long time (approx. 1 second), the router will not receive the coordinator's "Beacon" frame as what we find with original firmware.
It will display the error information as following.

        /-----------------/
    CMD: zs
    /-----------------/
    ZDO_CMD_ZDO_START: Starting as a Router.
    ZDO_START
    MAC_HW - New channel set: 0B

    ********** FreakZ Main Menu **************
    *                                        *
    ******************************************
    FreakZ>> NWK_DISC_CONFIRM
    ZDO_DISC_CONF: Can't find a network to join.
    ZDO_DISC_CONF: Cleaning up and going to idle.
    MAC_EVENTHANDLER: Rx event occurred.

In coordinator's side, we can get more details (because we turn on all debug switches). As we can see, "beacon" frame is sent out as expected.

    MAC_EVENTHANDLER: Rx event occurred.

    <INCOMING>
    DUMP_MAC_HDR: FRAME TYPE     = COMMAND.
    DUMP_MAC_HDR: PENDING_FRAME  = FALSE.
    DUMP_MAC_HDR: DSN            = 5B.
    DUMP_MAC_HDR: ACK REQ        = FALSE.
    DUMP_MAC_HDR: PAN ID COMPR   = FALSE.
    DUMP_MAC_HDR: DEST ADDR MODE = SHORT.
    DUMP_MAC_HDR: SRC ADDR MODE  = NONE.
    DUMP_MAC_HDR: DEST PAN ID    = FFFF.
    DUMP_MAC_HDR: DEST ADDR      = FFFF.
    DUMP_MAC_HDR: SRC PAN ID     = 5340.
    DUMP_MAC_HDR: SRC ADDR       = NONE.

    DUMP_MAC_CMD: CMD ID         = BEACON REQUEST.
    MAC: MAC Beacon Request Command Received.

    DUMP_MAC_HDR: FRAME TYPE     = BEACON.
    DUMP_MAC_HDR: PENDING_FRAME  = FALSE.
    DUMP_MAC_HDR: DSN            = 38.
    DUMP_MAC_HDR: ACK REQ        = FALSE.
    DUMP_MAC_HDR: PAN ID COMPR   = FALSE.
    DUMP_MAC_HDR: DEST ADDR MODE = NONE.
    DUMP_MAC_HDR: SRC ADDR MODE  = SHORT.
    DUMP_MAC_HDR: DEST PAN ID    = NONE.
    DUMP_MAC_HDR: DEST ADDR      = NONE.
    DUMP_MAC_HDR: SRC PAN ID     = 162D.
    DUMP_MAC_HDR: SRC ADDR       = 0000.

Issue Debug
So what's wrong, if you don't have any sniffer device you have to guess. Luckily I do have one. What's that? Oh... It's still ravenstick.
Yes, I program the ravenstick with Atmel's original firmwarer image and install AVR Wireless Service application on Windows platform.
That's all about my sniffer used for issue debugging. You can use what ever you have to capture the data transfered in air. Remember to check
the correct channel(for FreakZ test, the default channel is 0x0B) before you start capturing.

This is what I got from the sniffer. Please notice the time values red marked.
Open
Sniffer Data
The first pair is a good example when play with a coordinator programmed with debug switches off.
The last pair is captured when the issue found.
Issue Solve
Since we know the issue root cause, let's check the code.
It's even better that we look the explanation in IEEE802.15.4-2003 specificaton first.
There is a "Scan Duration" definition on page 145. The words are

The device shall then enable its receiver for at most [aBaseSuperframeDuration *
(2^n + 1)] symbols, where n is a value between 0 and 14.

Search codes related in FreakZ and then we can find the following in "freakz/constants.h" line 112.

It should work because we know aBaseSuperframeDuration is approx. 16ms (see line 74~77). Then the duration should be almost
16 seconds!

But why did it fail? Check the code more deeply then I got something in "freakz/mac/mac.h".

/// Calculate amount of time to perform a scan
This is not compliant with the spec says. There is a extra ">>6" I guess is for original author quick debug purpose.
Remove that and make it seems like below.

/// Calculate amount of time to perform a scan

Solution Verification
Program Ravenstick#1 with the modifications above and execute the operations just like we did in "Issue Replay" section.
And we will make the router join the network successfully.

Wait a moment! Do you see there is a big delay between the beacon received from coordinator and the next "associcate request" frame sent out?
Yes, that is the scan duration we fixed to correct value 16 seconds! But that seems too long for debug and actually we don't need that long for issue solving.
As we can see from the sniffer, the coordinator introduces a delay with approx. 1seconds. So we can change the DEFAULT_SCAN_DURATION
from 10 to 7 and then the delay will be reduced to 2 seconds.
Change codes in "freakz/constants.h" line 112.
rf230bb: Adjust the code format

Signed-off-by Zhong Hongbo <bocui107@163.com>