[SCT] it is very difficult to function SCT as what I want

[lpcware]

Content originally posted in LPCWare by uratan on Wed Dec 10 04:50:16 MST 2014
Hi all.

SCT is very interesting peripheral but I can not make it work as what I want yet.
(I have similar problem as: http://www.lpcware.com/content/forum/sct-halt-problem-split-mode-different-prescalers)
I'm fighting to grasp SCT, but it is far from easy...
so....

Q1

Is there some more detailed documents about SCT other than UM10601 ?
(for example, how does it act when STOP condition and START condition is conflicted)
(or why the counter never be HALTed when it is already STOPped)
(or why I can not get static comparison result with MATCHMEM attribute when starting the SCT with initial counter value)

Q2

I'm referencing "lpc_chip_8xx_lib/inc/sct_8xx.h" (from lpcopen_2_01_lpcxpresso_nxp_lpcxpresso_812.zip), and it
has these register difinitions which are not described in UM10601:

 MATCH_L[n]    / CAP_L[n]     @ 0x5000_4180--
 MATCH_H[n]    / CAP_H[n]     @ 0x5000_41c0--
 MATCHREL_L[n] / CAPCTRL_L[n] @ 0x5000_4280--
 MATCHREL_H[n] / CAPCTRL_H[n] @ 0x5000_42c0--

It seems that these are some alias for 16bit-mode access, and can work legally.
Is there any problem about using these registers ?

---

p.s.

The UM10601 says that "The prescaler is cleared" when "Software writing to the counter register" (page 156 of 370, Rev.1.6),
but I can not get this action...

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Tue Dec 23 07:08:09 MST 2014
Have you tried using the Red State function in LPCXpresso? It is described in chapter 17 of the User Guide and supports the SCTimer.

[lpcware]

Content originally posted in LPCWare by uratan on Tue Dec 23 06:54:25 MST 2014
[u]To: sandy_493[/u]

Thank you for your guide.

I had taken a glance at some of the samples, and found these:

(1) samples under "code examples/LPC81x/LPCOpen/applications/lpc81x/examples/SCTimer_PWM/" are not so reliable because I have found these defects.
[list=d]
[*] periph_SCT_deadtime/main.c:
    [list]
     [*] setting for AUTOLIMIT_L of CONFIG register is missing.
     [*] setting for STOP_L register is missing.
     [*] clearing interrupt flag may be missing in SCT_IRQHandler().
    [/list]
[*] periph_SCT_reload/main.c:
    [list]
     [*] conflict setting about CTOUT_1 is lacked.
    [/list]
[/list]
  These samples may be simply converted from Keil version, I think.
  I recommend followers to see samples under "code examples/LPC81x/Keil"...

(2) register assignments:
    MATCH_L[n] / MATCH_H[n] / MATCHREL_L[n] / MATCHREL_H[n]
  are used in "code examples/LPC81x/Keil/SCT_start_stop/"

(3) "code examples/LPC15xx/Keil/SCT1_ws2811/" is very exciting and useful,
  I can grasp something to use state-value of the SCT.
    (But another question is made that,
      whether does STATEMASK0 hit or not if STATE number is 2 ?
        (upper bit of STATE register is ignored or not ?), at LPC810)

 

Thanks a lot, but not enough...

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Dec 22 18:19:38 MST 2014
Thank you for sharing this information - it will be helpful for me, too!

Initially I thought of a n-pulse generator, too. But in the end I decided to allow burst length to be specified independly from the pulse width. The rounding up (the time) of burst length is done by the SCT as a side effect  :)
I enjoy that SCT beep generator very much, because I can use it as a re-usable module in different applications.

I haven't looked at your results in detail, but I seems you get unexpected results even you're not using different prescalers....!
Not very funny.

Marc

[lpcware]

Content originally posted in LPCWare by uratan on Fri Dec 19 02:25:52 MST 2014
> [SCT] it is very difficult to function SCT as what I want

I had wanted to implement "n-pulse generator" which generates
simple pulses and stops after specified number of pulses.

I had designed it like this.

  <<< L-counter - generates plain pulses         >>>
  <<< H-counter - counts number of pulses        >>>
  <<<                                            >>>
  <<< to count number of pulses, H-counter is:   >>>
  <<<   started at L-counter== m                 >>>
  <<<   stopped at L-counter==(m+1)              >>>
  <<<                                            >>>
  <<< Halt both H- and L-counter when H-counter  >>>
  <<< reaches required count: n                  >>>

But it act as out of my thought, and more, ended with unbelievable status:
"L-counter is halted but H-counter is run" when n is even number.
      (I had thought that HALT must have highest priority)

