On 04/10/2019 14:17, dufa...@hda.com wrote: > > >> On Nov 25, 2018, at 14:45 , Christian Mauderer <l...@c-mauderer.de >> <mailto:l...@c-mauderer.de>> wrote: >> >> Thomas mentioned already the bug that has been reported to Microchip. >> Please note that I had two more problems with the BSP on another >> customers board: >> >> - The core clock couldn't be set to the maximum frequency from the data >> sheet. Both possible configurations for that frequency didn't work. The >> first one would have set the PLL to the same frequency as the CPU core >> clock. With that the system was not stable. The other setting (a divider >> of two after the PLL) seemed to work better but that forced me to set >> the PLL to a higher frequency than the data sheet specified. I ended up >> with the lower frequency. >> >> - The external SDRAM seemed to introduce some jitter into the core PLL >> too (not only in the USB PLL which was the reason for the USB bug). With >> higher frequency configurations the system sometimes had an odd >> behaviour: A comparison went wrong when it should go well. Again that >> lead to a slightly lower frequency that seemed stable. So the board now >> runs on only about two thirds of the maximum frequency specified by >> Microchip. >> > > Following up on this old thread. I found this this morning > (https://community.atmel.com/forum/weird-issue-interference-between-usb-host-and-independent-core-instruction): > > Hi folks again, if anyone faced this or a similar issue! > > Currently my project has been waken up and is in the prototyping phase. > Since, many things happened. > 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: > > 15.2 USB and SDRAM Concurrent Access Issue > > USB module functionality is adversely affected with concurrent SDRAM access. > > Workaround > Ensure that no concurrent module operations when using both SDRAM and USB. > > It seems to be quite bad news, eh? frown Fortunately I think this 'bug > report' is made from the cases we have opened (me and another guy, may
For the E70 and V71 our bug report had a similar effect. It needed about half an year and then the entry appeared in the Errata. > be more). Quite many weeks of troubleshooting and mainly thanks to the > another guy's idea and equipments we've solved the issue: > 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. That's great news. I'm quite sure we tried some external oscillators back then too without luck. Might I ask which types (drive strength, ppm, ...) you used so I can remember them for my next odd problem with this chip? > > 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). > 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. > > 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.) > But people may try using external clock and benefit from the MCU's > power. wink > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > > This email is delivered through the public internet using protocols > subject to interception and tampering. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
