Need a confirmation, a test to be made with the SAM V71 Xplained Ultra board and Softpack v1.5!

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

Hi Folks!

 

I have a quite weird issue on my Xplained Ultra board. The thing is something that is nonsense and I would ask You to check it on your own one!

 

I am using Atmel Studio 7.0. (ver. 7.0.1188) Compiler is GCC version 5.3.1.

The tool used is EDBG. No optimization is applied to the code.

 

In short words: the 'USB Device CDC' example in the 'AS Software Package 1.5' works well until it applies SDRAM writes... then it makes the program to be frozen after some time when doing the 'test' with it.

 

---

In details:

To check the thing:

  • Download the "SAMV71-XULT Atmel Studio Software Package 1.5". And open example located at .\examples_usb\device_examples\usb_cdc .
  • Since I have troubles with CDC when the code is located on flash, I use the 'sram' linker script and the flash is erased. (Though, running from flash it is the same faulty as from SRAM.)
  • Make Tiny modifications to the source code:
    • in main.c just before 'USBD_Connect();', add these two lines to enable the SDRAM:
          _SetupMemoryRegion();
          BOARD_ConfigureSdram();
    • in main.c, _SendText() function, replace 'while (!txDoneFlag);' with 'while (!txDoneFlag) SDRAM_write();'
    • Implement 'SDRAM_Write()' as:
          void SDRAM_write()
          {
              uint32_t* p = (uint32_t*)SDRAM_CS_ADDR;
              for(int i=0; i<8; i++) *(p++) = 0xffff0000;    //or any value...
          }
  • Open the EDBG Virtual COM port with a terminal like PuTTY.
  • Connect the board to the PC through the USB, then run the modified code. A new device appears and some COM port is assigned to it. (Check in device manager or such.)
  • Open this new COM port (CDC) with another terminal.
  • Press 't' key some times on the EDBG Virtual COM port's terminal. After some tries the board is frozen (infinite loop waiting for and USB (endpoint) to be ready) and it does not do anything more.

 

If You comment out the '*(p++) = 0xffff0000;' from the code, so no writes are made to the SDRAM, it works without error. At least for me...

---

 

Please confirm that this fault is present on other board pieces too, not only on mine!

Any thought on this kind of error is welcome since I am not able to imagine anything that should work like this.

 

(I have spent 1 full month yet to discover such 'bug' in my own project, where the same was present: USB (host) gets error when I use (write) the SDRAM quite often. Lowering the write frequency may lower the risk of the fault, but this is not so simple... it's very complicated. My project's USB and SDRAM code has been ported to the Xplained Ultra board and it shows the same error, but even more frequently! And only depends on the SDRAM write access. Oh, my god... what is this???)

 

Thank You!

Zoltan

Last Edited: Sun. Jan 8, 2017 - 01:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I reply for myself. Discovered this fault... (still not the main one, but anyway. Later.)

 

It's all about the RXD2 line on the board. It is wired very close and parallel to the SDRAM lines (like SDWE) and each time I make a write access to the SDRAM (2 bytes, cache cleared), a huge and short positive pulse is present on RXD2, despite the line is driven to low. And the program stops when it tries to write data (zeros) to the USB (in XDMAC or USART2 handler).

 

This case don't need to be solved. I can now continue discovering the main fault.

 

Last Edited: Sun. Jan 8, 2017 - 04:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

we have got problems while using SDRAM memory in our code too. And they looks the same weird freezes or memory corruptions.  We examined sam-v71 in Ethernet to SDRAM access configuration and SDRAM test with USB-log on sam-e70 (without using any debug interface).
We got to the conclusion these configurations can work stable only when CACHE is turned OFF!!! It is done by commenting the lines:
//    SCB_EnableICache();
//    SCB_EnableDCache();
in the initialization.
So I tend to think there is internal defect (or inconsistency) in the processor line between SDRAM controler and MPU.
There is no full functional test for SDRAM access in ASF with cache on that demonstrates stability of the access in long term. So I am not sure Atmel has tested-verified it properly.

 

Are you sure this is interference on RXD2 line? It could be processor bad activity on the pin, isn’t it???

 

Last Edited: Fri. Jan 20, 2017 - 11:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

