Questions regarding Changing Clock speed 'on-the-fly'

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the xmega 128A3U in an application that supports a graphics display that is controlled with a SPI interface.  I also am using a Cypress flash memory device to store the graphics images.  This flash memory is also controlled with SPI.  The graphics display and flash memory are located on separate SPI ports.

 

The system initializes the system clock to 8 Mhz at boot and the application runs at this speed for 99% of the time.  At some point when the display needs an image read from flash and written to the screen, I reinitialize the PLL to bump up the speed to 32 MHz (SPI = 16 MHz) read the flash and write to the screen to provide a fluid screen update.  Once the screen update is complete, I go back to 8 MHz.  The reason for the dual clock speed approach is due to EMI performance, which I will not go into further.

 

The approach works well.  I make sure that I check the PLL to ensure that the clock is ready before the data exhange.

My question is, after the clock has been changed between frequencies does anyone know of any 're-initializing' of the SPI port that would be necessary.  Are there an caveats that I should be cautious of when attempting this clock changing.  I've seen a couple of flaky issues that I cannot explain and am wondering if I am missing something subtle.

 

I would appreciate you opinions of potential subtle problems with this approach.

Thanks

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of "flaky" issues, can you be more specific?

 

I have not used the xmega's yet, so I can not recommend any specifics, but I have used a lot of mega's and tiny's.

In both cases, I have changed the CLKPR and or PLL on the fly and have not had any issues.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should be absolutely fine. However I would wait for any current SPI operation to complete first. Especially DMA transactions.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi -

Yes, I should have clarified the real problem.  I am attempting to find a reason for an anomaly that has occurred on about 4 circuit cards (built about 150) where the data from the flash memory cannot be correctly read.  It appears that for every byte read, several bits are corrupt.  The reason that I have come to that conclusion is that the video images are being rendered in a way that the colors are incorrect.  The main image is correct, i.e. the data read is not total garbage, but the RGB data is slightly corrupted making the color rendering incorrect.  I also know that the problem is not the graphics display because I have some non image data from the same flash that gets read and turns out to be corrupted.  The odd part is that once the flash memory goes into this 'mode', no power cycling will reset the problem.  I can reset the board a dozen times, power off/on, etc.  Problem remains.  Then all of a sudden, the problem disappears and cannot be repeated.  This has happened on about 4 boards out of 150 or so.  Frustrating to troubleshoot problems such as this as we all know.

 

I've reviewed the board layout, investigated possible  bad flash material, electrical issues such as POR timing and see nothing wrong.  Contacting Cypress has also not been productive.

 

The clock speed swap-over is being considered as a possible issue.  I thought the swap-over *might* be glitching the flash memory is some funky manner.  I plan on doing some additional testing today to try and recreate the issue.  My hope was that someone may know of some abnormal behavior the Xmega part could be experiencing during this clock switch over.

 

Hopefully this hasn't been too wordy an explanation.

Thanks again -

Jim

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

4 out of 150, sounds like a hardware problem, like a marginal solder joint (reflow the pcb again), or if using water soluble flux,(re-wash pcb again), it will take a very close inspection of it all to find.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you have the failing devices periodically log what they read from the flash memory to something like UART ? So you can see where and how the data is actually corrupt. (rather than just the observation of "wrong colored graphics").

 

But like Jim, it seems to me that faults that aren't even cured by power cycle but that then mysteriously correct themselves later sounds like intermittent connection problems. Could this be a "heat" thing? If you either heat or freeze the boards does that either correct a failing one or cause a non-failing one to then fail? How about other environmental effects like nearby electrical noise or vibration/shaking ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rfdes wrote:
Contacting Cypress has also not been productive.
If the cause is the external flash, consider patching a competitor's product and re-trying.

rfdes wrote:
My hope was that someone may know of some abnormal behavior the Xmega part could be experiencing during this clock switch over.
XMEGA SPI threads with pending questions :

http://www.avrfreaks.net/forum/issues-xmega-128a3u-possible-production-problem

http://www.avrfreaks.net/forum/a3bu-spi-issue

 


http://www.microchip.com/design-centers/memory/serial-parallel-flash

 

Edit : typo

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Oct 11, 2017 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might as well ask:

 

Are ALL Vcc and the AVcc pins connected to the V+ supply?

Are ALL Ground and AGround pins connected to the system Ground?

 

Do ALL Vcc/Ground and AVcc/Ground pins have a 0.1 uF by-pass cap installed very close to the uC's pins?

 

If you don't change the system clock, do the boards still fail, or do they work correctly?

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
 faults that aren't even cured by power cycle but that then mysteriously correct themselves later sounds like intermittent connection problems. 

Could be marginal timing somewhere: so the power cycle does actually cure the problem - but it just recurs

 

EDIT 

 

Or a glitch which occurs "near" some critical point - and sometimes "near" becomes "at" ...

Last Edited: Wed. Oct 11, 2017 - 08:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I appreciate all of the advice.  I need to review the power up timing to see if I have issues in that regard.  At the present, I have no boards that are exhibiting the problem.  I have yet been able to 'force' a previously failed board to repeat the failure.

 

More work to do...

 

Thanks again -

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

    Make sure the clock and phase are correct. It could be that your working boards work at the edge. Rising the clock frequency makes thing to no longer tolerate it. Another thing I would test is to lower the clock frequency by half. And obviously, a logic analyzer view during osc change would be first on my plate.

 

    George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a thought, could you use the 32MHz RC oscillator instead of the PLL? Then you don't need to actually change the PLL setting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible that you are changing clock frequency before a write cycle to the flash has been completed, mucking up the timings of the flash & causing the corruption?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IPguru wrote:
Is it possible that you are changing clock frequency before a write cycle to the flash has been completed

If that were happening consistently then, surely, it would always fail?

 

So  maybe there's a "corner case" where this kind of thing can happen - but doesn't very often ... ?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If there are any delays in the code - are they being properly adjusted for the changing clock ... ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:

    Make sure the clock and phase are correct. It could be that your working boards work at the edge. Rising the clock frequency makes thing to no longer tolerate it. Another thing I would test is to lower the clock frequency by half. And obviously, a logic analyzer view during osc change would be first on my plate.

 

    George.

+1

I've had boards where the spi (in this case a DAC) worked correctly for a long time and then started exhibiting very infrequent malfunctions.  A closer inspection revealed that I had originally chosen the wrong spi mode for that part.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again fellows -

 

Actually, the hardware had been working at the 32 MHz clock (16 MHz SCLK) since the inception with no know issues.  I've observed the signals on a scope and all appears

as it should.  Simple MODE 0 stuff... I am using one of the USART in the Master SPI mode.   Now I run the hardware at 8MHz and only switch to 32 MHz during the Flash reading.

There is no writing done to the flash in our system, the flash is preprogrammed at production.

 

What I have done is build a test version of the firmware that will reinitialize the SPI port that is used to communicate with the FLASH.  My suspicion is that the xmega usart peripheral is being

'glitched' at the clock swap and needs to be reinitialized.

 

Proving the testing of the firmware will be inconclusive.  When (and if) I get a glitched board and load the firmware, if the problem is not resolved you know the initializing of the Usart doesn't work. 

However, if the problem disappears you will not know with 100% certainty if that was the fix. 

Of course it certainly cannot hurt but only help.

 

What I plan on doing is setting up some test hardware that will cycle system power every 5 seconds or so and capture some uart debug information that will pause the power cycling once the anomaly

appears.  The uart information will report back some known data from the flash.  If the reported data is corrupted I will know that the anomaly has reappeared.

 

take care -

Jim