BSP for Microchip ATSAMA5D27-SOM1-EK1

[dufault at hda.com]

> On Nov 25, 2018, at 14:45 , Christian Mauderer <list at 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?  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:
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.
 
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. 

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191004/ffbf56f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: confused_smile.png
Type: image/png
Size: 1101 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191004/ffbf56f3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wink_smile.png
Type: image/png
Size: 1114 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191004/ffbf56f3/attachment-0001.png>