Thank You for the reply!

 

I don't know currently what the exact cause of this failure. The support team got my modified USB Device CDC example, they must be checking it nowadays.

The bad news is that I need the cache. Without it my project won't work any well. Though, I need SDRAM and USB "mass usage" too so it doesnt really matter why I can't continue my project. I just can't.

 

Memory corruptions isn't because of some cache maintenence missing? Unfortunately I have fixed some of this kind of bugs in the examples when I was getting familiar to the microcontroller. Sometimes the compiler made mistake and some const arrays were shifted in the memory... You can never know. The best to aviod these is using assembly. wink I love assembly but this project is too complex to be written in asm.

Furthermore, AS7 sometimes shows weird data in Memory or Watch windows. I don't know why... it's random. But I have tried to use the scrambling function of the SDRAM controller (to have quasi random data line changes) and with it AS7 was showing even more weird data (at SDRAM) and I was unable to edit them so that other bytes won't change... Scrambling should be absolutely transparent, for the debug interface too.

 

Please tell if something new happens with your project.

Bests,
Zoltan

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

:) I am happy to know somebody works on the platform and peripherals I try to work too :).

ztobler wrote:
Memory corruptions isn't because of some cache maintenence missing?
 

 Sure no! I saw memory corruptions even in DMA-controlled NO_Cache region and the issue disappeared when we set using SRAM instead of S-D-RAM.

Just for platform test, could you try to turn off cache in you project? If it is working stable that way it is strongest reason to prove internal processor defect as it means the issue is located inside the chip while only cache setting affect the issue presence!

ztobler wrote:
… and some const arrays were shifted in the memory...
 

Did you check addresses in the *.map-file? compiler places any named entity description there. Just search the name in any text editor in the file.

 

ztobler wrote:
…Furthermore, AS7 sometimes shows weird data in Memory or Watch windows. I don't know why...
 

I suppose debug tools is not perfect for the chip-line yet. I believe it is completely debug tool chain issues it shows different(erroneous) data than there really are. I met the same in debug windows but other interfaces show correct data. And again, it is rather internal chip issue about debug (jtag) interface internal chip implementation!

ztobler wrote:
 Please tell if something new happens with your project.
 

Ok

Best regards,

Sergey

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

Hi!

 

Just for platform test, could you try to turn off cache in you project?

I don't remember exactly, but I think I have tried it. Don't even remember the result. cheeky I'll try it again, on both the boards (mine and the Xplained Ultra).

 

Did you check addresses in the *.map-file? compiler places any named entity description there. Just search the name in any text editor in the file.

From the start of the .lss file it was clear that all VMA and LMA address pairs were shifted with 4 bytes. I used SRAM compilation. This way the relocate segment was badly copied. I tried things to overcome it but nothing helped. Then, updating the AS7 (for some other reason) make it disappear. Though, I have tried using arm-eabi 5.2.1 earlier, but didn't solve it either.

Fortunately, it's not a case with the SAM chips. wink

 

Currently, my SDRAM issue is being inspected by the support team. I have sent a simply modified version of USB CDC example that shows the issue on the Xplained Ultra board. I am waiting for the result.

Until then, I am working on an other project, but I'll check the cache thing soon again.

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

Hi,

ztobler wrote:

 I'll try it again, on both the boards (mine and the Xplained Ultra).

I forgot to note it is important to have both D and I caches turned off if you try.

 

And we saw some improvements with debug functionality after AS7 updating too.

 

ztobler wrote:

Currently, my SDRAM issue is being inspected by the support team. I have sent a simply modified version of USB CDC example that shows the issue on the Xplained Ultra board. I am waiting for the result.

 

 

My colleagues are in contact with Atmel support too but I am afraid it is not priority task (we have got other platforms to try for our task) and the issue is not well defined as I can see. I will inform here if there is any result too.

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

Hi!

 

Now I am doing the tests. I use the Xplained board. It does the following: enumerates the Camera (on USB host) and starts reading frames into SDRAM (DMA).

 

The results:

1) Compiled in debug mode, no optimization applied to the code (regardless if I use cache or not):

  • Works with clock settings (HCK, MCK): 75/75, 150/75, 150/150, 246/123
  • Fails: 300/150 (a fault is done and handled)

