BSP for Microchip ATSAMA5D27-SOM1-EK1

[Christian Mauderer]

On 04/10/2019 14:17, dufault at hda.com wrote:
> 
> 
>> On Nov 25, 2018, at 14:45 , Christian Mauderer <list at c-mauderer.de
>> <mailto: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? 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.
>