• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 1202 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.

CC2541 BLE interruption processing

Evgeny Lunev
Intellectual 475 points

Other Parts Discussed in Thread: CC2541

Hi,

We have a device based on CC2541 chip and use firmware based on BLE stack.

We have a button (reed switch) connected to port P0 and configured such that our application

receives key event every time reed switch is closed.

Problem is:

if our device doesn't transmit notification messages (which is part of normal operation - device sens some information

to the host) almost every interrupt is catched and handled

but if notification messages are transmitted (with fairly high frequency - up to onve in 150 msec) some interruptions

are missed - i.e. reed switch is closed but key event not fired - and interruption seems to be lost at all,

it happens say once in 100 reed switch clicks.

Reed switch clicks with intervals at around 1 in 500..600 msec.

So it seems as if OSAL being kept busy by transmission routines doesn't have time to handle interrupt properly.

Could you propose some solution or workaround to it?

BR,

Evgeny

  • 0
    Expert 1740 points

     Hi, Evgeny 

     

    Check out this thread: 

    http://e2e.ti.com/support/low_power_rf/f/538/p/227515/803665.aspx

    Several people stumbled upon USART missing some interrupts when RF module is actively broadcasting (e.g. peripheral-role device sending out advertising packets).

    Turns out that when RF event happens, it stops CC25xx for some time, so if interrupt happens during this period, it could be missed by hardware. I believe same may apply to GPIO interrupts, too. There is link-layer solution proposed, you may find it useful.

    Oleg. 

  • 0 in reply to Oleg Komlev
    Intellectual 475 points

    Hi Oleg,

    Thank you for quick reply - i see it's well-known issue...

    What do you mean by link-layer solution? - the only I have seen in above mentioned thread

    to check if there is enough time before next transmission and notify interrupt source accordingly

    which is obviously not an option in our case)

    'cause whole idea of this periphery (reed switch) is to register some unforeseen events...

    Could you also tell expected time of release 1.3?

    BR,

    Evgeny.

  • 0 in reply to Evgeny Lunev
    Expert 1740 points

    Well, that's exactly it - I actually misnamed it. 

     

     >>Could you also tell expected time of release 1.3?

    Сan't (not a TI employee) - I really wish I could :)

    The only idea I could propose is to use software edge detector (put it into task that is just after HCI by priority). And put something that makes reed switch pulse (I assume that it clicks out very quickly, so you can't just read it - if the logic high from switch that comes to GPIO is long by design, you're ok) longer. Probably some old-fashioned like RLC + Shmidt trigger. Really crummy workaround, but looks like using straight interrupt is not an option for you.

    BR,

    Oleg

  • 0 in reply to Oleg Komlev
    TI__Mastermind 23440 points

    Hi,

    Could you check whether the IRQ flag relevant for reed is set, perhaps? This should be cleared by the ISR, so if you periodically output this to a LED you can see whether it has been set but not processed if the LED keeps glowing. Look at chapter 2.5 of the chip user guide.

    The reed switch int should just lie there pending completion of other interrupts, so I don't know what is happening exactly.

    Best regards,
    Aslak 

  • 0 in reply to Oleg Komlev
    Intellectual 475 points

    Hi Oleg,

    Thank you for suggestion - ubfortunately we cann't change hardware at the stage we are now,

    you are right reed sw. clicks rather quickly so it may not be high while the task tries to read it.

    Actually i thought about it and tried to read in a task but with bad reasult...

    BR,

    Evgeny

  • 0 in reply to Aslak N.
    Intellectual 475 points

    Hi Aslak,

    >Could you check whether the IRQ flag relevant for reed is set, perhaps?

    the reed switch would not work in 99 cases out of 100 i guess)

    just then it coincides with transmission as the post above describes it..

    Thaank you.

    BR,

    Evgeny