2,a) The same but I do write to the SDRAM meanwhile (very much, toggling data bits), cache is turned on:

  • All "low clock" settings make the USB fail as "normally"
  • 300/150 does the same, plus if the SDRAM writes come some later than the first frame has begun to be transmitted, the CPU does a fault.

2,b) The same without cache:

  • ALL settings do the USB fail but NO CPU FAULT even at 300/150!

 

The failure is something weird... while the pixels are coming to SDRAM, the CPU/SRAM seems to do something wrong, it calls a function with invalid address ("never execute" region) or a usage/hardfault executing some other 'data'... It looks like the CPU/registers are messed up inside...

 

So, turning off the cache eliminates the CPU fault at the fastest speed but the USB thing remains. It's rather hard to understand why it is not eliminated when I do not write to the SDRAM additionally...

 

Summarized: smiley

There are two type of "faults" here:

  • "USB", when the USB host losts communication with the device. (This is the main fault we are searching a clue for.)
  • "CPU" fault, when the CPU looks like working wrong and some kind of CPU fault will be thrown.

The compilation/hardware configurations are:

  • clock speeds: fast ("300/150" MHz) and "slow"
  • using cache (I+D) "+" or not "-"
  • with ("+") or without ("-") writing additionally to the SDRAM (while the camera is streaming data to the SDRAM)

 

The result table:

clock speed cache usage SDRAM writes faults:
300/150 - - CPU
slow - - -
300/150 +

-

CPU
slow + - -
300/150 - + USB
slow - + USB
300/150 + + USB or CPU
slow + + USB

 

Well, that's enough for now. I'm gonna share this with the support team as well.

 

Have a nice day!

Last Edited: Sun. Feb 5, 2017 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have done a really great job! I believe we saw the same results though we were not able to structure them (as we have more complicated interface composition: the same USB+SDRAM and Ethernet in addition).

 

Looking for Atmel responce with anticipation :) !

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

I suspect the same, maybe we are facing the same trouble (cause) but different exact issues.

The support case is still open and "hanging". My demo example for Xultra board is sent in for over a month now but still no feedback if it's working or not. Two things can happen: 1, there is a huge problem about the SAM series and they are figuring out what to do; 2, my contact is too slow. cheeky I would need a result now, the project would be not only a hobby one. Though, I had time to work on another project that may partly "replace" this one but the invested work into the suspended one may go to /dev/null.

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

Our Atmel contact admitted problem with SDRAM on SAM-V71. So we are going to use SAM-E70. I saw there is problem with USB on E70 but we don't need USB in our project(if only for debug and it works for sometime).

To work with SDRAM on E70 we fixed the defines:

#define   SDRAMC_CR_CAS_LATENCY<num> (0x<<num-1>>u << 5) /**< \brief (SDRAMC_CR) 1 cycle CAS latency */

to

#define   SDRAMC_CR_CAS_LATENCY<num> (0x<<num only!!!>>u << 5) /**< \brief (SDRAMC_CR) 1 cycle CAS latency */

It seems it is stable now. (we are still testing!).

And there is a lot of work to do for SW-concept-protocols-development and debug so we have time to wait.

Last Edited: Fri. Feb 17, 2017 - 06:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rather weird things happen recently about this issue.

Today I've made tests with the EBI data pins, disconnecting each from the SDRAMC peripheral, so less pins are driven, less coupling to the other signals/powers. The result is interesting. The data lines that affect the "CPU fault" are located next to or close to the VDDOUT and VDDIN power pins. So I made a simple (not the best) external 1.25V supply and disconnected the board from the VDDOUT pin. The CPU fault disappeared and the USB issue stayed.

 

So I thought that the power pins may be the solutions. (As at the very beginning but have found nothing.) I started playing with stronger HF filters, bigger capacitors at the VDDUTMIC power pin (that may affect the USB) but nothing changed. Meanwhile I've found a way to do the CPU fault again...! indecision I've disconnected the !SDWE pin, no CPU fault occurs if the pin is driven low or high constantly. But I've made a mistake for first and set another PIO's registers and I only disabled the peripheral driving of the pin, but haven't set it to be an output. As an input, it must be coupled with many surrounding lines and it must be toggling continuously. This leaded to the same CPU fault...

 

I'm totally lost on these power and line coupling issues. And the USB is still unusable.

 

The support team said that the modified example that fails at my board works stable at them. So what now. I own an unstable demo board and a more stable but still bad own one. What's the next step...? This takes up too much time and nothing is better. No solution, not even a good tip.

Meanwhile I am working with an AVR to test some pre-prototype things. At least they work well. But I would need this damn massive SDRAM-usage later with a strong CPU. May separated power supplies for SDRAM and MCU solve the issues? (My last idea.) I could hack my board (for the Nth time yet) like this but can't do it on the Xplained Ultra. Ahh....

 

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

It is not clear, what does it mean: "disconnecting each from the SDRAMC peripheral"?

Did you exclude SDRAM usage in your example SW if you disconected SDRAM pins? Have you tried to make it stable on 300/150-max-clock as you wrote it stable without SDRAM with low clock (looking your table)?

I don't think it is possible to fix the issue by configuring pin-environment (espatialy power-pins) of the chip. I think it is internal chip-issue. 

Ask Atmel to give you that stable board that they tested with your example.

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

I meant that I configure the !SDWE pin (PD29, for example) as output, driven by the PIO registers, not one of the available peripherals (A to D). Meanwhile, the SDRAM controller is configured and working, so it drives all the other pins.

 

Of course I did not disconnect any power pin. :) Except that I have to desolder the VDDOUT (internal regulator) pin to apply an external 1.25V for the core, utmi etc. This new power source made the CPU fault disappear...

 

...temporarily, since I've found some way to have it again, but this requires another "configuration"... Damn. So, the system stability depends on the 1.25V source, at least a bit. I am testing with this power supply now, rather interesting results I had.

 

One result is that I can not interpret at all: if I configure the SDCK pin as a PIO output to low, one should think that the SDRAM IC will not function (store, give data) but the SDRAM controller inside the MCU will. It DOES NOT!!! If the pin is an output 0, all the data pins (D0..D15) are not driven as well. What...??? How the SDRAM controller depends on the pin's configuration? It's a simple multiplexing at the PIO whether the peripheral or the PIO registers set the data/direction of it. And of course as the data pins are not toggling, the system is stable and no errors occur. If I let the SDCK pin driven by the SDRAM controller, the USB fault is present, the communication through CDC dies.

 

The tests about these pins (all of the SDRAM controllers) was to discover any correlation between the driven lines on the PCB and the fault(s). And there is! The less data/address lines are toggling on the PCB (and between the chip die and the case's pin), the less probably that the USB communication will fail. Doing these tests I have faced the above "issue"... that is nonsense.

 

It's way too annoying now, why a factory PCB (or MCU) doesn't work any stable. Showing many issues I have to figure out myself. Even my own PCB is a lot more stable, that's why the USB failure was totally hidden until I started to use the SDRAM very hard. (This was the goal, to have a MCU that can handle such hard processings.) crying

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

Has Atmel perceived the result? Is Atmel intersting about the condition when the chip fails? Have you received any concernment from Atmel?

While you are reserching the equipment I search why there is two chip's series SAME70 and SAMV71 that seems to be equivalent to each other.

Only difference I found is that V71 is “Automotive Qualified” while E70 is not (from “Product Selector: Microcontrollers (MCUs)” – Atmel site).

Device Name

Automotive Qualified

ATSAME70Q21

 

ATSAMV71Q21

Yes

 

So I wonder why they need two series with the same characteristics. The series seems to be differ in producing tecnology only!

Does it mean there is something wrong with the initial series?

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

Atmel has received my results, the description of the used system, everything. I've made a modified USB CDC example to show them the faults. It works at their test setup but on mine. That's all they could discover until now.

I suspect a very strong problem about the chip. It's an early one (the V71), marked as -ES3 (must be engineering sample). But at least if I knew that the board is "faulty" and they could replace it or just ensure that is has problems and I should use newer chip versions.

 

In my project a S70 type MCU is used. This shows the same USB faults with less probability but no CPU faults at all. That IC is not marked really identifiable, I don't know what series it may be. The only thing I know about it is that it may be a very early one. I've ordered it when it was not yet available at the distributor (Mouser). I don't need Ethernet and such function that the V71/E70 has.

A real solution were if Atmel would tell me to use a new chip (or E70 for example) because it is fixed and seems stable by all the users. (No such faults observed.) The only reason why I can wait some more for the solution is that there is many new things to develop before I would need the "ARM with SDRAM" unit again. :) I am doing those controlled with AVR. I love AVRs. And I would love SAM series too, for today I've got quite familiar with them. CM7 core is very effective and it's fun to write speed optimized assembly routines on it. ;)

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

