LPC546xx SCTIMER Documentation errors and SDK bug or limetet SCTIMER INSYNC funktions?

[A_M]

Hi, I use the lpc54628 and have a problem whit the SCTimer (INSYNC).
Table 334. UM10912 Rev. 2.4 11 November 2019

I use 5 Inputs and all 10 events rise/fall edge. On inputs 0 – 3 whit INSYNC Bit 0 - 3 = 1 everything works like it should. But Input 4 doesn’t work properly. Too use it properly I must set the corresponding INSYNC Bit4 (13 Bit in SCT CONFIG Register). But the UM says these bits are reserved, the IDE shows that only Config Register bits 12 - 9 are for INSYNC and the SDK code also sets only 4 bits.

Se here:

 

 

LPC54628.h the Mask for the INSYSNC.

#define SCT_CONFIG_INSYNC_MASK (0x1E00U)
#define SCT_CONFIG_INSYNC_SHIFT (9U)

And also, the function SCTIMER_GetDefaultConfig() set only 4 bit INSYNC.

void SCTIMER_GetDefaultConfig(sctimer_config_t *config)
{
…
/* Default value is 0xFU, it can be clear as 0 when speical conditions met.
* Condition can be clear as 0: (for all Clock Modes):
* (1) The corresponding input is already synchronous to the SCTimer/PWM clock.
* (2) The SCTimer/PWM clock frequency does not exceed 100 MHz.
* Note: The SCTimer/PWM clock is the bus/system clock for CKMODE 0-2 or asynchronous input
* clock for CKMODE3.
* Another condition can be clear as 0: (for CKMODE2 only)
* (1) The corresponding input is synchronous to the designated CKMODE2 input clock.
* (2) The CKMODE2 input clock frequency is less than one-third the frequency of the bus/system clock.
* Default value set as 0U, input0~input7 are set as bypasses. */
config->inputsync = 0xFU;
}

Course when I set the 4 bit in INSYNC by debugger, apparently everything works like it should.

Is there an error in the documentation and SDK, or is there a something wrong in the Config Register bits 16 - 13 INSYNC (Bits 7-4) and we should not use them?

[A_M]

Hello  @Alice_Yang 

I add some Pictures and my test project whit the code changes.

1.Yellow is the Input4 (1Hz 50%/50% frequency generator).
2. Blue is the output kSCTIMER_Out_9.

In Picture tek00004.png - tek00006.png the Bits 13 – 16 are off. The detection of the rising edge is unreliable.

I switch the Bit 13(channel 4) on, and it works correct as expected see tek00007.png.

The behavior for all bits 13-16 channel 4-7 is the same as 9-12 channel 0-3. When I set the corresponding bit 1 it works immediately like it should.

It is hard to believe that the INSYNC function is only for channel 0-3 when the SCTimer have 8 inputs. There is also nothing in the errata too SCTimer.

Is this really not an error in the documentation and in the SDK? We are using this in a new product, and I need a reliable statement.

BR

A_M

[Alice_Yang]

Hello @A_M 

Thanks for your patience. 

I have reproduced on my side. Yes, I think this is doc issue.

When refer to UM, do not set bit 13 to 1. Keep it to reserved. 

Result as below ：

While set bit 13 to 1, 

Result as below:

I have reported it to related team. I will send to you with any update.

Sorry for  the inconvenient to you.

BR

Alice

[Alice_Yang]

Hello @A_M 

Sorry for the inconvenient for you. I will further check and confirm with our internal. I will send to you with any information. Thanks for your patience.

BR

Alice 

[jnol]

Hello @Alice_Yang
Do you have any further information on this?
Is it a doc issue and I can assume that I can synchronize all inputs?
BR
jnol

[Alice_Yang]

Hello @A_M 

INSYNC in CONFIG register controls  Synchronization for input. Only the four inputs input0-input3 have this function. 

- A 1 in one of these bits subjects the corresponding input to synchronization to the SCTimer/PWM clock.

- Clearing this bit bypasses synchronization on the corresponding input. This means disable synchronization function. but input function still works.

There is no this Synchronization function with Input4.  So it has no effect on input4 if setting 13 Bit in SCT CONFIG Register.

BR

Alice