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 dufa...@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.doerf...@embedded-brains.de >> <mailto:thomas.doerf...@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" <dufa...@hda.com <mailto:dufa...@hda.com>> >> An: "Development" <devel@rtems.org <mailto:devel@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@rtems.org <mailto:devel@rtems.org> >> http://lists.rtems.org/mailman/listinfo/devel >> -- >> -- >> -------------------------------------------- >> embedded brains GmbH >> Thomas Doerfler >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: thomas.doerf...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