Now, things happened. smiley They can reproduce the CPU fault at their test setup with the modified example project. It's just the same as at me. Finding of the fault's root cause has begun.

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

Hi,

 

I've discovered what appears to be the same or a related issue.

 

I simply run the ASF-provided SDRAM test program: "SDRAM Example for Micron IS42S16100E." It simply writes data to the SDRAM and then reads it back again. The data is corrupted in random locations when it is read, so the "benchmark" test fails. This occurs on two separate SAMV71 Xplained Ultra boards that I have tried (They both have the SAMV71Q21 chip with the -ES3 chip designation). The provided test app appears to assume there is 10MB of SDRAM, which is wrong. The error still occurs when I reduce the assumed SDRAM capacity to 2MB.

 

Have you heard any news or status on this issue?

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

Hi!

I have good news, the issue has just been solved. :) Thanks for a smart user, 'mvolstad'!

I don't know if this root cause can make the SDRAM to fail 'by itself' but I can't exclude it. Our issue was about the USB communication failure, when the SDRAM is being used strong (written by toggling data bits at high frequency). I had no SDRAM data corruption while I was struggling with the USB issue for over 3 months now.

The cause is the improper MAINCK clock in the system. If the MCU's crystal oscillator is used (12MHz), tha MAINCK and all the clocks that uses this as the reference clock (UPLL, PLLA) gets 'corrupted'. The 12MHz MAINCK is good until the SDRAM is being utilized strong. Then it has very high jitters and makes the UPLL to have even higher period/freq. changes. This leads to USB sync error and it can even cause the CPU to fail if it runs on a high frequency (250-300 MHz from PLLA).
mvolstad tried to use an external reference clock of 12MHz for the MCU and all the issues has gone. Yesterday I made an external oscillator too and tried it on the SAM V71 Xplained Ultra board. All the issues has disapperared! No CPU and USB faults in any of the system configurations... laugh

It seems that all the MCUs in the family (S70, V71 at least for sure) has this kind of weakness. They need a stable external clock and they work very fine.

Bests,

Zoltan

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

Hi,

And I have just found interesting issue on our SAME70 based board with 32Mbytes SDRAM.

It failed on repeated SDRAM access too.

I adopted ASF-example to the board.

And It works on 300/150MHz!

There is define:

#define CONFIG_PLL0_MUL             25

in conf_clock.h file

I changed it to 50! It sets PLL output frequency so it is going to be 600MHz for 50-value defined there.

Though it is out of allowed range: Section 30.2 ”Clock Generator Embedded Characteristics” of SAME70 description pdf:

PLLACK is the output of the divider and 160 to 500 MHz programmable PLL (PLLA)

It works on at least two boards!!!

And it looks like I have found the difference that fixes the issue with SDRAM access.

 

There is prescaler in Master Clock Controller in Power Management Controller (PMC – section 31 of the pdf) that is controlled by a field in PMC_MCKR-register. It has value 1 that means

“Selected clock divided by 2” or means the prescaler is used in the successful project. In our previous projects it is zeroed that I suppose means the prescaler is bypassed, I changed it to 1 with the same change to PLL-mul=50 and it seems all issues with SDRAM access have disappeared!!! (though I still can’t believe it yet by myself it needs weeks of testing not just one day :)

 

The only explanation I can provide is that the prescaler serves as buffer that prevents clock signal consumer to affect PLL-unit stability or something like that.

 

So there are the questions to Atmel:

  1. what could be outcome of PLL output signal (PLLACK) is out of the range? If there is any when it works.
  2. Could my guess about the prescaler role be true? Or Why does use of zeroed prescaler (or not divided PLL clock) can lead to faults?

 

Regards,

Sergey

