BSP for Microchip ATSAMA5D27-SOM1-EK1

Mon Nov 26 19:09:57 UTC 2018

Hello Peter,

yes, that sounds about right. I'm not entirely sure about the name of
the file we used as a base back then. I would have to take a look at the
exact version at work.

I think the new software should be based on the "legacy" one so I would
expect that the interface is at least similar. But yes, it will be some
work to use the updated libraries. Especially because there are some
RTEMS-patches in the legacy libraries to work around some bugs.

Best regards

Christian

Am 26.11.18 um 18:37 schrieb dufault at hda.com:
> 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
>> <mailto: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 <mailto: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>
>>>> <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>
>>>> <mailto:dufault at hda.com>>
>>>> An: "Development" <devel at rtems.org <mailto: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> <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 <mailto: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.
> 