Wrong handling of FLEXCOM Fractional rate divider on LPC55xx

cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong handling of FLEXCOM Fractional rate divider on LPC55xx

129 Views
Contributor III

Hi,

The Configuration tool integrate in MCUXpresso IDE 11.2.0 generates badly wrong code for the fractional divider in front of the FLEXCOM module!

1) The Clock Diagram shows FRGCTRLx_MUL as fixed to 256, according to UM11126 (rev 1.9) this is wrong, the Multiplier value can be set from 1 to 256 (Register value 0..255).

2) The Clock Diagram allow to set FRGCTRLx_DIV from 256 to 511, according to UM11126 (rev 1.9) this value has to be fixed to 256 (Register value 255) to enable the use of the divider.

3) The value set in FRGCTRLx_DIV - 1 gets written to FLEXFRGxCTRL with out any check (see function CLOCK_SetClkDiv() ) this results in an invalid DIV value!

Best regards

Martin

0 Kudos
4 Replies

96 Views
NXP Employee
NXP Employee

Hi Martin,

The FlexCOMM Interface function clock is computed as follows:

FlexCOMM clock = 

= (clock selected via FCCLKSEL) / (1+ FLEXFRG0CTRL[MULT] / FLEXFRG0CTRL[DIV])

= (clock selected via FCCLKSEL) / ((FLEXFRG0CTRL[DIV]+ FLEXFRG0CTRL[MULT]) / FLEXFRG0CTRL[DIV])

= (clock selected via FCCLKSEL) * FLEXFRG0CTRL[DIV] / (FLEXFRG0CTRL[DIV]+ FLEXFRG0CTRL[MULT])

The FLEXFRG0CTRL[DIV] has always equal to 255, meaning the denominator value is 256, hence:

FlexCOMM clock = 

= (clock selected via FCCLKSEL) * 256 / (256 + FLEXFRG0CTRL[MULT])

In Clocks tool, the above equation is represented as:

FXCOM0 clock = (clock selected via FCCLKSELx) * FRGCTRLx_MUL / FRGCTRLx_DIV

where 

FRGCTRLx_MUL  = 256

FRGCTRLx_DIV = 256 ~ 511 (or in other words 256 + (0 ~ 255))

Refer also to descriptions of FRGCTRL0_MUL and FRGCTRL0_DIV:

In other words, FRGCTRLx_MUL in Clocks tool represents bits FLEXFRGxCTRL[DIV] and FRGCTRLx_DIV represents FLEXFRGxCTRL[DIV] + FLEXFRGxCTRL[MULT] 

Therefore I think writing FRGCTRLx_DIV - 1 value directly to FLEXFRGxCTRL register is OK as it in fact represents combination of FLEXFRGxCTRL[DIV] and FLEXFRGxCTRL[MULT] bits.

However, we recognize confusion in the naming of settings in Clocks tool vs naming of the bits and we plan improving names in the the next version of the tool.

Sorry for the inconvenience it caused.

Regards,

Lukas  

0 Kudos

93 Views
Contributor III

Hi Lucash,

Thanks for Your answer, but i still convinced that the value written to the register FLEXFRGxCTRL is wrong.

Because:

1) UM11126 on page 73 claims that Bit 0..7 (DIV) has always to be set to 0xFF.

2) Bit 8..15 (MUL) can be set from 0 to 255 ( 0: Fout = Fin / (1  + 0/256) --> Fout == Fin, 255: Fout = Fin / (1 + 255/256) --> Fout = Fin / 1.99609375 ).

What You do is writing a value between 255 and 510 directly to FLEXFRGxCTRL, this evidently violates point 1 and results in the Fractional rate divider switching to Fout = Fin for any value You are writing to the register ( because DIV is not 0xFF ).

The only value that is working is when You write 255 to the register ( Fout == Fin )

If You want to retain The "logic" You are using at the moment You have to:

 FLEXFRGxCTRL = 0xFF | ((FRGCTRLx_DIV - 256) * 256);

best regards

Martin

0 Kudos

53 Views
NXP TechSupport
NXP TechSupport

Hi Martin,

Thank you for the feedback provided. Do you have a small example you can share that demonstrates this behavior so that I may replicate it from my end. I understand what you mean by the register values, however are you also seeing the incorrect frequency on the flexcomm once it is configured using the config tools?

Best Regards,

Sabina

0 Kudos

49 Views
Contributor III

Hi Sabina,

Thanks for the answer, un fortunately I don't have time to prepare You an example. But I can assure You that the divider settings are not working. In my Application I used FLEXCOM1 as asynchrone UART dividing a 50MHz clock to 40MHz. The resulting Baud-rate was off by about 20% ( The clock feeded to the FLEXCOM1 was 50Mhz ). Changing the clock to 40MHz input and 40MHz output by setting the divider to 1:1 ) the Baud-rate is ok.

Martin

0 Kudos