RT1170-EVKB hangs when set core at 800MHz with PMIC

[mastupristi]

Hi,

It seems that there is some problems when I set 800MHz as core clock, when PMIC is used and DCDC is bypassed. Note that on legacy EVK (w/o PMIC) all works.
I have SDK_2_15_000_MIMXRT1170-EVKB.zip as SDK installed in MCUXpresso IDE v11.9.0 [Build 2144] [2024-01-05]
I use J-LINK and so I also closed J5.

I attach my design for you to try out

I modified my RT1170-EVKB to use PMIC, as stated in the schematic

Then I took the "hello-world" example from the sdk. By default it would use DCDC, but by using SKIP_DCDC_CONFIGURATION=1 in the preprocessor settings, I verified that the example works. But core clock is 996MHz.

I want run @800MHz. So I used the config tool embedded in MCUxpresso, to set 800MHz.

The FW so it dies "badly". Badly means I get to line 432 of config_tool.c I don't get out. But even worse, the debugger itself goes bad, which makes us think about the core no longer being clocked in

I summarize here the tests I performed:

	ARM_PLL_CLK (MHz)	core clock (MHz)	result
1	1992	996	OK
2	2400	800	Fail
3	2400	600	OK
4	2388	796	Fail
5	1596	798	OK
6	1800	900	OK
7	2496	624	OK
8	2496	832	Fail

ARM_PLL_CLK can run as high as 2496MHz. This limit is never exceeded

To set the PLL and dividers and have the clock at 800MHz I had the config tool calculate.

where is the mistake?

best regards

Max

[EdwinHz]

Hi @mastupristi,

I believe you have stumbled on the issue described on the following knowledge base article: Issues with BOARD_BootClockRUN_800M on RT1170 - NXP Community

It seems that some batches of the RT1170 have faulty ARM PLL's, that reduce the 2496MHz estimated max frequency, and cause issues when this PLL is set to work at frequencies near this value. I would recommend you follow the workaround on that post, since this issue is on the silicon level.

BR,
Edwin.

[mastupristi]

Hi @EdwinHz 

first of all your link is broken, please provide me with a verified one.

And then the thing you say should be better argued.
You say that the RT1176 mounted on my EVKB might be from a "defective" batch, and that the PLL at too high frequencies does not work. Right?

It seems to me to be a rather hasty conclusion compared to the evidence that we have done.

In fact, if I set the PLL to 2.4GHz and then divide by 3 to make 800MHz, it doesn't work. The same 2.4GHz divided by 4 makes the 600MHz core work correctly, though. I deduce that the problem should not be the PLL. I also did similar demonstration with PLL at 2.496GHz.

Also, if I revert the changes to EVKB, to not use PMIC and use the internal DCDC, then everything always works. The problem seems to be related to DCDC. When using PMIC and not DCDC we have the problems, while with DCDC we do not.

If the problem was really the faulty PLL, it should not work at 800MHz as it does at 600MHz. It should not work whether using the PMIC or the internal DCDC... or at least intuitively I would think so.

Finally, if they really were batches of faulty processors, could you give me the list of these batches so that we can verify it.

regards

Max

[EdwinHz]

Hi @mastupristi,

You mentioned that you used ConfigTools to modify the frequencies and set the core clock to 800MHz. But does this issue also happen when using the "BOARD_BootClockRUN_800M" function from SDK 2.15 as stated on this other community post?

BR,
Edwin.

[mastupristi]

Hi @EdwinHz 

I honestly left the setting on BOARD_BootClockRUN.

However, there is something that really stands out.
Here a screeshot of the config tool

the clock branch leading to the core is well highlighted in blue.

In the post you linked is this sentence:

The issue is caused by the internal ARM PLL which is unable to generate a high enough clock signal on some batches of the RT1170. As described on the post you refer to, the BOARD_BootClockRUN_800M sets the ARM PLL to 2.4GHz, and then sets its divider to 3, and this way it achieves an 800MHz signal. However, this 2.4GHz is basically the absolute maximum operating frequency for this PLL, as the datasheet rates its maximum clock output range as 2496 MHz:

so somehow the PLL doesn't generate frequencies above 2400MHz right? Maybe some parts don't even generate 2350MHz? In fact I have cases where 2400MHz does not work (but I also have cases where it works at 2496MHz!!!)

So, you say, the problem lies in the left side of the image

But if the PLL does not generate the clock, no matter how much it divides CLOCK_ROOT0.DIV, nothing will get to the clock, right?
Then how do you explain that if I divide by 4, (at 600MHz) the core works? This is incontrovertible evidence that the PLL generates clocks at 2.4GHz. And this 2.4GHz is the same that divided by 3 doesn't run the core.

And it works even if I divide by 5 (cores @480MHz), etc. It doesn't work if I divide by 3 (core @800MHz), though.

Not only that, my tests show that the PLL can reach its stated maximum speed 2496MHz as long as the divider is not less than 4. And this happens on the component that dividing 2.4GHz by 3 does not work.

Other evidence: how do you explain that everything starts working again if you use internal DCDC instead of PMIC?

I'll re-post you a more detailed table of results

	ARM_PLL_CLK (MHz)	CLOCK_ROOT0.DIV	core clock (MHz)	result (PMIC)	result (DCDC)
1	1992	2	996	OK	OK
2	2400	3	800	Fail	OK
3	2400	4	600	OK	OK
4	2388	3	796	Fail	OK
5	1596	2	798	OK	OK
6	1800	2	900	OK	OK
7	2496	4	624	OK	OK
8	2496	3	832	Fail	OK

In reference to the text quoted above, assuming this is indeed the case then NXP MUST provide the following information:

• The complete and exhaustive list of RT1170 batches affected by the problem
• A new table of PLL parameters, in which the new maximum value (that cannot be exceeded) is given.
• Update the errata describing the workaround in that official document

I will try to do more testing, but to me it seems more like something related to DCDC than PLL

best regards

Max

[mastupristi]

I did some more testing, going for the threshold frequency at which it stops working when the divider is 3

here is the updated table

	ARM_PLL_VDIV	ARM_PLL_CLK (MHz)	CLOCK_ROOT0.DIV	core clock (MHz)	result (PMIC)	result (DCDC)
1	133	1596	2	798	OK	OK
2	150	1800	2	900	OK	OK
3	166	1992	2	996	OK	OK
4	190	2280	3	760	OK	OK
5	192	2304	3	768	OK	OK
6	193	2316	3	772	OK	OK
7	194	2328	3	776	Fail	OK
8	195	2340	3	780	Fail	OK
9	199	2388	3	796	Fail	OK
10	200	2400	4	600	OK	OK
11	200	2400	3	800	Fail	OK
12	208	2496	4	624	OK	OK
13	208	2496	3	832	Fail	OK

as you can see I have cases where the PLL works up to 2496MHz, conversely I have cases where the PLL does not work at 2328MHz.

S/N of my EVKB is TR22511725

Processor marking is:

I give you this info on the off chance that it really is a batch of faulty processors. This component should be of the 23rd week of 2022

However, we have experienced this problem on other processors, certainly from other batches

this should be of the 27th week of 2021

Again, in my opinion, it's not the PLL that's not working, but the interaction of the PLL with other settings, and certainly DCDC is also involved

regards

Max

[EdwinHz]

Hi @mastupristi,

After deliberating with internal, we came to the conclusion that this might be an unexpected behavior caused due to clocking the ARM PLL higher than 1GHz. Could you see if this issue is present when limiting the ARM PLL to 1GHz (while using the PMIC)?

Understandably, the ARM PLL has a maximum output frequency of 2496 MHz as stated by "Table 27. Arm PLL’s electrical parameters" of the datasheet. However, the note presented under section "4.2.5 PLL’s electrical characteristics" states that the ARM PLL "should be not greater than 1GHz on over drive mode, 800MHz on normal drive mode and 480MHz on under drive mode." This is in order to ensure the proper functionality of the PLL and prevent unusual behaviors, like the ones you are experiencing right now with the use of the external PMIC.

BR,
Edwin.