• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 565 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1310: CC1310 - POR behaviour unexpected

Oliver Lewis
Intellectual 635 points
Part Number: CC1310


Hi,

We are seeing a strange behavior in a few of our devices. We have a simple non-rechargeable battery driven device, with a cc1310, an SPI accelerometer, SPI external flash and a simple inductor coil. The device spends most of its time in standby mode, with just the accelerometer running in the background. Every 4-5s the accelerometer FIFO is cleared and the data written to flash. Two to three times a day, the analysed data is uploaded to a host over radio. So, in principle a very simple design.

I'm currently debugging an issue that we see very infrequently, but nonetheless, often enough for our client to complain about it. After a few weeks running, we see about 1 in ~1000 devices hang. Occasionally, they recover themselves reporting that they reset due to a brown out on VDDS. If they don't recover themselves, we can disconnect and reconnect the battery and the same reset cause is reported. In both cases, the battery still reads ~full (3.6V Li/Io 3500mah).

My first course of investigation is for potential bus contention. E.g. we turn SPI off when the cc1310 enters a low-power mode and just drive all the gpio low. However, given the fault that is reported, I'm a little unsure if this is indeed the case. ...and here's my question...finally...what is the reset behavior on a BOD? Are the GPIO pins all reset on entering brown out reset, or are they reset when the device exit the reset? My confusion comes in, because if there is bus contention, then resetting all the pins to their default state should resolve any contention.

Maybe someone at TI can shed some light on the underlying behavior.

Thanks

- Oliver

  • 0
    TI__Guru**** 317180 points

    All DIOs is set to be high-impedance when getting a reset.

    Not sure if I understand what is going on here considering the message you get on a restart. It sounds like the battery is still full when this happens and hence this is not caused by the battery dropping below 1.8 V over time due to the battery is close to empty. 

    Then it could be two other events:

    - The battery looses contact momentarily with the contact meaning that you for a short while does not have a supply voltage on the device. How this will look like will depend on the state the chip is in when this occur. The decoupling caps on VDDS will retain some voltage and if you are in standby the voltage will slowly go under 1.78 V and then getting a BOD. 

    - You get a large current draw for some reason that will cause a IR drop and VDDS going under 1.78 V.  

    How is the device used, how likely is a momentarily loss of battery? 

    How is the code written, do you check for the cause of a restart when booting up? 

  • 0 in reply to TER
    Intellectual 635 points

    Hi TER,

    Thanks for your response.

    "All DIOs is set to be high-impedance when getting a reset."

    Any idea if that happens, when the device is released from brown out and resets, or when it enters brown-out? 

    As for the other two events you describe. The batteries are soldered onto the PCB, so this one is unlikely to be a momentary power loss. Though not unthinkable, it could be a dry solder joint or something like that. It is more likely to be a high current draw. Though I am seriously struggling to recreate that, even forcing bus contention e.g. on SPI lines doesn't seem to kill the device. 

    There is a regulator that takes the battery from ~3.6V to 3V which is rated up to 150mA. I guess, that will be the current draw limit. Worst case, I don't really ever see the device go above about 50mA (with everything turned on and the cc1310 transmitting on full power). BOD is set to the higher level in the config (2V, not 1.8V as we use 14dBm output power).

    The code is written to report any reset cause (for interrupt catchable ones, we even mark the program counter where the exception occurrred). 

    Is there a way to disable BOD and handle it in e.g. an IRQ? That way I might be able to find the cause of the issue.

    NB: The devices in the field are potted and even hard resetting them requires a milling machine, so I can't even probe lines to look for contention or feel for hot components. I have a couple of open PCBs that I'm using to try to recreate the problem.

    Any other thoughts on how I might debug this?

    Thanks

    - Oliver

  • 0 in reply to Oliver Lewis
    TI__Guru**** 317180 points

    "All DIOs is set to be high-impedance when getting a reset.": As I understand it this will happen when it enters the brown-out since a BOD generates a reset which resets the flip-flops controlling the DIOs.

    I agree that the two events I thought about doesn't seem to be too likely.

    It's not possible to disable the BOD since the states internally is not fully defined below 1.78 V. 

    What sort of environment is this in or to put it a different way, could an external event occur (and then later we have to figure out why an event could cause this)

  • 0 in reply to TER
    Intellectual 635 points

    Not during testing, there are simply boxes upon boxes of these devices sitting in a lab, activated but physically idle. In practice they will go into quite a destructive environment, but we're not quite at that point in testing yet.

    There is an induction coil that runs into a rectifying diode and into a low-power 200x op-amp, then to a GPIO; this acts like a kind of an external trigger to force comms - rather than wait for scheduled events. A tuned loop (or even some RFID readers) can trigger this. This circuit is passive apart from the op-amp which uses uA's. That is the only "external" event that the device is configured to handle. However, we have seen devices enter this brown-out state without the external trigger being used. 

    There is also some circuitry to do a battery level check. This consists of a mosfet to switch in/out the battery checking circuit - it uses some current, so when not in use, it's disabled - and a resistor-pair voltage divider which is fed into an analog input. This should read 0.5x the actual battery voltage at the anaolg pin (against a fixed reference). Again, unlikely as a source of a short.

    There is a debug uart, which is not used once deployed (though the code to manage it is still there). This is disabled and turned to GPIO with an internal pull-down on the RX line - when connected this springs to life and configures the pins as a UART. This isn't even accessible when the devices are potted.

    That's pretty much the complete design. The rest is all 868/915 radio related (PCB antenna and supporting circuitry) all taken from the reference designs.

    I think my next port of call is to ask the client to X-Ray the devices to see if there are any possible solder problems that could cause intermittent issues. 

    If you have any further thoughts on how I might be able to debug this, then please keep them coming.

    Thank you again

    - Oliver

  • 0 in reply to Oliver Lewis
    TI__Guru**** 317180 points

    From your descriptions I can't see any obvious reason for the behavior you are seeing. 

    x-ray sounds like a good start to get some insight in how the module "looks like". It could be useful to compare a "good" module with a module where your customer has seen issues. 

    In addition the following errata note should be noted: