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.

CC2530 Initialization Problem

Other Parts Discussed in Thread: CC2530

Hi everyone,

I have a CC2530 on a custom PCB. Unfortunately, we seem to be stuck in the "Hello Word" stages as we cannot get the LEDs to turn on.

Here's our code:

int main (void)
{

P1DIR = LED1_MASK | LED2_MASK; 

for(;;)
{
LED1_ON(); // Turn LEDs on
LED2_ON();
delayMs(100);

LED1_OFF(); // Turn LEDs off
LED2_OFF();
delayMs(100);
}

}

The macros just basically set P1_1 or P1_0 to 1 or 0.

Are there any other registers we need to set? Are we missing something?  

One thing to note is that if we generate a .hex file from IAR and load it through Flash Programmer (erase, program and verify), we get a hex verification error.  So it is possible that the code did not download properly and that there is a hardware issue.  Any insights on this would be helpful but we'd preferably like to rule out software mistakes as well.

Thanks!

  • It is likely that you have a problem with the connection between the debugger and the CC2530. This could be anything from soldering issues (pins not properly soldered, lacking connection of the solder pad under the chip), grounding, decoupling of the voltage signals or signal integrity problems. I assume you're using the CC Debugger to program/debug the device. Have you checked the recommendations in the CC Debugger's User's Guide?

    You're using IAR Embedded Workbench? Did you get any problems when downloading the code to the device? Are you certain that the code is actually downloaded (and not running from e.g. the simulator? You could also manipulate the registers directly in the register view and try to toggle GPIOs.

  • Hi,

    I dont see any issue in your code as long as you have enabled relevant bits in P1DIR register & your macros are writing to P1_x bits.

    Did you try Flashing from IAR?

    May be you can try once, to select the TI debugger follow this--- Project->Options->Debugger->Driver

  • Hi M,

    Yes we are using the CC Debugger and we do have all the pins connected as per the User's Guide and the green LED on the debugger does turn on.  We are using IAR EW and I don't think we are using the simulator (I checked that TI is selected in the Debugger options and not Simulator).  But to be safe, we tried to also use the Flash Programmer where we did find some verification errors.

    I did not know that we could manipulate the registers directly though.  Can we do this with the minimum Debugger connections, or do we need all the pins of the debugger connected to the chip?

    Some other things we thought of:

    • Do P1_0 and P1_1 source current as output? Or does it sink current?
    • What makes the CC Debugger LED turn green? In other words, how does it determine that there is a connection to the CC2530 and what are the scenarios that would cause it to turn green when the connection is actually faulty?
  • Hi Karthikeyan,

    I've checked that I am turning the correct bits on. Here are the macros:

    LED1_MASK is 0x01

    LED2_MASK is 0x02

    LED1_ON() is (P1_0 = 1)

    LED2_ON() is (P1_1 = 1)

  • Hi Angela,

    You can read and write the device registers directly in IAR by just using the minimum pin connections (i.e. only the debug signals, reset, GND and the target voltage sense pin). Just opne the register view (or memory view) in IAR once you have connected to the target.

    If you say you get verification errors when using the flash programmer, you should definitely check your hardware design thoroughly. Is everything powered correctly? 

    P1_0 and P1_1 are by default set up as input tristate on the chip. Unless you have reconfigured the IO's, they won't source any current.

    As for the status LED on the debugger, it will turn green after a power-on (or reset) if it detects that a known chip is connected to the debug interface (or SPI for a transceiver). The debugger basically sends the GET_CHIP_ID debug command and interprets whatever it gets back from the chip. The chip detect sequence is fairly robust (perhaps too robust) and runs at a low bit rate. It will be able to detect a device even though the interface is flaky.