Here is another issue that should be a triviality but is probably going to turn into a week-long quest, like everything else in the S32G2: How does one enable the A53s' System Counter? This is a critical 64-bit clock that is distributed by the S32G2 to all four A53 cores and used for ubiquitous purposes of wait, timeout, etc.
The root functionality of this clock is external to the cores, as it must be. It is the responsibility of the SoC hosting the cores. ARM (cf. A53 TRM) suggests an interface, such as the existence of a register called "CNTCR", to implement what it calls "Generic Timer". A top-to-bottom search of the entire S32G2RM for various keywords, such as "system counter" and "CNTCR" and "generic timer" yielded nothing of value.
As an experiment, I looked at another SoC, the LS1046A. In the LS1046A's RM, I immediately see a chapter called "System Counter". Obvious. In that chapter, four registers are explained, one to set the frequency (CNTFID0), one to enable the clock (CNTCR), and a pair to read the clock's 64-bit time (CNTCV). Obvious. These are the only three things that anyone would want to do, right there in the open. Between the time I decided that I wanted a clock to the time that the clock was working, only five minutes would elapse. Why is it so difficult to do such a simple and important thing in the S32G2? If everything else in the S32G2 is like the things I already experienced, then the true cost of this processor is much, much higher than expected.
How does one configure and enable the System Counter that is provided by the S32G2 to its A53 cores?
Solved! Go to Solution.
Hi @carlo-nonato. I can't tell from your description if it's exactly the same situation, or what your "symptoms" are, but I can tell you a brief story about clocking that will probably solve your problem, somehow.
There are many, many things in the S32G2 that require a clock. Perhaps the most important examples are the four Cortex-A53s. There are, essentially, two physical clock sources: FIRC and FXOSC. FIRC is internal to the S32G2, while "FXOSC" is more like an interface, to be supplied by an external clock (crystal oscillator). We are using NXP's S32G-VNP-RDB2 board, which has a 40MHz crystal supplying this FXOSC. I think the idea is that the FXOSC is more accurate, reliable, etc. FIRC is intended to be used only for a brief time after power-on, before switching to FXOSC. For that reason, almost everything important is supplied by FIRC when FXOSC is absent (and, at power-on, FXOSC is disabled, presumably because choices must be made that the S32G2 can't possibly know about).
So, even if you do nothing, the A53s still work and your code can still execute. Note that execution is extremely slow, because scaling up to speeds like 1GHz is done in the PLL, which must be done by software (the FIRC ticks at 48MHz, and I bet that this is what the A53s run at if you do nothing, but I didn't test this; all I know is that it is very slow).
The System Counter that the S32G2 supplies to the A53s is an exception: it is driven only by FXOSC, and if FXOSC is inactive then CNTPCT does not increment.
So, you must enable FXOSC, via FXOSC's CTRL register @ 0x40050000. This is not completely trivial, and some choices need to be made that I can't advise you about. The S32G2RM explains how to think about those choices.
Immediately after enabling FXOSC, System Counter will start incrementing. Assuming that your crystal is running at 40MHz (which is probably very common) then you may notice that the System Counter is running at 5 MHz (you can discover this using a wristwatch or smartphone app). Why? This is because there is a divider, A53_GPR00[CA53_COUNTER_CLK_DIV_VAL] that defaults to 0b111==7, and the FXOSC is divided by 1+CA53_COUNTER_CLK_DIV_VAL==8, which is how you get 40MHz/8==5MHz. Whatever frequency you decide, it is customary to set CNTFRQ to this value, because that register is the reference for various clock-related logic. Probably everything in this paragraph should be done before enabling FXOSC.
As far as I know, it works the same on the S32V234, but I didn't spend much time researching this. If you had no difficulties there, it was probably because somebody installed a DCD that does all this stuff before the software runs. I'm not aware of any memory-mapped registers to read the System Counter, but you can read CNTPCT using inline assembly.
I hope that's helpful.
May I ask how you guys solved the mentioned problem?
I'm in a similar situation. I want to read the CNTPCT_EL0 value from the Cortex-M7 and with other SoCs I'm able to do that via the system counter registers (e.g. in the iMX8M or in the S32V234 I can do that reading two 32 bit registers), but in the S32G2 it seems undocumented.
Thanks.
Hi @carlo-nonato. I can't tell from your description if it's exactly the same situation, or what your "symptoms" are, but I can tell you a brief story about clocking that will probably solve your problem, somehow.
There are many, many things in the S32G2 that require a clock. Perhaps the most important examples are the four Cortex-A53s. There are, essentially, two physical clock sources: FIRC and FXOSC. FIRC is internal to the S32G2, while "FXOSC" is more like an interface, to be supplied by an external clock (crystal oscillator). We are using NXP's S32G-VNP-RDB2 board, which has a 40MHz crystal supplying this FXOSC. I think the idea is that the FXOSC is more accurate, reliable, etc. FIRC is intended to be used only for a brief time after power-on, before switching to FXOSC. For that reason, almost everything important is supplied by FIRC when FXOSC is absent (and, at power-on, FXOSC is disabled, presumably because choices must be made that the S32G2 can't possibly know about).
So, even if you do nothing, the A53s still work and your code can still execute. Note that execution is extremely slow, because scaling up to speeds like 1GHz is done in the PLL, which must be done by software (the FIRC ticks at 48MHz, and I bet that this is what the A53s run at if you do nothing, but I didn't test this; all I know is that it is very slow).
The System Counter that the S32G2 supplies to the A53s is an exception: it is driven only by FXOSC, and if FXOSC is inactive then CNTPCT does not increment.
So, you must enable FXOSC, via FXOSC's CTRL register @ 0x40050000. This is not completely trivial, and some choices need to be made that I can't advise you about. The S32G2RM explains how to think about those choices.
Immediately after enabling FXOSC, System Counter will start incrementing. Assuming that your crystal is running at 40MHz (which is probably very common) then you may notice that the System Counter is running at 5 MHz (you can discover this using a wristwatch or smartphone app). Why? This is because there is a divider, A53_GPR00[CA53_COUNTER_CLK_DIV_VAL] that defaults to 0b111==7, and the FXOSC is divided by 1+CA53_COUNTER_CLK_DIV_VAL==8, which is how you get 40MHz/8==5MHz. Whatever frequency you decide, it is customary to set CNTFRQ to this value, because that register is the reference for various clock-related logic. Probably everything in this paragraph should be done before enabling FXOSC.
As far as I know, it works the same on the S32V234, but I didn't spend much time researching this. If you had no difficulties there, it was probably because somebody installed a DCD that does all this stuff before the software runs. I'm not aware of any memory-mapped registers to read the System Counter, but you can read CNTPCT using inline assembly.
I hope that's helpful.
Thank you very much for such a detailed description.
Unfortunately this doesn't solve my actual problem (reading the system counter outside of the A53s), but it surely gives me a lot of crucial information which I'll definitely need one day or the other.
Thanks again!
yes, I'm not sure that it's possible to do what you want, enable and read the System Counter from the Cortex-M7; you are correct that it would be possible if (like the LS1046A) it was all memory-mapped through the SoC; but the actual value of the clock seems to be absent; so, you could actually enable it from the Cortex-M7 (FXOSC), but I don't know how you could read its value, no way to reach into the Cortex-A53 from the Cortex-M7
Thank you for reaching out to us.
I have initiated a thread with NXP internal team regarding the same. I will get back to you soon.
Thanks,
Mayank s Patel
Generatic timer is the system timer in ARM architecture, BSP use Generatic timer as default system timer. it can be enabled PIT or STM from menuconfig like below
You will get detailed information about register of Generic timer from ARMv8 architecture document.
Thanks,
Mayank s Patel
This response is totally wrong. STM is a 32-bit clock that has absolutely no relationship to either the A53 cores or to their "System Counter", except for superficial similarity in the names, "System Timer Module" vs. "System Counter". PIT is some other thing, also unrelated.
I am confused how there can be such a disconnect between the question and the response. A reference to an ARM document cannot possibly have the answer. As the A53 TRM explains, and as I repeated in my post, the System Counter is implemented outside the cores. From the A53 TRM: "The Cortex-A53 processor does not include the system counter. This resides in the SoC.". It is part of NXP's hardware, not ARM's. You casually posted a screenshot from the A53 TRM, but you don't understand what's in it. None of those registers controls the System Counter.
User @kf6uzf solved the problem already, the System Counter is working now.
Hope you are doing well.
The issue is resolved? Or do you need any support on this?
Can you please post the solution which you apply to work the system counter here.
Thanks,
Mayank s Patel
yes, we resolved it, System Counter works now
Thanks for the reply.
Can we close this ticket?
You can always create a new ticket for the issue you face in the future.
Thanks,
Mayank s Patel
that's fine
ok, thanks very much
I was told that the System Counter in a related processor, the S32V234, "works automatically following reset", which explains why there are no overt controls for it; however, it doesn't seem to work "automatically" for the S32G2, both CNTPCT and CNTVCT are constant during early boot following BootROM, IVT, etc.