BSP for Microchip ATSAMA5D27-SOM1-EK1

dufault at hda.com dufault at hda.com
Mon Nov 26 17:37:10 UTC 2018


It will be some work to update.  I believe what’s in the existing port is from this:
atmel-software-package-samv7:  Legacy software package for samv7, same70 and sams70 product families.
while the newest software that supports the ATSAMA5 is here, with a different directory layout.
atmel-software-package: Atmel Software Package

> On Nov 25, 2018, at 14:45 , Christian Mauderer <list at c-mauderer.de> wrote:
> 
> Hello Peter,
> 
> 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.
> 
> If you still want to use the ATSAM chip: Microchip managed to get a
> better community around the libraries that are used in the BSP for that
> chip. There is a newer version of them somewhere on github. If there is
> funding for it, I would suggest to update the ones that are integrated
> in the ATSAM BSP by the newer ones. They contain quite some bug fixes.
> But it will need some work to do that.
> 
> With kind regards
> 
> Christian Mauderer
> 
> Am 25.11.18 um 19:42 schrieb dufault at hda.com:
>> Thank you for the advice.  I will not need USB, but will need SDRAM and
>> don’t need poor support.  Microchip? You tried to push RTEMS for this
>> platform tied to space applications, are you monitoring this?  The
>> platform looks like just what I need but not if you’re not supporting it.
>> 
>>> On Nov 25, 2018, at 13:23 , Thomas Dörfler
>>> <thomas.doerfler at embedded-brains.de
>>> <mailto:thomas.doerfler at embedded-brains.de>> wrote:
>>> 
>>> Peter,
>>> 
>>> just to make you aware: we designed a board with the ATSAMV7 chip and
>>> hit some nasty and at least one really ugly bug: operating the USB
>>> interface concurrently with external SDRAM does not work. Half a year
>>> after reporting this bug, Microchip confirmed it, but did not plan any
>>> fix for it. BTW: The conbination (USB+SDRAM) was also available on
>>> Microchip's evaluation board, but obviously was not tested together at
>>> Microchips labs...
>>> 
>>> So: I recommend you to tripple check, whether the ATSAMA5 meets all of
>>> your expectations.
>>> 
>>> 
>>> Kind regards,
>>> 
>>> Thomas.
>>> 
>>> ----- Ursprüngliche Mail -----
>>> Von: "Peter Dufault" <dufault at hda.com <mailto:dufault at hda.com>>
>>> An: "Development" <devel at rtems.org <mailto:devel at rtems.org>>
>>> Gesendet: Sonntag, 25. November 2018 18:38:19
>>> Betreff: BSP for Microchip ATSAMA5D27-SOM1-EK1
>>> 
>>> I need to evaluate this for a multi-chip application.
>>> 
>>> This part is a result of Microchip’s take-over of ATMEL.  I’m
>>> double-checking that to create a BSP based on this I should start with
>>> the existing ATSAMV7 BSP, I think the peripherals (e.g. network chip
>>> and so on) are the same as the existing ATSAMV7 port.
>>> 
>>> 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 at rtems.org <mailto:devel at rtems.org>
>>> http://lists.rtems.org/mailman/listinfo/devel
>>> -- 
>>> -- 
>>> --------------------------------------------
>>> embedded brains GmbH
>>> Thomas Doerfler
>>> Dornierstr. 4
>>> D-82178 Puchheim
>>> Germany
>>> email: Thomas.Doerfler at embedded-brains.de
>>> Phone: +49-89-18 94 741-12
>>> Fax:   +49-89-18 94 741-09
>>> PGP: Public key available on request.
>>> 
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> 
>> 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>> 
> 

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/20181126/4234c5c8/attachment-0002.html>


More information about the devel mailing list