Can I write EV[n].CTL when counter is running?

[alexeyborisenko]

I wish to capture start-bits of UART transfers while counter continously running in modulo2^16 mode. Is It possible with SCT? How can i signal to SCT that I am read previously captured value and need to capture start-bit of next transfer?

In UM10601, it is stated clearly that STATE and OUTPUT can be written ony when counter halted. But what about EV[n].CTL and EV[n].STATE? I need to keep timer permanently running without any stops and halts to allow precise measurements of time between any pair of captured events.

As I understand, with SCT, I will change state on capture event to prevent overwriting captured value by following transitions until end of transfer, and then i need some means to return to original state to allow capture of  next transfer.

I working with LPC812.                 

[jeremyzhou]

Hi Alexey Borisenko,

Thank you for your interest in NXP Semiconductor products and 

the opportunity to serve you.

To be honest, I'm not very clear with your question, so I'd highly recommend you to illustrate the application flow of SCTimer in details, then I can verify whether this application is feasible or not.

I'm looking forward to your reply.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[alexeyborisenko]

For clarity, I summarise my original questions in more clear form:

Q1: Is it safe to write EV[n].CTL when associated counter is running?

Q2: Is it safe to write EV[n].STATE when associated counter is running?

And, if answer is "not in general" , I have other set of more restricted questions:

Q3: Is it safe to write EV[n].CTL when associated counter is running but it is known that EV[n] can't be triggered during

write operation assuming either previous or written value of EV[n].CTL value.

Q4: Is it safe to write EV[n].STATE when associated counter is running but it is known that EV[n] can't be triggered during

write operation assuming either previous or written value of EV[n].STATE mask.

Q5: Is it safe to write EV[n].CTL when associated counter is running but EV[n] is disabled in current state by EV[n].STATE

and it is known that state can't change during write operation.

Intuitively, answers to Q3-Q5 most probably to be "yes", but I'm not sure, because I heard about situations in which SCT behave counter-intuitively, and I not yet seen any examples using write to Ev[n].CTL or EV[n].STATE while counter is running.

If answer of any quection above is "yes", I think it is worth to place it in documentation explicitly as usable feature of SCT, because they are enabling features for many applications.

[jeremyzhou]

Hi Alexey Borisenko,

Thanks for your reply.

It's not safe to write these register when the counter is running, we'd highly recommend the customers to avoid these operations.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[alexeyborisenko]

And yet one option I found just now:

Option 3:

Make both Ev[0] and Ev[1] triggering capure of same capure register and toggle state, but using different sct inputs, one of them connected by switch matrix to RxD and another to always-high input. Then software will toggle connection of RxD/always-high signals to sct inputs using switch matrix each time to allow new capture event.

But this option still slihgtly ugly: it seems to be less efficient in coding than options 1 or 2 and needs some pin to be useful as source of always-high signal, so original question remains actual.

If options 1 or 2 is ok, I prefer to use one of them.

And if anyone have other options, I will be glad to hear about them.   

[alexeyborisenko]

Caprure event (ev[0]) will be enabled in state 0 only, and it always andvances to state 1, to disabling itself and avoid owerwriting of capture register until software responses to this event.

No events enabled after that in state 1, only software will decide when to return to state 0 to allow next capture.       

Strightwordward way of returning to state0 from software is writing 0 to SCT.STATE register, but it is not allowed  when counter is running. I'm trying to found best way to work-around this.

Let suppose using another event (EV[1]) to return from state1 to state0. How it may be triggered by software?

Option 1:

Make EV[1].CTRL condition always true but initially disabled by EV[1].STATE mask, and software can trigger it by writing enabling value to EV[1].STATE

Option 2:

Make EV[1].CTRL condition initially always false, but changing it to true by writing EV[1].CTRL when software wish to trigger it.

Other options:

I know about options to feed triggering input to sct (to EV[1] in our case) through board-connected pair of external pins or by single pin using pullups, but those options are so ugly so I trying not thinking about them yet.

I hope I'm described my questions clearly enough now.

Thanks for response.