CC2640: Minimizing sleep current when using I2C and UART

If you were to revert to the version of your code that did not use I2C/UART and could easily enter LPM, you would not observe this behavior?  And the behavior does not occur on the unoptimized I2C/UART version which consumes higher power?  Can you decrease any other stacks so that you can have room to increase the Program stack? 

I think this thread may have gone beyond my expertise and thus a new thread would allow another expert to give more in-depth assistance.

Regards,
Ryan

Ryan Brown1 said:

If you were to revert to the version of your code that did not use I2C/UART and could easily enter LPM, you would not observe this behavior? 

The behavior is not observed with my code prior to I2C/UART addition to the code. This much older code (~18 months ago) wakes up from <10ua sleep and it does not execute a re-boot through main.c code since RTC and RAM variables persist after wakeup.

Ryan Brown1 said:

And the behavior does not occur on the unoptimized I2C/UART version which consumes higher power? 

My last distributed unoptimized I2C/UART version of my code which was tested for many months before this month+ long topic, does not have this behavior either but I have been unable so far to pinpoint the exact change in the last month or so that caused this new behavior.

Ryan Brown1 said:

Can you decrease any other stacks so that you can have room to increase the Program stack?

Sorry, I incorrectly stated that Program.stack sets the IdleTask stack size. (I have edited my previous post to correctly refer to it as the IdleTask stack).

I have done a lot of research to figure how to increase the IdleTask stack size and still have not found out how to do this.

Do you know how to  increase the IdleTask stack size?

I will start a new topic soon and put a link to it in this topic.

What do you think of this as a title for my new topic "IdleTask stack overflows only AFTER waking up from a sleep/standby state"?

Thanks,

Dale

Task.idleTaskStackSize in the configuration (.cfg) file.

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/tirtos/sysbios/docs/Bios_User_Guide.pdf 
https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/tirtos/sysbios/docs/cdoc/index.html 

You've got a better title than any alternative I can think of.

Regards,
Ryan

Thanks, I would have found that if workspace searching had an option to not be case sensitive ;)

Dale

We it looks like I have to come up with a better new topic title now ;)