See the sample of log.

   CTRL_U:00020000   COUNT_U:00020005   OUTPUT:00  <<< L==5 -> ev0 (limit-L)
 ^^^ CLK ^^^
   CTRL_U:00020000   COUNT_U:00020000   OUTPUT:01  <<< L cleared
 ^^^ CLK ^^^
   CTRL_U:00020000   COUNT_U:00020001   OUTPUT:01
 ^^^ CLK ^^^
   CTRL_U:00020000   COUNT_U:00020002   OUTPUT:01  <<< L==2 -> ev1 (run-H)
                                                   <<< (*1)
 ^^^ CLK ^^^
   CTRL_U:00000004   COUNT_U:00030003   OUTPUT:00  <<< L halted but H is run (*2)
                                                   <<< L==3 but halted, no event will occur
 ^^^ CLK ^^^
   CTRL_U:00000004   COUNT_U:00040003   OUTPUT:00
 ^^^ CLK ^^^
   CTRL_U:00000004   COUNT_U:00050003   OUTPUT:00

(*1) H==2 but H is stopped at here, so event cannot be generated, I think.
     But after next clock, L is halted. so ev5 (H==2) must be generated
     by some "look-ahead-run-status" (next_state_is_run).
(*2) From the priority of conflict actions by my examination,
     it is natural that HALT is ignored for H counter if it is stopped.

I was very confused, was at my wit's end, spent days drunk.
But one day, I had changed my mind, decided to
confirm basic behavior of SCT, and they are reported here.

- * - * -

Now I can figure out why SCT act so (a little), and now
I think my design will work correctly if I give cooked number like:
    expect 1 pulse  <-- give n=1
    expect 2 pulses <-- give n=3
    expect 3 pulses <-- give n=5
  ...

The SCT is very interesting and flexible, I am deeply excited
when reading a sample code of WS2811 LED driver.
But It is too flexible so there may be another difficulties
of readability or commonality or verification...
  (I wanted to discuss about this here at first, but it was very hard how to report...)

 
[hr]
 

See attached ZIP file "sct-test-013.zip" about the detail of SCT's curious action.
  (omitted below, see my previous post)

 
 
 

(to be continued..., next final)

[lpcware]

Content originally posted in LPCWare by uratan on Thu Dec 18 03:10:59 MST 2014
> The UM10601 says that "The prescaler is cleared"
> when "Software writing to the counter register" (page 156 of 370, Rev.1.6),
> but I can not get this action...

I have made a program to confirm this.

It seems that:
  The prescaler is cleared by CTRCLR bit in CTRL register,
  but is NOT cleared by writing to the counter register.

See the sample of result log.

 sct_reset_peri()
 sctimer_init()                                    <<<< with CTRCLR >>>>
 ---------- go(2)                                  <<<< without CTRCLR >>>>
 n = 2
CLKs: 12MHz/12MHz
LPC_SCT
 00000184 =CONFIG
 00C00080 =CTRL_U             <<<< prescale: H=1/7, L=1/5, both run

 <<<<< snipped >>>>>

   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:1/7,   L:1/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:2/7,   L:2/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:3/7,   L:3/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:4/7,   L:4/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:5/7,   L:5/5++
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:6/7,   L:1/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:7/7++, L:2/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04570124
 ^^^ CLK ^^^                                      <<< H:1/7,   L:3/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04570124
 sct_stop()                                  <<<< once stop >>>>
 ---------- go(2)                            <<<< run again without CTRCLR >>>>

 <<<<< snipped >>>>>

   IN0:00   CTRL_U:00C00080   COUNT_U:04560123    <<< counter is re-writed
 ^^^ CLK ^^^                                      <<< H:2/7,   L:4/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560123
 ^^^ CLK ^^^                                      <<< H:3/7,   L:5/5++
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:4/7,   L:1/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:5/7,   L:2/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:6/7,   L:3/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04560124
 ^^^ CLK ^^^                                      <<< H:7/7++, L:4/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04570124
 ^^^ CLK ^^^                                      <<< H:1/7,   L:5/5++
   IN0:00   CTRL_U:00C00080   COUNT_U:04570125
 ^^^ CLK ^^^                                      <<< H:2/7,   L:1/5
   IN0:00   CTRL_U:00C00080   COUNT_U:04570125

See attached ZIP file "sct-test-012.zip" about the detail of this examination.
  (omitted below, see my previous post)

 
 
 

(to be continued...)

[lpcware]

