• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 912 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.

Hard Fault Error with New 2650 Project and IAR

Mike Marks
Prodigy 140 points
Other Parts Discussed in Thread: CC1310

I'm working on a new project on the 2650 evaluation module and the Smart RF06 evaluation board with IAR for ARM.  I downloaded the CC26xxware_2_21_03_15980 to get the necessary library and startup files.  The startup file is startup_iar.c which executes as soon as I reset, and includes the functions trimDevice() and then a call to __iar_program_start().

As soon as I try to run the first executable line in main(), I get sent to FaultHandlerISR().  The first line is a call to the library function GPIODirModeSet() to set two GPIO pins to outputs.  Looking at the registers, I see that in CFSR in the system Control block has bits PRECISERR and BFARVALID set.  Looking at CPU registers, IPSR is set to 0x00000003 indicating a hardware fault.

My guess is that there is something simple that needs to be set up or initialized that I am missing.  Any hints on where to look?

The project will eventually be developed on the CC1310, but I suspect this startup issue is part of the ARM core.

Thanks,

Mike Marks

  • 0
    Prodigy 140 points

    Problem solved:

    Before attempting to configure the GPIO module, it must first be powered on and have its clock enabled. This was confusing to me coming from the MSP430 where all peripherals are ready to use at reset.  For the CC26xx, that is not the case.

    Use the driverlib function PRCMPowerDomainOn(PRCM_DOMAIN_PERIPH) to turn on; spin and wait until the status retrieval function PRCMPowerDomainStatus(PRCM_DOMAIN_PERIPH) does not return PRCM_DOMAIN_POWER_OFF, and then call the following:

    PRCMPeripheralRunEnable(PRCM_PERIPH_GPIO);

    PRCMLoadSet();

    Now the GPIO pins can be configured without getting a bus error.

    Thanks to the anonymous TI contact who responded back to our local Arrow office for the clue on tracking this down.  I wanted to have a simple way to enable and use the GPIO port without bringing in the more complex PIN library and corresponding RTOS functions since our application will not use an RTOS.

  • 0 in reply to Mike Marks
    TI__Expert 6995 points

    Hi Mike, 

    If your application will not use an RTOS (or specifically TI RTOS), there's a good deal of housekeeping that needs to be taken care of. Both power management, clocks and RF setup are dependent on software to operate correctly. 

    Peder

  • 0 in reply to Peder
    Prodigy 140 points

    Peder,

    Thanks for the reply. Our project will ultimately be used on the CC1310 with a proprietary radio scheme for communication in the 403-405 MHz MICS band. We won't need the established stacks like BLE, Zigbee, or 6LowPan.

    It does seem like the CC13xx/26xx family has a lot more to keep straight than the MSP430 family.

    --

    Mike

  • 0 in reply to Mike Marks
    TI__Expert 6995 points
    Hi Mike,
    Yes, the CC13xx/CC26xx has a significantly more flexibility in power management and the radio than previous generation. To make it easy to use, we really depend on the intelligence built into the software drivers. I would really recommend you consider running your application as a thread in TI RTOS. It automatically takes care of putting the device into the lowest possible power mode at any given time, starts clocks and has powerful drivers for the radio and other on-chip peripherals that will save you time when developing.

    Peder
  • 0 in reply to Peder
    Prodigy 140 points
    Thanks in. We're early enough in the project that we can go either way, so I will download TI-RTOS and take a good look at the documentation.
    --
    Mike