I was able to rearrange to stack sizes (except for ICall_taskEntry stack which also still alludes me as to how to change its's stack size) and now, after waking from sleep and stepping through code, I have no more stack errors:

BUT, the code is stuck in a loop going through the above 4 lines 1001b180 to 1001b188 repeatedly forever (or at least as many times I have paused execution and pressed F5 till my fingers got sore.

There may be these other few clues for someone in ROV but I do not understand their relevance:

Can you help drill down more or suggest a new topic name?

Thanks,

Dale

The BLE-Stack User's Guide has some information on Hwi exception parsing which you could use to get further details on what is transpiring.

Regards,
Ryan

Thanks, actually I already have a  void execHandlerHook(Hwi_ExcContext *ctx) function in my code and it is not being triggered with my current behavior.

During my behavior (4 lines looping), here is the Exception tab of hwi in ROV:

NOCP is hard to find info on, one person suggests it is defined as no coprocessor found error but also states that it is used as a catch all sometimes...

Is "Hard Fault: FORCED: USAGE: NOCP only AFTER waking up from a sleep/standby state" the appropriate new topic title?

Thanks,

Dale

Are your .cfg settings using BIOS in flash or ROM?  And have you tried debugging while adding RTOS ROM symbols? https://www.ti.com/lit/swru393 

Regards,
Ryan

Ryan Brown1 said:

Are your .cfg settings using BIOS in flash or ROM?

I do not know, how can I tell?

EDIT: My cc2640.cfg is set up for BIOS in ROM

Ryan Brown1 said:

And have you tried debugging while adding RTOS ROM symbols?

The ROM symbol file was not in the location in that document, I loaded it from C:\ti\tirtos_cc13xx_cc26xx_2_20_01_08\products\bios_6_46_01_38\packages\ti\sysbios\rom\cortexm\cc26xx\golden\CC26xx\rtos_rom_syms.xem3

The below disassembly listing with ROM symbols added starts with the first ROM symbol a little before my 4 line loop at lines 1001b180: to 1001b188: and goes to 1001b364: where the 4 line loop sometimes exits to (yes it is not an endless loop as I previously stated):

          ti_sysbios_knl_Task_schedule__I():
1001b174:   B570                push       {r4, r5, r6, lr}
1001b176:   4C11                ldr        r4, [pc, #0x44]
1001b178:   2600                movs       r6, #0
1001b17a:   25F8                movs       r5, #0xf8
          $C$L37:
1001b17c:   8126                strh       r6, [r4, #8]
1001b17e:   E001                b          $C$L39
          $C$L38:
1001b180:   F000F8F0            bl         #0x1001b364
          $C$L39:
1001b184:   6860                ldr        r0, [r4, #4]
1001b186:   2800                cmp        r0, #0
1001b188:   D0FA                beq        $C$L38
1001b18a:   6860                ldr        r0, [r4, #4]
1001b18c:   69A3                ldr        r3, [r4, #0x18]
1001b18e:   6962                ldr        r2, [r4, #0x14]
1001b190:   FAB0F080            clz        r0, r0
1001b194:   EBA501C0            sub.w      r1, r5, r0, lsl #3
1001b198:   1858                adds       r0, r3, r1
1001b19a:   4282                cmp        r2, r0
1001b19c:   D20A                bhs        $C$L40
1001b19e:   6922                ldr        r2, [r4, #0x10]
1001b1a0:   6160                str        r0, [r4, #0x14]
1001b1a2:   F001F897            bl         #0x1001c2d4
1001b1a6:   4601                mov        r1, r0
1001b1a8:   6121                str        r1, [r4, #0x10]
1001b1aa:   F1020010            add.w      r0, r2, #0x10
1001b1ae:   3110                adds       r1, #0x10
1001b1b0:   F001F8A4            bl         #0x1001c2fc
          $C$L40:
1001b1b4:   8920                ldrh       r0, [r4, #8]
1001b1b6:   2800                cmp        r0, #0
1001b1b8:   D1E0                bne        $C$L37
1001b1ba:   BD70                pop        {r4, r5, r6, pc}
          $C$CON34:
1001b1bc:   0100                lsls       r0, r0, #4
1001b1be:   2000                movs       r0, #0
          ti_sysbios_family_arm_m3_Hwi_Module_startup__E():
1001b1c0:   B570                push       {r4, r5, r6, lr}
1001b1c2:   2020                movs       r0, #0x20
1001b1c4:   F3808811           .word       0x8811f380
1001b1c8:   4A0D                ldr        r2, [pc, #0x34]
1001b1ca:   6991                ldr        r1, [r2, #0x18]
1001b1cc:   6950                ldr        r0, [r2, #0x14]
1001b1ce:   F04F35FF            mov.w      r5, #-1
1001b1d2:   F0200007            bic        r0, r0, #7
1001b1d6:   1809                adds       r1, r1, r0
1001b1d8:   480A                ldr        r0, [pc, #0x28]
1001b1da:   6015                str        r5, [r2]
1001b1dc:   3908                subs       r1, #8
1001b1de:   6804                ldr        r4, [r0]
1001b1e0:   6111                str        r1, [r2, #0x10]
1001b1e2:   2C00                cmp        r4, #0
1001b1e4:   DD0A                ble        $C$L565
1001b1e6:   2600                movs       r6, #0
          $C$L564:
1001b1e8:   2000                movs       r0, #0
1001b1ea:   4631                mov        r1, r6
1001b1ec:   F000FAE8            bl         #0x1001b7c0
1001b1f0:   2100                movs       r1, #0
1001b1f2:   F7FFF891            bl         #0x1001a318
1001b1f6:   1C76                adds       r6, r6, #1
1001b1f8:   1E64                subs       r4, r4, #1
1001b1fa:   D1F5                bne        $C$L564
          $C$L565:
1001b1fc:   4628                mov        r0, r5
1001b1fe:   BD70                pop        {r4, r5, r6, pc}
          $C$CON631:
1001b200:   0144                lsls       r4, r0, #5
1001b202:   2000                movs       r0, #0
          $C$CON633:
1001b204:   0494                lsls       r4, r2, #0x12
1001b206:   0000                movs       r0, r0
          ti_sysbios_heaps_HeapMem_getStats__E():
1001b208:   B570                push       {r4, r5, r6, lr}
1001b20a:   4605                mov        r5, r0
1001b20c:   6928                ldr        r0, [r5, #0x10]
1001b20e:   460C                mov        r4, r1
1001b210:   6020                str        r0, [r4]
1001b212:   2000                movs       r0, #0
1001b214:   6060                str        r0, [r4, #4]
1001b216:   60A0                str        r0, [r4, #8]
1001b218:   480C                ldr        r0, [pc, #0x30]
1001b21a:   6806                ldr        r6, [r0]
1001b21c:   4630                mov        r0, r6
1001b21e:   F001F83D            bl         #0x1001c29c
1001b222:   4601                mov        r1, r0
1001b224:   68E8                ldr        r0, [r5, #0xc]
1001b226:   B160                cbz        r0, #0x1001b242
1001b228:   6862                ldr        r2, [r4, #4]
1001b22a:   68A3                ldr        r3, [r4, #8]
          $C$L421:
1001b22c:   6845                ldr        r5, [r0, #4]
1001b22e:   18AA                adds       r2, r5, r2
1001b230:   6062                str        r2, [r4, #4]
1001b232:   6845                ldr        r5, [r0, #4]
1001b234:   429D                cmp        r5, r3
1001b236:   BF84                itt        hi
1001b238:   1C2B                adds       r3, r5, #0
1001b23a:   60A3                str        r3, [r4, #8]
1001b23c:   6800                ldr        r0, [r0]
1001b23e:   2800                cmp        r0, #0
1001b240:   D1F4                bne        $C$L421
          $C$L422:
1001b242:   4630                mov        r0, r6
1001b244:   F001F82C            bl         #0x1001c2a0
1001b248:   BD70                pop        {r4, r5, r6, pc}
1001b24a:   46C0                mov        r8, r8
          $C$CON442:
1001b24c:   04B8                lsls       r0, r7, #0x12
1001b24e:   0000                movs       r0, r0
          ti_sysbios_knl_Mailbox_Module_startup__E():
1001b250:   4810                ldr        r0, [pc, #0x40]
1001b252:   B538                push       {r3, r4, r5, lr}
1001b254:   6804                ldr        r4, [r0]
1001b256:   2C00                cmp        r4, #0
1001b258:   DD19                ble        $C$L367
1001b25a:   2500                movs       r5, #0
          $C$L364:
1001b25c:   2000                movs       r0, #0
1001b25e:   4629                mov        r1, r5
1001b260:   F000FB1C            bl         #0x1001b89c
1001b264:   4602                mov        r2, r0
1001b266:   68D0                ldr        r0, [r2, #0xc]
1001b268:   B948                cbnz       r0, #0x1001b27e
1001b26a:   F001FAF5            bl         #0x1001c858
1001b26e:   6851                ldr        r1, [r2, #4]
1001b270:   1840                adds       r0, r0, r1
1001b272:   1DC1                adds       r1, r0, #7
1001b274:   F001FAF0            bl         #0x1001c858
1001b278:   1E40                subs       r0, r0, #1
1001b27a:   4381                bics       r1, r0
1001b27c:   E001                b          $C$L366
          $C$L365:
1001b27e:   6851                ldr        r1, [r2, #4]
1001b280:   3108                adds       r1, #8
          $C$L366:
1001b282:   4610                mov        r0, r2
1001b284:   F000FB20            bl         #0x1001b8c8
1001b288:   1C6D                adds       r5, r5, #1
1001b28a:   1E64                subs       r4, r4, #1
1001b28c:   D1E6                bne        $C$L364
          $C$L367:
1001b28e:   F04F30FF            mov.w      r0, #-1
1001b292:   BD38                pop        {r3, r4, r5, pc}
          $C$CON355:
1001b294:   04CC                lsls       r4, r1, #0x13
1001b296:   0000                movs       r0, r0
          ti_sysbios_family_arm_m3_Hwi_disableInterrupt__E():
1001b298:   4A0F                ldr        r2, [pc, #0x3c]
1001b29a:   2810                cmp        r0, #0x10
1001b29c:   D20B                bhs        $C$L14
1001b29e:   280F                cmp        r0, #0xf
1001b2a0:   BF18                it         ne
1001b2a2:   2000                movs       r0, #0
1001b2a4:   D115                bne        $C$L15
1001b2a6:   6910                ldr        r0, [r2, #0x10]
1001b2a8:   6911                ldr        r1, [r2, #0x10]
1001b2aa:   F0000002            and        r0, r0, #2
1001b2ae:   F0210102            bic        r1, r1, #2
1001b2b2:   6111                str        r1, [r2, #0x10]
1001b2b4:   E00D                b          $C$L15
          $C$L14:
1001b2b6:   3810                subs       r0, #0x10
1001b2b8:   2101                movs       r1, #1
1001b2ba:   F000031F            and        r3, r0, #0x1f
1001b2be:   08C0                lsrs       r0, r0, #3
1001b2c0:   4099                lsls       r1, r3
1001b2c2:   F0200003            bic        r0, r0, #3
1001b2c6:   1812                adds       r2, r2, r0
1001b2c8:   F8D20100            ldr.w      r0, [r2, #0x100]
1001b2cc:   F8C21180            str.w      r1, [r2, #0x180]
1001b2d0:   4008                ands       r0, r1
          $C$L15:
1001b2d2:   BF00                nop        
1001b2d4:   4770                bx         lr
1001b2d6:   46C0                mov        r8, r8
          $C$CON4:
1001b2d8:   E000                b          ti_sysbios_family_arm_m3_Hwi_enableInterrupt__E
1001b2da:   E000                b          #0x1001b2de
          ti_sysbios_family_arm_m3_Hwi_enableInterrupt__E():
1001b2dc:   4A0F                ldr        r2, [pc, #0x3c]
1001b2de:   2810                cmp        r0, #0x10
1001b2e0:   D20B                bhs        $C$L450
1001b2e2:   280F                cmp        r0, #0xf
1001b2e4:   BF18                it         ne
1001b2e6:   2000                movs       r0, #0
1001b2e8:   D115                bne        $C$L451
1001b2ea:   6910                ldr        r0, [r2, #0x10]
1001b2ec:   6911                ldr        r1, [r2, #0x10]
1001b2ee:   F0000002            and        r0, r0, #2
1001b2f2:   F0410102            orr        r1, r1, #2
1001b2f6:   6111                str        r1, [r2, #0x10]
1001b2f8:   E00D                b          $C$L451
          $C$L450:
1001b2fa:   3810                subs       r0, #0x10
1001b2fc:   2101                movs       r1, #1
1001b2fe:   F000031F            and        r3, r0, #0x1f
1001b302:   08C0                lsrs       r0, r0, #3
1001b304:   4099                lsls       r1, r3
1001b306:   F0200003            bic        r0, r0, #3
1001b30a:   1812                adds       r2, r2, r0
1001b30c:   F8D20100            ldr.w      r0, [r2, #0x100]
1001b310:   F8C21100            str.w      r1, [r2, #0x100]
1001b314:   4008                ands       r0, r1
          $C$L451:
1001b316:   BF00                nop        
1001b318:   4770                bx         lr
1001b31a:   46C0                mov        r8, r8
          $C$CON471:
1001b31c:   E000                b          ti_sysbios_knl_Swi_post__E
1001b31e:   E000                b          #0x1001b322
          ti_sysbios_knl_Swi_post__E():
1001b320:   B538                push       {r3, r4, r5, lr}
1001b322:   4603                mov        r3, r0
1001b324:   F3EF8411           .word       0x8411f3ef
1001b328:   2020                movs       r0, #0x20
1001b32a:   F3808811           .word       0x8811f380
1001b32e:   8B98                ldrh       r0, [r3, #0x1c]
1001b330:   B998                cbnz       r0, #0x1001b35a
1001b332:   2001                movs       r0, #1
1001b334:   8398                strh       r0, [r3, #0x1c]
1001b336:   F000FECD            bl         #0x1001c0d4
1001b33a:   4605                mov        r5, r0
1001b33c:   6A98                ldr        r0, [r3, #0x28]
1001b33e:   4619                mov        r1, r3
1001b340:   F000FF38            bl         #0x1001c1b4
1001b344:   4906                ldr        r1, [pc, #0x18]
1001b346:   6998                ldr        r0, [r3, #0x18]
1001b348:   684A                ldr        r2, [r1, #4]
1001b34a:   4310                orrs       r0, r2
1001b34c:   6048                str        r0, [r1, #4]
1001b34e:   F3848811           .word       0x8811f384
1001b352:   B925                cbnz       r5, #0x1001b35e
1001b354:   F7FFFE6C            bl         #0x1001b030
1001b358:   BD38                pop        {r3, r4, r5, pc}
          $C$L305:
1001b35a:   F3848811           .word       0x8811f384
          $C$L306:
1001b35e:   BD38                pop        {r3, r4, r5, pc}
          $C$CON248:
1001b360:   01C8                lsls       r0, r1, #7
1001b362:   2000                movs       r0, #0
          ti_sysbios_knl_Task_allBlockedFunction__I():
1001b364:   B508                push       {r3, lr}

Have you made any changes to the .cfg which may require the BIOS to be in flash instead of using the pre-configured ROM settings?  Are you able to view your call stack during the debug session to further deduce how your code ended up at its current location?

Regards,
Ryan

I tried remming out the appropriate code section in cc2640.cfg so that I would have BIOS in flash but the code compiled with the exact same FLASH and SRAM usage.  Also, the behavior after wakeup is not changed.

My rem out change:

/* ================ ROM configuration ================ */
/*
 * To use BIOS in flash, comment out the code block below.
if (typeof NO_ROM == 'undefined' || (typeof NO_ROM != 'undefined' && NO_ROM == 0))
{
  var ROM = xdc.useModule('ti.sysbios.rom.ROM');
  if (Program.cpu.deviceName.match(/CC26/)) {
      ROM.romName = ROM.CC2650;
  }
  else if (Program.cpu.deviceName.match(/CC13/)) {
      ROM.romName = ROM.CC1350;
  }
}
 */

Ryan Brown1 said:

Have you made any changes to the .cfg which may require the BIOS to be in flash instead of using the pre-configured ROM settings?

I compared my current cc2640.cfg with one in the rollback directory C:\ti\simplelink\rollbackBackupDirectory4\C\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\config

The only differences are that I have set up an exception handle long ago, I set Program.stack to 512 relatively recently as a result of another forum topic I had and I now have recently in this topic set Task.idleTaskStackSize to 818.

Ryan Brown1 said:

Are you able to view your call stack during the debug session to further deduce how your code ended up at its current location?

If you mean from the Debug tab in CCS here it is (not many levels ;), otherwise how to I view my call stack in more detail?

Thanks for providing the additional information.  Unfortunately I can't determine any more from the call stack if the ROM symbols have already been enabled.

It seems that your code is transitioning from ti_sysbios_knl_Task_schedule__I to ti_sysbios_knl_Task_allBlockedFunction__I.  You can find some details from the ti.sysbios.knl.Task module of the TI-RTOS Kernel Runtime APIs and Configuration (cdoc)

config Task_allBlockedFunc  // module-wide	
index URL
Function to call while all tasks are blocked

C synopsis	target-domain
extern const Task_AllBlockedFuncPtr Task_allBlockedFunc;
 
DETAILS
This function will be called repeatedly while no tasks are ready to run.
Ordinarily (in applications that have tasks ready to run at startup), the function will run in the context of the last task to block.
In an application where there are no tasks ready to run when BIOS_start() is called, the allBlockedFunc function is called within the BIOS_start() thread which runs on the system/ISR stack.
By default, allBlockedFunc is initialized to point to an internal function that simply returns.
By adding the following lines to the config script, the Idle functions will run whenever all tasks are blocked:
  Task.enableIdleTask = false;
  Task.allBlockedFunc = Idle.run;
SEE
enableIdleTask
CONSTRAINTS
The configured allBlockedFunc is designed to be called repeatedly. It must return in order for the task scheduler to check if all tasks are STILL blocked and if not, run the highest priority task currently ready to run.
The configured allBlockedFunc function is called with interrupts disabled. If your function must run with interrupts enabled, surround the body of your code with Hwi_enable()/Hwi_restore() function calls per the following example:
  Void yourFunc() {
      UInt hwiKey;

      hwiKey = Hwi_enable();

      ...         // your code here

      Hwi_restore(hwiKey);
  }
 

This will take further investigation of the task scheduler and determine how/why all tasks remain blocked.

Regards,
Ryan

How about I start a new topic now with title "All tasks remain blocked only AFTER waking up from a sleep/standby state by interrupt and then executing one 'Application main loop' 1ms periodic cycle clock event"?

This title is a little long but what can I leave out?

I recommend stating the root issue (tasks remaining blocked after exiting standby) and providing more details in the body of your post.  Have you considered that 1 millisecond may sometimes be too quick to effectively loop through the application code?  Or this E2E post may be similar in nature: https://e2e.ti.com/f/1/t/1113624 

Regards,
Ryan

OK on the name simplification.

My main loop 1ms periodic clock cycle event has been working very well for a couple years now and for many months since that last big change which added a UART device to talk to, is that sure enough?

EDIT: I have even captured by logic analyzer what seems to be the normal real time per 1ms event at from 0.92 ms to 1.15ms

If possible, it would be interesting to test at 5 to 10 milliseconds.

Regards,
Ryan

Since I posted my edit above, I reviewed all my code change notes over the last couple years and found this interesting edit:

* //p2f14-28 Apr 15 2022 I discovered a RARE condition where the 1ms periodic clock was not running/triggering periodic 1ms events so I added
*                  code in the 2 second periodic clock to try to reset and restart the 1ms clock if a 1mshasticked variable is 0 at every 2 second check  
*                 The main 'for (;;)' loop was still running, UART events and the 2 second periodic clock were still running fine...
*                 I also added a permanently saved system variable as to how many times in the life of the cc2640 that a 1msreset was done
*                and update Nextion to add this number to its debug page and the App to request it in every connect and send it
*                with every diagnostics email and csv file

It has been well over a month now that the cc2640 pcb which is having this 'tasks still blocked after wakeup behavior' and the saved (to external flash) system variable mentioned in my note above still shows a count of zero 1msresets done since new.

I will try 10 ms and report back but it would require a major program re-write if I have to go that long for my fast main loop clock...

Thanks,

Dale

Changing my 1ms periodic cycle clock to 10 ms still presents the same 'tasks still blocked after wakeup' behavior.

I have created a new topic to continue this discussion at:

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1121162/cc2640-all-tasks-get-blocked-shortly-after-wake-up-from-a-sleep-standby-state

Thanks for all the help here Ryan.

Dale

Looks like we are not quite done here...

While my one line solution of adding 'threadSafeStdbyDisRelease(&uartRxPowerConstraint);' as the last line at the end of the UARTCC26XX_close() function in the file UARTCC26XX.c does work to get <10ua, I have discovered that after running UARTCC26XX_close() function, my UARThandle is not returned to NULL or 0 (UARThandle still contains the same value that it had when the UART was used before my <10ua sleep state).

I think this may be problematic because when I try to re-open the UART that still has its UARThandle after waking up from sleep, the UART does not open and the UARThandle is then set to 0.

I even tried putting my 1 line at the beginning of UARTCC26XX_close() but the sleep current goes to many milliamps and the UARThandle is still not set to 0 after a UARTCC26XX_close().

So then I made the assumption that my 1 line at the end of UARTCC26XX_close() is allowing the Power Manager to enter the sleep/standby state and allowing the UART to still be open during this sleep/standby state.  But this assumption is likely not true since after I wakeup and the UART still has its same UARThandle, I try to begin a UART read with a 'UART_read(uartHandle, &uartrxByte, 1); //turn on continuous 1 byte reads' and my HWI error handler gets a call with this error:

This means my solution may not be the full solution for this topic.

Any ideas about why the UARThandle is not cleared after calling UARTCC26XX_close() ?

Thanks,

Dale

EDIT: I now believe that this issue of 'not being able to re-open the UART after waking up from <10ua sleep' is the cause of the hang state in the topic that we branched off to from here. I am not sure how to confirm that until we figure out how to re-open the UART after waking up from <10ua sleep. I did mention that I was still not able to re-open UART after sleep as an edit at the end of this post of this topic https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1109571/cc2640-minimizing-sleep-current-when-using-i2c-and-uart/4150532#4150532 .

I guess I should have gone down this rabbit hole back then....

Thanks for pointing this out so that we can further investigate.  Do you get this same behavior without including 'threadSafeStdbyDisRelease(&uartRxPowerConstraint);' in UARTCC26XX.C?  What is the context from which you call UART_close?  This API calls [Hwi/Swi/Clock]_destruct which should not be used from Hwi/Swi threads themselves, only the Task or Main.  See module ti.sysbios.hal.Hwi (among others) form the TI-RTOS Drivers Configuration APIs (cdoc)

Regards,
Ryan