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
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.
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
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.
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:
I will try to do more testing, but to me it seems more like something related to DCDC than PLL
best regards
Max
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
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.