RTOS/CC2640R2F: Event issue/bug

alexbec

Part Number: CC2640R2F
Other Parts Discussed in Thread: LAUNCHXL-CC2640R2, SYSBIOS

Tool/software: TI-RTOS

Hi,

i'm using events module to post different button states from GPIO ISR Callback Fxn's to a predefined user main task. I've used GPIO.h library and interrupt are configured to occure on both edges.

I followed instructions from TI-RTOS Kernel User's Guide (SPRUEX3T) p. 115 and implemented runtime configuration.

For debounce logic I'm using Clock_module, which so far works very good. Parallel another clock instance for long push button action (5s push) is running.

All in all there are 3 button states:

#1: Falling edge --> Button wasn't pushed and is pushed now (after debounce time). An event for falling edge is posted and an initialisation routine is processed in my task.

#2: Short push --> Button was pushed and is released now. An event for short push is posted and a defined mode is processed.

#3: Long push --> Button still pushed after 5s clock instance overflow . An event for long push is posted and another defined mode is processed. post_Event is done in 5s clock overflow Callback Fxn.

Once #2 or #3 event was posted, events aren't allowed anymore (no disturbance allowed because of measurement of sensor data), so Event_delete(&myButtonHandle) is called.

In main user task another clock instance is used for waiting operations.

For safety and redundance resasons i tried to disable interrupts by using GPIO_disableInt(MYBUTTON), so that GPIO Callback Fxn should be never called. Unfortunately GPIO interrupt isn't disabled and Callback Fxn is called anyway. Therefore i declared a global status flag for disabling further GPIO interrupt handling.

After measurement is done peripherial devices are shutdown and events are reinitialised, so pending on events by using even_pend() is possible and allowed again at next loop iteration.

Now the problem is that the processor hangs up, when long push action #3 (only happens in this mode) was successfully processed and pending again on button events in next loop iteration.

When the button is pushed at this stage one of the following is happening,

-) Processor hangs up - disassambly:

-) IAR hungs up without error message

-) IAR hungs up with following error message:

I also tested our battery powered device "Standalone". Short push mode #1 is working fine, but once long push mode #3 occured cpu hangs up as well at next iteration.

What could cause the hang up of the CPU?

Further information:

simplelink_cc2640r2_sdk_1_40_00_45

IAR-Version: 8.11.2.13606

Debugger & Programmer: TI XDS110 from LAUNCHXL-CC2640R2 board

XDS Tools: xdctools_3_50_02_20_core

over 8 years ago

0 RachelP over 8 years ago

TI__Genius 12815 points

Hi alexbec,

Are you running on a custom board or on the CC2640R2 LaunchPad? Did you start from the gpiointerrupt sample application or a different project?

0 alexbec over 8 years ago in reply to RachelP

Prodigy 200 points

Hi RachelP,

i'm using a custom board. I started from simple_peripheral example, because bluetooth is needed later on.

0 RachelP over 8 years ago in reply to alexbec

TI__Genius 12815 points

Hi alexbec,

Have you reviewed the CC26xx HW Design Checklist and the CC26xx BLE HW Troubleshooting & Bring Up guides on the TI BLE Wiki?

0 alexbec over 8 years ago in reply to RachelP

Prodigy 200 points

Hi Rachel,

sry for answering late. I was busy doing other tasks.

RachelP said:

Have you reviewed the CC26xx HW Design Checklist and the CC26xx BLE HW Troubleshooting & Bring Up guides on the TI BLE Wiki?

Yes, i already did this and from HW point of view everything's OK.

Well, now i got really deep in this. It seem to be related to HWi's - see following message from ti.sysbios.BIOS error ROV:

To get more details from this exception, i opened ti.sysbios.family.arm.m3.HWi ROV.

Because IMPRECISERR appeared, i followed instructions from:

http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_50_00_58/docs/blestack/ble_user_guide/html/debugging/cpu_exceptions.html

int main()
{

  //FOR DEBUGGING HARDFAULT
  //TODO: REMOVE - produces much overhead
  HWREG(CPU_SCS_BASE + CPU_SCS_O_ACTLR) = CPU_SCS_ACTLR_DISDEFWBUF;

This enabled HWi exception ROV to get more details from the HWi exception:

This happens randomly at different positions in my routine - see following snippet:

This really seem to happen randomly. There is no deterministic behaviour.

Any other suggestions?

0 alexbec over 8 years ago in reply to alexbec

Prodigy 200 points

Hi,

i solved the problem, finally...

This was a memory issue. I forgot to free an object, which was allocated in heap memory at the end of the iteration. At the beginning of the iteration this objects are reallocated. After 2 or 3 iterations i ran out of memory, which further caused the randomly HWi exceptions.

Best regards,
Alex

Bluetooth®︎

Bluetooth forum

RTOS/CC2640R2F: Event issue/bug