Last Edited: Fri. May 5, 2017 - 01:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I guess Your issue with the SDRAM is just the same. The SDRAM and its access needs short high currents and the crystal oscillator on the chip seems to be very sensitive to these changes. (I guess that board uses the integrated crystal oscillator (12MHz) too.)

As the PLL uses a voltage controlled oscillator, it must react on reference clock signal jitters differently if it works on a different frequency (300 or 600 MHz). I would try to use an external oscillator in a final product even if it seems to work stable. Unfortunately this issue about the crystal oscillator seems to include S70, E70, V71 and maybe others too. I was told that Microchip/Atmel will release an errata about this after they have inspected this root cause.

I have also noticed that the 600MHz is more than the datasheet allows, though some configuration in the Xplained Ultra software package 1.5 uses it. I think it works but may not for every piece of these MCUs. (They may saturate on a bit lower frequency.)

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

Hi!

Our board uses the external crystal oscillator (12MHz and 12 x 50 = 600MHz or 12x25=300MHz PLL).

I agree there must be common root cause for the issues. I think there is harmful feedback loop or just a link on power lines inside the chip and it mainly affects clock system (related with what you write about high currents consumption).

For 600MHz it isn't even warmer so I think it will work as PLL-unit provides it (there can be only two options: yes and no) and chip core works on allowed 300MHz.

regards,

Sergey

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

Hi,

 

Looks like we are on the same boat, and our "solutions" or findings are the same too. 

On my board there are 64MB SDRAM, and it works quite stable with 150MHz CPU and 150MHz MCK with 300MHz PLL freq.

When I try to use it with 300Mhz CPU and 150MHz MCK clock with 300MHz PLL I got stability issues,

but with 600MHz PLL it works nicely with 300/150MHz over a few days running memtests and other parallel test. 

 

I slowly pulled my hairs one-by-one, becouse I though I got same software issues under linux, but this is clearly hw related:

http://www.at91.com/discussions/...

 

There is a note in the datasheet 56.13, the worst case conditions are 250/125MHz, so it would be good to get some official? notes about what can be the root of this issue.

 

Regards,

Andras

Last Edited: Thu. Jun 1, 2017 - 07:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

The PLLs may be a little bit more vulnerable than they should be, as they are a part of the clock system. Just like the internal crystal oscillator circuit that is proven to be a bit weak.

 

I would advise to route the PLL clock diveded to an IO pin for both the 300 and 600 MHz PLL settings and monitor it with an oscilloscope using a min-max (envelope) mode. If the peak-to-peak jitter at 300 Mhz was considerably higher this would explain this behaviour. It's enough to have the SDCK to be a bit faster for only one clock period to have issues.

 

Such measures has proven my issues with the USB (PLL). I've attached my screenshots from the UPLL divided by 16 signal when the system was idle (CPU was doing NOPs in infinite loop) and when I was using (writing) the SDRAM quite hard. Similar but lower differences may be osberved for the PLLA clock for 300 and 600 MHz clock speeds.

 

Bests,

Zoltan

 

Edit: sorry, these are frqencies UPLL divided by 8. wink Though it doesn't really matter.

Attachment(s): 

Last Edited: Sat. Jun 3, 2017 - 12:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Yes it would be interesting to get pictures, but unfortunately I have not got appropriate equipment now.

 

regards,

Serge

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

Hello!

 

I have this same problem with a E70 Q21. If I enable SDRAM everything goes pear-shaped. I see where I can change the CONFIG_PLL0_MUL to 50, but what is the command to change the register? I tried REG_PMC_MCKR |= PMC_MCKR_PRES_CLK_2 to set the prescaler on the master clock to DIV 2... and as I was just typing that out, I realized I was multiplying it by 2 and not dividing it. So... that explained why it froze attempting to run at 1200Mhz...

 

That said, I'm not at all confident that changing it that way will work (actually going to try DIV 2 this time.) If I'm on the wrong track, please let me know.

 

Thanks!

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

Yes, that doesn't seem to work. I've tried pmc_mck_set_division(2); but that doesn't seem to do anything for the processor clock? I thought the processor clock was derived from the master clock at 1 times division. I've set the processor clock to /2 but the SDRAM issues remain. Anything obvious I'm missing?