Content originally posted in LPCWare by sandy_493 on Wed Dec 17 07:47:18 MST 2014
The SCTimer/PWM Cookbook and Tutorial example in depth learning of SCT with examples

http://www.lpcware.com/content/project/SCTimer-PWM

[lpcware]

Content originally posted in LPCWare by uratan on Tue Dec 16 21:07:26 MST 2014
> how does it act when STOP condition and START condition is conflicted
> why the counter never be HALTed when it is already STOPped

I have examined about this by myself.

Here is a sample of result, when all /* HALT + STOP + START */ is conflicted.
(event occurred when L==2, while high-side is stopped and low-side is running)

                                                <<<< HALT + STOP + START >>>>
   IN0:00   CTRL_U:00020000   COUNT_U:00000000
 ^^^ CLK ^^^
   IN0:00   CTRL_U:00020000   COUNT_U:00000001
 ^^^ CLK ^^^
   IN0:00   CTRL_U:00020000   COUNT_U:00000002    <<< match!
 ^^^ CLK ^^^
   IN0:00   CTRL_U:00000004   COUNT_U:00010003    <<< H started, L halted
 ^^^ CLK ^^^
   IN0:00   CTRL_U:00000004   COUNT_U:00020003

result:       (...really ?)

                             (High side)          (Low side)
---+---------------------+--------------------+---------------------
 n | EVENTs (CONFLICT)   |  while "stop"ped   |  while "run"ning
---+---------------------+--------------------+---------------------
 1 |               START | "run" with count   |  keep "run"
 2 |        STOP         |  keep "stop"       | "stop" after count
 3 |        STOP + START | "run" with count   | "stop" after count
 4 | HALT                |  keep "stop"       | "halt" after count
 5 | HALT        + START | "run" with count   | "halt" after count
 6 | HALT + STOP         |  keep "stop"       | "halt" after count
 7 | HALT + STOP + START | "run" with count   | "halt" after count
---+---------------------+--------------------+---------------------

considerations:

(A) while the counter is "run"ning,
  (A1) the priority of events is HALT > STOP > START.
  (A2) the counter will advance when move to "stop"/"halt" state.

(B) while the counter is "stop"ped,
  (B1) the priority of events is START > STOP, HALT is ignored !!!!
  (B2) the counter will advance when move to "run" state.

- * - * -

I think all the actions above are very natural as synchronous circuit
except stop-to-run state transition.

When run-to-stop state transition, it is normal to do
these two actions with 1 clock.
  (CLK-1) count because the current state is "run"
  (CLK-1) move the state from "run" to "stop"

When stop-to-run state transition, it shall take 2 clocks
as (simplest) synchronous circuit.
  (CLK-1) do not count because the current state is "stop"
  (CLK-1) move the state from "stop" to "run"
  (CLK-2) count because the new state is "run"

But the SCT will start to count with state transition,
some (so called) look-ahead logic may be implemented here...
  (CLK-1) move the state from "stop" to "run"
  (CLK-1) count because the *next* state is "run"

 
[hr]
 

See attached ZIP file "sct-test-011.zip" about the detail of this examination.

FILES
  00README.txt --- this file
  Makefile     --- Makefile for make.exe
  link.awk     --- a AWK script to generate linker script
  Startup.S    --- CPU start up
  main.c       --- main entry
  common.h     --- system shared difinitions
  common.c     --- system shared functions (uart)
  rprintf.c    --- simple printf() (from sample of WinARM_20060606.zip)
  sct_test.c   --- a console to evaluate SCT
  test-NNN.hex --- a hex file image made
  zz-result.txt --- evaluation result log (with comments)

My LPC810 is:
    /*
     *   +------------+
     *   | LPC810     |
     *   ) P  M021F   |
     *   ) X  1M28603 |
     *   | N  +D3414C | ... year 3, week 41, '4C' ver.13.4
     *   +------------+
     *      | Dev.ID:  0x00008100
     *      | B.L.Ver: 13.4         <-- by FlashMagic
     */
And referecing:
    /*
     *   UM10601: LPC81x User manual Rev.1.6
     *   LPC81xM: Product data sheet Rev.4.3
     *   lpcopen_2_01_lpcxpresso_nxp_lpcxpresso_812.zip
     */

With above code, I had configured the SCT to use external clock from CTIN_0,
then drive CTIN_0 internally (thru SSEL of SPI0) by myself.

The test is executed like step-execution.[list=1]
[*] dump-registers
[*] give clock
[*] dump-registers
[*] give clock
[*] ...[/list]

'T' command is provided to run a set of tests, to re-produce this examination.

 
 
 

(to be continued...)