• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 566 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DDI16BitfieldRead Failing

Trey German8
Expert 1930 points
Other Parts Discussed in Thread: BLE-STACK

I'm working on a new piece of hardware and I'm seeing some strange behavior.  Details are as follows:

Board is custom, but based off the SensorTagv2.  I've swapped some of the sensors and I'm using a pre-certified LSR module.  Design uses a CR2032 and I've ensured I have a fresh one installed.

Firmware is based on the SensorTag project, but has been modified to work with the new sensors.  Changes have been made to profiles and the application layer, but no changes have been made to clocking or power or anything of that sort.  I'm just trying to get the data out similar to how the sensortag does it.

The firmware does work and I'm able to read and write characteristic values, but occasionally the device will bus fault after debugger resets. See below:

As you can see the issue appears to be a DDI read failing, due to what I assume is the AUX_PD not being powered up.  Would you agree?

Given that I haven't touched any of the underlying code that controls this stuff, I'm curious if there may be a bug somewhere in CC26xxWare?  I'm using BLE-STACK 2.2 and TI-RTOS 2.18.0.03.

I'd appreciate any pointers y'all can give me to help track down the issue.

Best,

Trey

  • 0
    Expert 1930 points

    I've got some additional information.  After it hangs in the handler function (due to the bus fault), if I reset using the debugger and then run, the application hangs at 0x10000486 which looks like a WFI instruction.  

    I've experimented with it a bit and the behavior seems random.  33% chance of application boot, 33% chance of ending up in the handler, and 33% chance of ending up at 0x10000486.

    Any ideas?

    Thanks,

    Trey

  • 0 in reply to Trey German8
    Expert 1930 points
    Hey Simplelinkers,
    I'm guessing someone is already looking into this and you're swamped with about a billion other things going on at TI, but could I at least get a response? Just trying to look out for your forum metrics :-P haha

    Best,
    Trey
  • 0
    TI__Mastermind 20480 points

    Trey,

    so, looking at your exception callstack the AUX_SMPH_BASE is probably not powered up as you already guessed.

    It's a hardware semaphore used by the RF driver (probably other drivers as well). I suppose you don't see this exception the 1st time around as you're able to run the BLE stack for a while..right?

    Is this reproducible with the stock sensortag example in the SDK?

    Here are a few things I'd try:

    1. Disable the power savings in your project (-DPOWER_SAVINGS) and see if you get into this issue.

    2. If that didn't help, I'd also disable the power driver in the board file:

    /*
 *  ============================= Power begin ==================================
 */
const PowerCC26XX_Config PowerCC26XX_config = {
    .policyInitFxn      = NULL,
    .policyFxn          = &PowerCC26XX_standbyPolicy,
    .calibrateFxn       = &PowerCC26XX_calibrate,
    .enablePolicy       = FALSE, //<------ This guy here
    .calibrateRCOSC_LF  = TRUE,
    .calibrateRCOSC_HF  = TRUE,
};

  • 0 in reply to Tom Kopriva
    Expert 1930 points
    Hey Tom!

    First off, I don't think the 0x10000486 thing is the application hanging. Its really hard for me to see the advertisement light because of the way the debugger plugs into my board. I think I was just missing that.

    Second, the exception seems to be happening every other time a program runs on the device. After flash programming, when I run the application it faults. After a reset, it runs. After a pause/reset/run, it will again fault and so on. My guess is that a driver somewhere is assuming some type of initial register value that it shouldn't be. I certainly made this mistake when I was writing drivers for C2k clocking and power.

    I've got a sensortag here I'll try to do some testing with and report back. I will try your other suggestions as well.

    Thanks so much Tom!
  • 0 in reply to Trey German8
    TI__Mastermind 20480 points

    Also,

    I noticed this thing is dying in a Swi. Looking at the other board files, I noticed that the sensortag defined the RF driver's swi priority as 0. Can you update this to 5?

    /* RF hwi and swi priority */
const RFCC26XX_HWAttrs RFCC26XX_hwAttrs = {
    .hwiCpe0Priority = ~0,
    .hwiHwPriority = ~0,
    .swiCpe0Priority = 0,
    .swiHwPriority = 5, //<------- here
};

    I'd do this before disabling the power stuff.

    Tom

  • 0 in reply to Tom Kopriva
    Expert 1930 points
    Turning off the POWER_SAVING define did cause the faults to stop occurring. I will try re-enabling them and changing the RF SWI priority next.
  • 0 in reply to Trey German8
    Intellectual 470 points

    Hi Trey,

    Did you make any further progress investigating this? Did you find a better workaround/fix?  I have had a similar issue, described here, which makes me suspect it's something incorrect in the example code.  I am hoping TI will help to resolve.  The solution of simply removing the POWER_SAVING isn't really an acceptable solution in the long term.  

    Thanks,

    Ross

  • 0 in reply to Ross Arnott
    Expert 1930 points

    Ross,

    No I have not.  I'm seeing the exact same thing as you.  Every other debug reset I this happens, but it doesn't happen when I'm not debugging and running off battery power.  I agree with you that there is likely a bug in the TI code somewhere.