Aug 01, 2019
08:24 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 01, 2019
08:24 AM
Hello,
I'm seeing a number of failures due to the system clock (so far as I can tell) running at a lower frequency than expected on startup. This is only occurring on 3 out of the 100 units we've produced for far. Of those 3 it is very easy to reproduce, around 1 out of 5 startups will run at a different clock speed.
As far as I can tell, it is not a PCB issue, the clock signal is the same regardless of if the board is operating correctly. The signal from the clock is also identical to that of a passing board.
I've tried using the debugger on this and can't seem to find any conclusive issues with the clock and pll register settings being done in our code. There are some minor changes in the SCU module's register settings but these seem to mostly be in the WDT and RST submodules.
Does anyone know of a way to conclusively determine if this is an issue with the Aurix Processors (which is worrying) or if this is a software fault?
Cheers,
Details:
Aurix TC299 processor
I'm seeing a number of failures due to the system clock (so far as I can tell) running at a lower frequency than expected on startup. This is only occurring on 3 out of the 100 units we've produced for far. Of those 3 it is very easy to reproduce, around 1 out of 5 startups will run at a different clock speed.
As far as I can tell, it is not a PCB issue, the clock signal is the same regardless of if the board is operating correctly. The signal from the clock is also identical to that of a passing board.
I've tried using the debugger on this and can't seem to find any conclusive issues with the clock and pll register settings being done in our code. There are some minor changes in the SCU module's register settings but these seem to mostly be in the WDT and RST submodules.
Does anyone know of a way to conclusively determine if this is an issue with the Aurix Processors (which is worrying) or if this is a software fault?
Cheers,
Details:
Aurix TC299 processor
Labels
4 Replies
Aug 02, 2019
01:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 02, 2019
01:47 AM
Hi Radon,
on startup the backup clock is used and user software has to switch to PLL.
If there is something detected on the clock via internal monitors, AURIX switches back to backup clock to have a reliable base frequency.
Do you have the chance to check the differences of clock speed like outputting some signal and measuring it with an oscilloscope?
From there you can see what frequency you are running at.
As you write that this happens randomly you could also check, if the capacitors on the supply rails are as recommended and if you maybe ramp up the PLL too fast.
Did you also check what exactly the differences in the SCU lead to?
on startup the backup clock is used and user software has to switch to PLL.
If there is something detected on the clock via internal monitors, AURIX switches back to backup clock to have a reliable base frequency.
Do you have the chance to check the differences of clock speed like outputting some signal and measuring it with an oscilloscope?
From there you can see what frequency you are running at.
As you write that this happens randomly you could also check, if the capacitors on the supply rails are as recommended and if you maybe ramp up the PLL too fast.
Did you also check what exactly the differences in the SCU lead to?
Aug 02, 2019
07:25 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 02, 2019
07:25 AM
Also check that the Workaround for errata PLL_TC.005 is implemented in your PLL initialization.
Aug 20, 2019
11:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 20, 2019
11:04 AM
Hello,
I ended up trying the errata from PLL_TC.005 but that did not appear to resolve the issue.
I can verify the clock speed is changing, or at least the fcpu, fcan and fbaud clocks are changing. Fcpu by outputting the signal to an LED, which changes it's period from the default to a slower rate.
It could be a supply issue, I'll have to see if I can check that with an oscilloscope as well.
What I don't get is that we're supposed to be running at 300MHz, but if we're running at 1/2 speed that would be 150MHz. However if there is a clock error it should only be able to run at 100MHz. Right now I'm trying to push out the fpll to an external pin but am having no luck.
I ended up trying the errata from PLL_TC.005 but that did not appear to resolve the issue.
I can verify the clock speed is changing, or at least the fcpu, fcan and fbaud clocks are changing. Fcpu by outputting the signal to an LED, which changes it's period from the default to a slower rate.
It could be a supply issue, I'll have to see if I can check that with an oscilloscope as well.
What I don't get is that we're supposed to be running at 300MHz, but if we're running at 1/2 speed that would be 150MHz. However if there is a clock error it should only be able to run at 100MHz. Right now I'm trying to push out the fpll to an external pin but am having no luck.
Aug 22, 2019
07:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 22, 2019
07:56 AM
So after a bunch of playing around I found that it was the PLL settings.
First make sure to disconnect the PLL from the main oscillator before changing the Pdiv and Ndiv values.
Second was to follow the recommended values for Pdiv and Ndiv from section Table 3 of AP32201.
This took us from an incorrect clock on startup after 5 power cycles to no error in 17752 cycles.
It does seem to be related to the silicon, as 97% of the time it's fine. Would be nice to have a better guide on this from Infineon that describes how setting Pdiv and Ndiv can affect clock stability.
First make sure to disconnect the PLL from the main oscillator before changing the Pdiv and Ndiv values.
Second was to follow the recommended values for Pdiv and Ndiv from section Table 3 of AP32201.
This took us from an incorrect clock on startup after 5 power cycles to no error in 17752 cycles.
It does seem to be related to the silicon, as 97% of the time it's fine. Would be nice to have a better guide on this from Infineon that describes how setting Pdiv and Ndiv can affect clock stability.