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.

CC1110 PM2 sleep stall issue

I have designed a system which has 1 receiver & up to 4 transmitters. using the sleep timer & PM2 to sleep for 200mS & wake to check for transmissions. If a packet is detected, then the receiver remains awake to process the data, then sleeps again & the cycle is repeated. This works well with good battery life & good range. This is now in mass production with ~6000 units in operation.

I've since designed an enhanced system based on the original design & firmware with some extra feature for a 2nd product. Again similar battery life & range. This has just had the 1st production run of 1000 receivers & 4000 transmitters of which is sold out. Recently I've received 3 receivers back with the same symptoms. They appear to the locking up. I have a unit here which works fine.

On close investigation the are not waking from sleep reliably. When I look at the external oscillator on the good unit I can see the clock start, stay awake ~12mS, then good to sleep again for about 190mS. In the faulty units I we this, but I sometimes see the clock stay active much longer & occasionally it's continuous & occasionally the nothing. This becomes unresponsive & sometimes & have to reinstall the battery to get is working again

I have followed Design Note DN106 (SWRA162B) & I believe I've implemented it correctly. I also did not see this occur on the 1st product, or the pre-production units of the 2nd product. I can only think there are a race condition which I'm missing that only creates a problem on a handful on devices.

Please can I send you my code to check & possibly one of the faulty units to ensure they are not faulty.

This is quite urgent so your prompt response would be greatly appreciated.

 

John Galvin

  • Hi John
    It is hard to say what is going on when I do not know your code, but have you made sure that you follow the errata note on how to enter and exit PM2?
    There are issues related to doing specific operation if they are done on a 32 kHz edge, so for example updating EVENT0 and entering PM2 must be align to a 32 kHz edge. One of the things that could happen if you for example enter PM2 on an edge is that the sleep interval, tEvent0, will be 128 times longer than programmed.
    It is also very important that you remember to clear the MODE bits in all ISR for interrupts used to wake the chip from PM2/PM3 (SLEEP timer ISR, Port ISR etc.). This is stated in the data sheet.
    BRSiri
  • Siri,

    Many thanks for getting back to me so promptly. I'm happy to send you my code, but I don't want to post it here. Please can you send me a private link to do so.

    I have made every effort to follow the errata but I guess I may have missed or miss-interoperated something. It's strange that it works one the vast majority of units. Is this a likely symptom of not getting this right?
  • Send the code to me in a message and I'm going to pass it to Siri.
  • Sorry. I can't work out how to do that. I can start a private message but I can't see how to attach files to it.
  • In the new E2E "look" it should be as easy as "drag and drop" the file into the post as long as you use rich text formatting.
  • Hi John
    I have received the code from Torstein and will take a look at it over the weekend.
    BRSiri
  • Hi

    I have looked at your code (the parts involving entering PM2) and most of it look s OK, but you need to follow the work-around in the errata note with respect to turning on the HS XOSC.

    BR

    Siri

  • thanks. What bit did I get wrong?

  • Hi

    You cannot poll the XOSC_STB stable bit like you do in the following code as this bit cannot be trusted. Please see issue 3 in the errata note (Premature XOSC_STB Assertion)

    //////////////////////////////////////////////////////////////////////

    ///////////// Code section #2 begin: Switch to [HS XOSC] /////////////

    // Power up [HS XOSC] (SLEEP.OSC_PD = 0)

    SLEEP &= ~0x04;

    // Wait until [HS XOSC] is stable (SLEEP.XOSC_STB = 1)

    while ( ! (SLEEP & 0x40) );

    BR

    Siri

  • Sorry but can you please clarify.

    I assume you are referring to Design Note DN106 (swra162b) but I can't find any mention on premature XOSC_STB assertion.

    Are you saying do NOT use the code shown in your message. If so what should be done?

    There is a delay mentioned between monitoring SLEEP.XOSC_STB and clearing the CLKCON.OSC but this only applies to the CC243x

  • I am referring to the CC1110 Errata note (http://www.ti.com/lit/swrz022).

    BR

    Siri

  • Siri,

    Ok. There is my problem. I was working this the wrong document which didn't detail the SLEEP.XOSC_STB bug. Unfortunately this as impacted my battery life calculations as the unit needs to stay awake a further 1mS in every 200mS but I guess we will just have to live with it.

    Many thanks for taking the time to assist me.

    Have a great Christmas.

    Regards

    John