CCS/CC2640R2F: HWI thrown in hal_flash_read.c while starting

Hi David,

If you are using GAPBondManager, it may make sense that it's trying to read bonding information when the device is powered up.

Can you use ROV to try to debug the hardware exception?

You mention low battery condition - you are aware that the device should be operated at 1.7 V at the lowest? Operating the device at a lower current can lead to a bricket device, but you wouldn't be able to see it go into ICall_init().

Hi Marie,
Generally what happens is the device is discovered non-responsive. We replace the battery and it still doesn't respond. This doesn't happen consistantly (i.e. we have thousands of these things that run down the battery and still boot straight up when the battery is replaced). However, once they do get bricked, they stay that way until the firmware is reflashed. I have tried a few things (i.e. just flash the program and ignore the user SNV area for example) but only an entire re-flash will bring them back up.

I don't have any protection for a voltage check around the code where we are using the user areas of SNV (I thought it might be corrupted and stopping my own code from proceeding) but it doesn't seem like that is the case.

Despite investigating for quite some time now, we are still no closer to really understanding what is happening, so we're trying to limit reproducing the problem to things that are plausible / possible. When using Uniflash to check whether the firmware is OK, it seems fine (right up to where you expect it to differ i.e. the user snv areas at 0x1e000 and upwards).

Another related question. In the file nvocop.c is the following code fragment:

// Checks whether CC26xx voltage high enough to erase/write NV
#ifdef NV_VOLTAGE_CHECK
#define NV_CHECK_VOLTAGE() (PWRMON_check(MIN_VDD_FLASH))
#else
#define NV_CHECK_VOLTAGE() (TRUE)
#endif //NV_VOLTAGE_CHECK

So it would seem that, by default, there is no voltage protection check on the flash read / write routines in the BLE stack. This is not the impression that the documentation around osal_snv_write() suggests.

defining NV_VOLTAGE_CHECK doesn't work very well (the default project settings don't include pwrmon.c which has the PWRMON_check function in it. I can fix that, but I am curious as to why it is half implemented like that. Is it not meant to be used?

Hi David,

Sorry you ran into that stale code. I will file a ticket to update nvocop.c to actually do a voltage check.

The PWRMON_check API does not exist any more. You can use AONBatMonBatteryVoltageGet() and compare the value to MIN_VDD_FLASH. You need to call AONBatMonEnable() before using this API.

Documentation about AONBatMon is found in the driverlib API documentation (e.g. file:///C:/ti/simplelink_cc2640r2_sdk_2_30_00_28/docs/driverlib_cc13xx_cc26xx/cc26x0r2/driverlib/group__aonbatmon__api.html#ga9fa932b57660b7ff1062ca41ff31226a )