Can't connect debugger to a non functioning tag

Seems like your device is stuck in one of the "exception" interrupt ISR's, though I ma be wrong here

(refer to section 4.1 in cc26xx reference manual) .

Yes, this sounds plausible.
Do I have any chance to find out the reason of the exception? In the running firmware I did not touch exception handling, so in appBLE.cfg I have:
M3Hwi.excHandlerFunc = null;

In the next release, I will change that to
M3Hwi.excHandlerFunc = "&myExceptionHandler"; /* null = default while loop function. Use e.g. "&myFxn" to use your own function. */
and create a function like:void myExceptionHandler(exceptionFrame *e, unsigned int execLr)
{
uint16_t exceptioncounter;
readEEPROM(0, sizeof(uint16_t), &exceptioncounter);
exceptioncounter++;
writeEEPROM(0, sizeof(uint16_t), &exceptioncounter);
writeEEPROM(sizeof(uint16_t), sizeof(exceptionFrame), e);
writeEEPROM(sizeof(uint16_t) + sizeof(exceptionFrame), sizeof(int), &execLr);

HCI_EXT_ResetSystemCmd(HCI_EXT_RESET_SYSTEM_HARD);
}

Will that help? I kind of doubt, that my EEPROM calls will work properly, because they rely on RTOS and I2C driver.
Is that the appropriate way of performing a reset?
Regards
Harald

Hi,

Well, I'm not familiar with TI-RTOS, nor I have an installation of one to experiment and test with.
I like the way you thinking, means you have to add some functionality into exception handling
in order to be able to inspect where and why it hangs.
Not sure that dumping info to ROM will help, think of a convenient way to retrieve the info once the CPU
hangs in an exception IRQ.
I was thinking about toggling LEDs in a known pattern, or something like that.
If you have a deterministic way to inspect where the CPU hangs, I would suggest not to reset the SoC
rather try to understand the root cause from the information visible/known to you so far (LEDs state,
etc.)

Hy,

>I was thinking about toggling LEDs in a known pattern

good idea during development. But we are planning to start field test next week, so I need a "self-recovering" version soon.

Do you have any ideas on how to test the exception handling? How could I generate the different exceptions?

Of course, I could only call my exception handling synchronously, but I guess, It behaves differently when called from a real exception. For example, I don't expect the RTOS to be still running, so calls to any RTOS function will probably fail. Unfortunately, my EEPROM functions rely on the I2C functions provided by RTOS (i.e. Semaphore_pend in bsp_i2c.c), so I guess, they won't work either.

Regards

Harald

What about analyzing different sources of reset when the system is booting (refer to section 6.1.6.1).

In exception handlers issue a "warm" reset (something like that), in main insert some case for different

sources of reset and handle it differently.

Another thing, although your EEPROM is external to cc26xx device, you still have the internal flash,

which can be accessed without the RTOS api, direct addressing, as long as there is an area in FLASH

where you are permitted to write your own data, you can dump some info by a simple write. This data

will be read after reset.