CC253x chips, dev kit and software revisions

Hi Steve,

Could you please be a bit more specific about *what* does not run any longer. Does the application crash? What happens when you debug/single step you code on the two different versions?

Note that the hardware modifications (on both the chip and USB dongle) should normally not have any impact on the software.

FYI, the CC2531 reference design contains information about modifications from 2.0 to 2.4:

2.0 First official released version.
2.1 Changed routing of power to pin 27, 28 and 29 to improve decoupling and meet ETSI requirement on 4.8spurius emission in RX.
2.2 Changed discrete balun to Johanson to further reduce radiated 4.8GHz spurious when in RX, this made R251 and C251 obsolete hence removed
      Several minor layout changes were needed to accommodate the new balun.
2.3 Changed layout to reduce radiated VCO (4.8GHz) during RX to increase margin for ETSI requirement (-47dBm)
      Added filter on RESET_N to reduce probability of false reset initiated by noise.
2.4 Changed Layout to reduce VCO leackage in RX, added inductor on RBIAS, removed 32kHz crystal

Hi,

The code loops forever during initialisation at mac_mcu.c line 221, in the macro:

  /* start timer */
  MAC_RADIO_TIMER_WAKE_UP();

This is in Z-stack 2.2.0 debugging on a SmartRF05.

I've also tried the Dongle/EndDeviceEBPro application that comes with The Z-Stack 2.3.0 release and it hangs at the same point.

One of our engineers has reported that he can get the old binary to run OK on the new Rev 2.4 CC2531EMK providing he leaves the CC debugger connected.

CHVER on the new device reports 0x22 when on the rev 2.1 device its 0x21. This is what made me this it's a chip revision problem.

The target device will run the sniffer application OK.

Cheers, Steve

Steve,

I think I know what's happening. In the code you are running, you get stuck in a while loop that will wait for Timer 2 to start - the while loop exits when the T2CTRL.STATE bit is set. In your case, this bit will never be set. Notice that the T2CTRL.SYNC bit is set. This means that Timer 2 will start synchronously with an edge on the 32kHz clock (see the user guide, section 20.4).

If you run the standard Z-Stack CC2530 Sample App on the USB dongle, there are a couple of things to note:
- The default platform for this app is the CC2530EM mounted on a SmartRF05EB or SmartRF05BB.
- The CC2530EM has an external 32kHz crystal mounted and the software explicitly sets up the clocks such that the external crystal is used (CLKCONCMD.OSC32K is cleared).
- The CC2531 USB dongle does not have any external 32k crystal

So basically, you wait for a clock edge that will never come, and your application is "stuck".

But why did this work on earlier revisions of the dongle? One of the changes from earlier revs of the dongle was that the footprint and signal routing to an optional 32kHz crystal  were removed. Thus, on old revs of the dongle, when you tell the chip there is an external crystal, you pick up enough noise on these signal stubs to make it appear as though you do have an external crystal and thus causing false synchronization triggers for Timer 2. On newer revisions, you won't get the same noise and no triggers. Similarly, if you ground the signal stubs on earlier revisions, the likelihood of getting these triggers is reduced significantly.

So to conclude, you should modify the code such that you either use the internal 32kHz RC osc or turn off Timer 2 sync (i.e. make sure the code matches your hardware and/or timing requirements).

BTW - you would have detected that you don't actually have the 32k crystal if you had used the Clock Loss Detector feature of the CC253x (see user guide section 5.2).

Hi,

I've modified my code to use the CC2531 version of HAL_BOARD_INIT() from:

.\ZStack-CC2530-2.3.0-1.4.0\Components\hal\target\CC2530USB\hal_board_cfg.h

I have set the following compiler switch on the project build:

OSC32K_CRYSTAL_INSTALLED=FALSE

Calling HAL_BOARD_INIT() on startup now results in setting:

CLKCONCMD=0x80

As far as I can see the 32kHz RC oscillator should now be selected, running and stabilised.

CLKCONSTA=0x80

Unfortunately the Z-Stack code still hangs, as before, during initialisation at mac_mcu.c line 221, in the macro:

/* start timer */

MAC_RADIO_TIMER_WAKE_UP();

Am I missing an additional step? Is there any way to detect if the RC oscillator is running?

Thanks, Steve.

In IAR, there's an option for selecting whether or not to "Stop Timers on Halt". The option is found on the menu line, Texas Instruments Emulator --> Stop Timers on Halt. Does anything change if you turn this on or off?

HI Steve,

Thanks I am able to solve my problem by following your comments.

But the LCD is not displaying the IEEE address properly whereas the green LED is toggling.

I am using the cc2530 discrete module 1.3.1 version with smartRF05 EB and using SE profile of ZSTACk.

Ztool  is not detecting the device.

Can u help me out.