<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><br class=""><blockquote type="cite" class="">On Nov 25, 2018, at 14:45 , Christian Mauderer <<a href="mailto:list@c-mauderer.de" class="">list@c-mauderer.de</a>> wrote:<br class=""><br class="">Thomas mentioned already the bug that has been reported to Microchip.<br class="">Please note that I had two more problems with the BSP on another<br class="">customers board:<br class=""><br class="">- The core clock couldn't be set to the maximum frequency from the data<br class="">sheet. Both possible configurations for that frequency didn't work. The<br class="">first one would have set the PLL to the same frequency as the CPU core<br class="">clock. With that the system was not stable. The other setting (a divider<br class="">of two after the PLL) seemed to work better but that forced me to set<br class="">the PLL to a higher frequency than the data sheet specified. I ended up<br class="">with the lower frequency.<br class=""><br class="">- The external SDRAM seemed to introduce some jitter into the core PLL<br class="">too (not only in the USB PLL which was the reason for the USB bug). With<br class="">higher frequency configurations the system sometimes had an odd<br class="">behaviour: A comparison went wrong when it should go well. Again that<br class="">lead to a slightly lower frequency that seemed stable. So the board now<br class="">runs on only about two thirds of the maximum frequency specified by<br class="">Microchip.<br class=""><br class=""></blockquote><div class=""><br class=""></div>Following up on this old thread. I found this this morning (<a href="https://community.atmel.com/forum/weird-issue-interference-between-usb-host-and-independent-core-instruction" class="">https://community.atmel.com/forum/weird-issue-interference-between-usb-host-and-independent-core-instruction</a>):<div class=""><br class=""><div class="">Hi folks again, if anyone faced this or a similar issue!<br class=""> <br class="">Currently my project has been waken up and is in the prototyping phase. Since, many things happened.<br class="">For example I have noticed that there is a new errata (I've been waiting for a long) for the SAM S70 devices. The below is from this errata:<br class=""> <br class="">15.2 USB and SDRAM Concurrent Access Issue<br class=""> <br class="">USB module functionality is adversely affected with concurrent SDRAM access.<br class=""> <br class="">Workaround<br class="">Ensure that no concurrent module operations when using both SDRAM and USB.<br class=""> <br class="">It seems to be quite bad news, eh? <img alt="frown" title="frown" style="border: 0px; max-width: 100%;" apple-inline="yes" id="6A7C399B-BCDC-404F-A208-B721E5E10C12" src="cid:CC71F1CE-24C2-4A0F-AFA4-9099067A9982@RTEC.NET" class=""> Fortunately I think this 'bug report' is made from the cases we have opened (me and another guy, may be more). Quite many weeks of troubleshooting and mainly thanks to the another guy's idea and equipments we've solved the issue:<br class="">it's not the "concurrent access" but the crystal oscillator's weakness. As soon as I used external 12/16MHz clocks instead of using the embedded crystal oscillator, every issue has disappeared (+another one involving SDRAM usage and the CPU core) and all of my project are working without any faults for months now (at maximum speed (300/150MHz))! This was the case for the V71 Xplained Pro board as well. External clock solved the issues there too.<br class=""> <br class="">So I don't really know what is the exact cause why Microchip(/Atmel) tells that people shouldn't use SDRAM and USB actively at the same time. For example this is the power of the microcontroller, I am also benefiting from.. USB streams camera frames (~220Mbps) into SDRAM and it's processed realtime with another correction frames in SDRAM into the result area (SDRAM as well). It's quite hard usage of this two peripherals. And abolsutely no errors with external clock! (2 circuits and the Xplained Pro).<br class="">We have also closed the cases with Atmel with this conclusion (the oscillator was 'weak' and PLLs were doing quite bad clocks for the CPU/USBHS) so I'm a bit surprised on this errata entry.<br class=""> <br class="">I don't say that this issue written in errata does not exist. (If someone uses the embedded xtal oscillator, it will exist, I can confirm.)<br class="">But people may try using external clock and benefit from the MCU's power. <img alt="wink" title="wink" style="border: 0px; max-width: 100%;" apple-inline="yes" id="A665E88A-E4AC-4F6F-99C4-30F9DA6397DF" src="cid:1D07C729-F4F7-469B-8A9B-C955A26FB531@RTEC.NET" class=""><br class=""><br class=""><div class="">Peter<br class="">-----------------<br class="">Peter Dufault<br class="">HD Associates, Inc. Software and System Engineering<br class=""><br class="">This email is delivered through the public internet using protocols subject to interception and tampering.<br class=""></div><br class=""></div></div></body></html>