LPC54628J512 Configuration tool bug

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC54628J512 Configuration tool bug

1,347 Views
microcris
Contributor III

Hello!

While "playing" with the configuration tool (online, loca MCUXpresso Config Tools and MCUXpresso IDE) I found two situations that (I think) are not correct.

1 - System Clock Speed

if I configure the PLL to 220MHz an error is trown saying that the maximum speed is 180MHz

The problem seems to be inthe TOP.xml file

<constraint max_freq="220 MHz" when="queryFeature(`Configuration`,`Processor`,`Name`) == `LPC54628J512`"/>
<constraint max_freq="180 MHz" when="queryFeature(`Configuration`,`Processor`,`Name`) != `LPC54628J512`"/>

It seems the processor name is not correctly identified.

2 - FRGCTRL

The user manual sates the following about the Divider:

Remark: In order to use the fractional baud rate generator, 0xFF must first be written to
the DIV value to yield a denominator value of 256. All other values are not supported.

And yet, in the configuration tool, the MUL is locked to 256 and the DIV can be changed.

Best regards,

Cristiano Rodrigues

0 Kudos
3 Replies

1,050 Views
marek_neuzil
NXP Employee
NXP Employee

Hello Cristiano,

Thank you for reporting these issues. The first issue has been already reported (MCUXCON-4531) and it is under analysis by the Clocks tool development team. It should be resolved in the upcoming release of the MCUXPresso Configuration Tools V6.0.

Let me know if you need a hotfix for this issue (the constraint can be set to 220 MHz for all LPC546xx MCUs on your local copy of MCUXpresso Configuration Tools data).

The second issue is related to confusing names of the mutliplier and divider in the reference manual, see the answer in the discussion thread https://community.nxp.com/thread/484831

 

Best Regards,

Marek Neuzil

1,050 Views
microcris
Contributor III

Thank you for your answer, Marek.

Regarding the Fractional baud rate generator, if the following remark is to be taken seriously, it will be not possible to use it with without the FRO oscillator.

Remark: When the FRG is used to create a clock for use by one or more Flexcomm
Interfaces (the typical use of the FRG), the FRG output frequency should not be higher
than 48 MHz.

I'm using the Fractional Baud Rate Generator at 110215264Hz (main clock at 220MHz "drived" by an external 12MHz crystal and FRGCTRL= 0xFFFF), and, so far, it seems to working without problems. So, why the 48MHz limit?

And, by the way, there is a least one fix that needs to be made in the fsl_clock.c driver. That is:

In the uint32_t CLOCK_GetFrgClkFreq(void) function, you are not taking in to account the FRGCTRL content. This function is returning the same value as the uint32_t CLOCK_GetFRGInputClock(void) function

It needs to be changed from this

uint32_t CLOCK_GetFRGInputClock(void)
{
    uint32_t freq = 0U;

    switch (SYSCON->FRGCLKSEL)
    {
        case 0U:
            freq = CLOCK_GetCoreSysClkFreq();
            break;
        case 1U:
            freq = CLOCK_GetPllOutFreq();
            break;
        case 2U:
            freq = CLOCK_GetFro12MFreq();
            break;
        case 3U:
            freq = CLOCK_GetFroHfFreq();
            break;

        default:
            break;
    }

    return freq;
}

to something like this:

uint32_t CLOCK_GetFrgClkFreq(void)
{
    uint32_t freq = 0U;

    switch (SYSCON->FRGCLKSEL)
    {
        case 0U:
            freq = (CLOCK_GetCoreSysClkFreq() / (1.0 + (float)((SYSCON->FRGCTRL & 0XFF00) >> 8) / ((SYSCON->FRGCTRL & 0X00FF) + 1.0)));
            break;
        case 1U:
            freq = (CLOCK_GetPllOutFreq() / (1.0 + (float)((SYSCON->FRGCTRL & 0XFF00) >> 8) / ((SYSCON->FRGCTRL & 0X00FF) + 1.0)));
            break;
        case 2U:
            freq = (CLOCK_GetFro12MFreq() / (1.0 + (float)((SYSCON->FRGCTRL & 0XFF00) >> 8) / ((SYSCON->FRGCTRL & 0X00FF) + 1.0)));
            break;
        case 3U:
            freq = (CLOCK_GetFroHfFreq() / (1.0 + (float)((SYSCON->FRGCTRL & 0XFF00) >> 8) / ((SYSCON->FRGCTRL & 0X00FF) + 1.0)));
            break;
        default:
            break;
    }

    return freq;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
0 Kudos

1,050 Views
marek_neuzil
NXP Employee
NXP Employee

Hello Cristiano,

I have checked the implementation of the CLOCK_GetFrgClkFreq() on the LPC546xx MCUs and there is a defect as you have pointed out. I have logged the issue (KPSDK-26342). It should be fixed in the next release of the SDK.

Thank you for reporting of this issue.

Best Regards,

Marek Neuzil