Microchip SAML10/11 Xplained Pro Evaluation Kits - Review

Table of contents

RoadTest: Microchip SAML10/11 Xplained Pro Evaluation Kits

Author: BigG

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Not aware of any M23 devices, which offer both built in op amps and trustzone capability. This is the only development kit I am aware of that provides this unique current measurement capability. Otherwise the next closest rival is the STM32L552ZC (from ST Microelectronics) which is a more powerful and pricier M33 device with 2 built in op amps and trustzone etc.

What were the biggest problems encountered?: User Guide Documentation provided for examples found in Atmel START is quite poor (draft quality) and sprinkled with errors and omissions. For example, many lacked a clear description of expected outcomes when running the demo example and instruction steps limited to just 6, often stopping mid point.

Detailed Review:




1.0 Introduction


Firstly, I want to thank Microchip and Element14 for giving me the chance to review both the SAM L10 and SAM L11 Xplained Pro development kits.




Before I start my review, let me explain where my starting point is as this defined my road testing approach.


I am someone who has never used any of the Microchip Xplained Pro development kits or used Atmel Studio before. I have some previous experience using PIC micros and have briefly experimented with the lMPLAB IDE. I have plenty of experience using other competitor development kits and their associated IDE's.


So, for this review a key aim of mine was to evaluate the degree of effort it takes to get familiar with the SAM L10/L11 Development Kits and associated IDE, together with libraries and examples, and then, if time permitting, develop my own proof-of-concept (POC) prototype. To achieve this aim, within the allotted timescale, I followed a number of steps, namely:


  • Getting Started (or Quick Start) guide - does this facilitate or confuse the real getting started learning and application development process
  • Check what supporting materials, tools and resources are available to help facilitate and possibly accelerate the learning by doing process
  • Check that the hardware works as explained (this would be a cursory review as I'm not an Electronics engineer)
  • Follow through and review some of the examples provided
  • Finally, evaluate my attempt to create an enhancement of my own by building a new application and document the development process



2.0 Unboxing


I’m convinced that those within Microchip share my view that when it comes to ice cream there’s little value in trying to hide behind the sprinkles and the sauce, because the packaging used for the SAM L10 and SAM L11 development boards is minimal but functional and it does not include any fancy pamphlets or printed documentation (these days most purchases are done online which provide a good starting point for documentation).




The only criticism I have is that the labelling on the reverse side of the box could do with improving as it does not match the labelling used on static shielding bag and this does cause a moment’s hesitation. So, unless you are well versed on the product you may, like me, wonder what “DM320204” and “DM320205” on the boxes mean. I had to search online to discover that these refer to the part numbers for the development kits.



DM320204 is the part number for the SAM L10 Xplained Pro Evaluation Kit and DM320205 is the part number for the SAM L11 Xplained Pro Evaluation Kit, and not as per the picture below where I swapped products to make a point. The only linkage I could find between ESD bag labelling, the box labelling and the labelling on product version numbers (i.e. /03 for the SAM L10 board and /05 for the SAM L11 board). Whether this is intentional or otherwise I did notice that the SN numbering did not match either.





3.0 Getting Started


As there is no getting started information provided inside or on packaging, you are left to your own initiative and this is where many may take different learning paths to get to know the SAM L10/L10 boards.


Many may be like me and rely on search engines to guide you. This can be very fluid as things also change. For example, a month ago if I enter “SAM L10” or “SAM L11” in a search engine like the Google search engine, I was provided with a nice SAM L10/L11 landing page but if I entered "SAML10" or "SAML11" I received a different order of results where the landing page was no where to be seen on the first page. This has now changed for me.


However my other favourite search engine, DuckDuckGo, still displays this difference.




If we are smart enough and find the right link for the SAM L10/L11 landing page, we are presented with a great starting point.




On this landing page you are provided with a handy “Get Started” section:




Within this section, there are 4 tabs (Products, Development Kits, Documentation and Demo Examples).


All these have links to further information. Within the Documentation tab, there is the 41 page getting started guide (Application Note: AN2722).


The Demo Examples tab lists a range of examples but at the moment the links for those examples all point to the same Atmel START URL link (we’ll come back to Atmel START later in the review) rather than the supporting documentation. In my view this is circular, as once inside Atmel START and you click on the "USER MANUAL" button you are then often provided with another link to the relevant PDF documentation (which can be sometimes also found buried within a zip file containing the code).


Then looking below this tabbed section you will find three video demonstrations for the SAM L11 board. The first video is a 5 minute video titled “SAM L11 Trusted Execution Environment Demo” which can also be found on YouTube. The 2nd video covers the capacitance touch sensing(or Enhanced Peripheral Touch Controller), which is also available on YouTube. The 3rd video offers some user cases for the new TrustZone security feature. Note that the 3rd video is only available on the microchip YouTube channel in Chinese but can also be found on the microchip Vimeo channel. Note all 3 videos are available on Vimeo.


Now, for argument sake, say if you entered “DM320205” into a search engine, as this is what is provided on the packaging, rather than SAM L11, then you will be presented with a different set of search results which will include a link to the product page:




This page does not have a “Get Started” webpage section, although it does provide you with all the reference material and application notes etc. Within Documents and Software you will find a link to that key getting started application note (AN2722).


Then maybe some of you prefer to start things off by going directly to the microchip.com website, which by the way is very nicely designed, and searched for product information using their internal search engine you will be presented with a different set of results as well. Here I also noticed some subtle differences in the order in which information is presented to you. For example, if you entered “SAM L10”, in the microchip.com website’s site-search box you will be presented with a set of search results, which may lead to confusion getting started, versus, if you entered “SAML10” (without a space between SAM and L10). Using “SAM L10” as your search term will mean that you need to click on the “Application Notes” option to find this guide or use the “load more” button to find it. However, with “SAML10” as your search term, you would at least be provided with the “Getting Started” PDF (AN2722) link on the first page of search results.



3.1 Application Note AN2722 (Getting Started Guide)


This 41 page application note has 5 main sections, namely:


1. Device Documentation: here only a reference to the microchip website is provided. No reference is made to the DM320204/05 product numbers (it would be helpful if included here).


2. SAM L10/SAM L11 Xplained Pro Evaluation Kit: here the key board features are listed, as illustrated in the graphic below.




3. Development Tool Options: here web links are provided to both Atmel Studio 7 and Atmel START (the online IDE). It notes that Atmel Studio is the preferred IDE for developing and debugging firmware for SAM L10/SAM L11 (I’m assuming they are referring to other downloadable options, such as MPLAB X IDE, for example, which could also be used). It would have been handy if more links to training material is provided here, such as those video tutorials for Atmel START found via a YouTube Playlist.


4. Getting Started (with SAM L10) using Atmel Studio 7 and START: here a set of numbered instructions are provided on how to get started with your first example (LED Flasher) using the SAM L10.


5. Getting Started With SAM L11 Secure Solution Using Atmel Studio 7 and Start: here it starts with an overview on the security features (TrustZone). Then there are instructions on how to generate your first example using these security features.


The instructions given for two examples are pretty clear and I had no problem with running either demo. There were a few pauses though, which I've mentioned below.


The first main pause was section 5.1 (SAM L11 Security Concept Overview), as this still confuses me (even now as I reread it) rather than helps me.


It appears to be very much in draft format. My take is that the 2nd paragraph and only the 2nd paragraph is the crux of what Trustzone is all about. The rest of section 5.1 seems to be about single developer versus multiple developers which does not add much in terms of providing me with a concept overview (as a reader I don’t know much about this trustzone concept). Also Figure 5.1 is not very clear. I think what is trying to be explained is the ideal workflow when dealing with secure versus non-secure code modules. But what is not clear is why this is important from a concept overview perspective. So, for those like me who were still baffled, I found this article on the microchip website that provides a summary of what TrustZone is about, as well as info on the other security features available. Maybe this article should be referenced in this concept overview section.


Other than the concept overview issue, there were a few other very minor issues.


The first suggestion I would make is that the getting started instructions should, in my opinion, highlight the importance of first selecting your board in Atmel START, as once you select your board you will only be given the examples that are applicable to that board. This also narrows down the number of examples available for that board.




Then, a minor suggestion is to improve the wording used in the given demos (section 4 & 5). I note that the 1st SAM L10 example (section 4) you are provided with the following instruction (no problem here):



While in the 2nd example (section 5), the wording used is ever so slightly different, which led me to incorrectly search for “TrustZone Getting Started” in the search box rather than using the correct name “TZ-GetSmart-S”, thereby causing confusing as nothing relevant was shown - maybe make the text "TZ-GetSmart-S" bold to emphasise:



Then in the 2nd example, I was confused by Figure 5.10 in section 5.2.11, as I assumed this to be what you would see in Atmel Studio Solution Explorer view, which I could get as a "noob". As such, maybe the title should state “Compilation Resulting Secure Library File (using Windows File Explorer view)”, or something to that effect.




Then there was a minor error on the bottom of page 32. It should say File > SaveNonSecureProject rather than File > SaveSecureProject.


I was a little surprised that no getting started demo was provided for the capacitive sensing QTouch Button as this appears to be a new hardware feature for the Xplained Pro range (examples are there for capacitive sensing in the get started section of the SAM L10/L11 landing page but they require the QT3/AT7 extension).



3.2. SAM L10/L11 Xplained Pro User Guide


The other document, which I would presume many will be drawn to, when getting started, is the User Guide.


This 28 page document is a concise review of what you get with the SAM L10 and SAM L11 Xplained Pro evaluation kits.


I noted that this too has a getting started section (section 2), which explains what happens when you plug in your USB cable and power on the board. It would be useful, for sake of completeness, if this section made reference to the getting started application note (AN2722).


Section 3 is really useful as this provides you with good detail on what is contained on the Xplained Pro boards. This section is made up of 5 subsections.


In Section 3.1 you will find information on the Embedded Debugger (EDBG). The section on EDBG also provides a link to the EDBG user guide. Also Section 4.3 provides further details on Embedded Debugger implementation.


Section 3.2 covers the Xplained Pro Analog Module (XAM), where it explains that this module “extends the embedded debugger with high dynamic range current measurement, and this enables the power profiling of the target system”. A bit more detail on XAM is provided in Section 5.0 of the User’s Guide. It is a real pity no links are provided in this section for further information about XAM.


Section 3.3 indicates that each board contains a Microchip ATSHA204 Crypto Authentication™ chip for identification purposes and the information stored within the chip is sent to Atmel Studio when the board is connected.


Section 3.4 provides information on the different power source options.


Then Section 3.5 provides information about the Xplained Pro Headers and Connectors. More detail on the hardware connectors is also provided in Section 4 (Hardware Users Guide), including info about the mikroBUS Header and the X32 Header. It does seem odd to me that most of section 3.5 is repeated again in section 4. Maybe in a future revision of this document some cleaning will be done to remove the duplication.



4.0 Hardware Review


This is just a cursory review of some of the specific aspects of the hardware that were of interest to me. I also included some commentary about what is included on the silkscreen for GPIO pinouts, which I found to be lacking.


4.1 ATSAML10E16A / ATSAML11E16A Microcontrollers


For detailed design information about the SAM L10/L11, click here for the 1226 page datasheet, which is not found in the DM320204 or DM320205 product pages but in the ATSAML10E16A / ATSAML11E16A web-pages. Other than the enhanced security features found in the SAM L11 chip, the SAM L10 and SAM L11 microcontrollers are identical.



{gallery:autoplay=false} SAM L10 / SAM L11 Architecture + Schematics








4.2 Power Rail


As per the user guide:



Looking at the schematic, it reveals that there are two 3V3 LDO regulators on the board. One (TLV70033DSE) is to power the EDBG and CM (Current Measurement) controllers, which provides 200mA, and the other (TPS73533DRV) powers the MCU and peripherals, which provides 500mA.


4.3 Embedded Debugger (EDBG) Controller


The Embedded Debugger (EDBG) is used to program and debug the SAM L10/L11 using Serial Wire Debug (SWD). You connect to the EDBG through USB and comes three interfaces, i.e. debugger, virtual com port, and a data gateway interface (DGI). Each interface uses a different communication protocol. More is explained in the User Guide.


The EDBG controller is found on the reverse side of the board.





The schematic has this listed as an AT32UC3A4256S MCU.





4.4 Current Measurement (XAM) Controller


A really handy feature of the SAM L10/L11 Xplained Pro boards is that you can now set your current measurement for either the MCU or for GPIO's or both.





The new current measurement controller is handled by an ATSAMD20 chip, which is found on the reverse side of the board:


{gallery:autoplay=false} XAM Current Measurement Controller





4.5 Silkscreen for GPIO's (Extension Headers)


I felt that the silksceen for the GPIO pinouts was seriously lacking and could readily be improved. There is plenty of space on the front side of the board (as demonstrated) for the Xplained pro extension header pinout guide to be included rather than having it on the reverse side. Then with the mikroBUS the same pinout reference is used for front and back, rather than including the actual pin references. Finally nowhere does it show which GPIO's are for the X32 Header pins (it just assumes a person would know). Also the QT BTN 1 seems to be forgotten about as, in my opinion, it would be considered good practice to include the pin reference, which I believe is PA06. Similarly for LED0 (PA07?).


{gallery:autoplay=false} Silkscreen







5.0 IDE and Demo Example Review


The recommended IDE for the SAM L10/L11 family is Atmel Studio 7, although other options are available. Having never used Atmel Studio prior to this road test, I found it quite intuitive and had a similar workflow structure (i.e. build or compile a project then choose whether to debug or simply flash the board) to the other desktop based IDE's.


I thought the best way to capture my observations was through video. This video summarises my discoveries so far using Atmel START to choose an example for a board.



I once heard it being said that the enjoyment of a dish served at a nice restaurant starts with the quality of the ingredients and then the cooking, but that your impression and/or expectation of that dish will often be determined by what you read on the menu. So for this review, I thought to document my observations of two examples as they highlighted some of the minor issues uncovered.


5.1 The QTouch Example (Touch Sensing)



Atmel START lists a number of QTouch examples. For some reason, the ones listed above say that they are only applicable to the SAM L10 board which is incorrect as it equally applies to the SAM L11 board too. Then if you selected the SAM L11 board the only examples given for QTouch relate to Trustzone only.


If you then click on the User Guide button for the QTouch example highlighted you are presented just with an unformatted text description, as shown:




One hopes that this write-up is simply a DRAFT that will be updated soon, as the information given under "RELATED DOCUMENTS" is not sufficient at all.


Then looking at the "RUNNING THE DEMO" instructions, only the last 2 steps refer to what you can expect from the demo:


5. After 5 seconds, the touch button will be scanned every 64msec instead of 20msec.

6. You can use Data visualizer - power debugging option to view the current consumption of the MCU.


If we then select this example we are presented with this dashboard.




On the bottom left of the dashboard screen there is an tab available to configure the QTouch sensing option, but no documentation was provided in the user guide as to how to configure so I assumed you would leave as default:



Before we follow the instructions given in steps 3 and 4, and Build the project and then "Run without Debug", lets look at the code as it reveals something that is not documented. That is, if touch is detected then LED0 is switched on. For me, this would be one of the expected outcomes of this project example.




However, when running the demo, LED0 does not switch on, which has me perplexed. So maybe this was simply an example simply to show a timing event being triggered. If that is the case then this example is a little disappointing, in my opinion. Anyhow, I've captured running this example on video.




5.2 The ADC Gain Amplifier Example (OpAmp)


The ADC Gain Amplifier example provided in Atmel START, similarly says that it is only applicable for the SAML10 board, while the User Guide provides a reference to a PDF document which applies to both SAM L10 and SAM L11:


{gallery:autoplay=false} ADC Gain Amplifier example




This time there are only 3 steps provided in the Atmel Start User Guide to running the demo, of which the first two refer to download and importing the program which do no apply to Atmel START. The 3rd step simply says that we should build and flash the board. That is it. No further instruction given, even though the description given indicates that there will be a print out provided via the serial port and to refer to the application note for further details.


Even though the related PDF document goes into much more detail, especially on the op amp config side, it does not really help either, as it does not provide linkage with the Atmel Start Configuration dashboard settings. For example, the PDF provides detail on ADC configuration which is really difficult to relate to the ADC driver settings done in Atmel Start (maybe it is my lack of familiarity but, in my opinion, example documentation should generally be easy to understand). Hopefully this diagram illustrates the point:




The output from this example though, is as it says on the tin. Here I tested the Op Amp output using an analog moisture sensor attached to the designated analog pin (PA05):


{gallery:autoplay=false} Op Amp Example Output




The for pure curiosity sake I ran the data visualiser to see what the IO current measurement looked like when touching the moisture sensor. I can see many hours spent looking at all the options.




5.3 SAM L11 TrustZone Examples


I have not written up anything here, as I found that the examples work as per instruction and as I have no method of validating or stress testing these examples I am not in a position make comment.


What I have seen looks rather impressive and I think the key to getting value out of this feature will be determined by the architecture of your application rather than just the code.



6.0 My own project attempt


Unfortunately, I ran out of time. However I did manage to attach my own 2.9" ePaper display shield and modify the Low Power Weather example to display my own splash screen. The intention I had was to further modify this example to read temperature and humidity data from an I2C based temperature and humidity sensor and take moisture reading from an analog based moisture sensor. For the sake of simplicity I was intending to use the same pinouts as per the Weather example.


One thing I do like is the mikroBUS header connectors as these are breaboard/stripboard friendly, so it will be very straightforward to create your own mikroBUS type interface board.




Based on what I have achieved so far I am quite confident that developing a new project on these development boards will be relatively straightforward and without headache or heartache.



7.0 Conclusions


My original goal was to determine if this is a market winner as a mid priced standalone MCU and I believe it is. As to whether TrustZone technology puts constraints on the M23 controller, compared to which are removed by using an M33 is hard to say at this stage. Time will tell.


I really like the sleep walking feature. This is really well suited to sensors which can trigger an interrupt when certain thresholds have been reached. For example, a TSL2561 Digital Luminosity/Lux/Light sensor has such a feature. According to the datasheet it has about 0.5mA in active mode and less than 15 uA in powerdown mode. So combine this with a SAM L10 and you have a great opportunity to create something ultra low power.


Offering my opinion on pros and cons for these boards is too subjective, in my opinion, so I have left it out as it is up to the reader to make up their own minds. Despite the weaknesses discovered with the dev kit recipes (i.e. demo example documentation), I could quickly determine the quality of the ingredients that make up the L10 and L11 Xplained Pro devlopment boards. Based on my experience so far, I will certainly continue to work with these via Atmel Studio 7.

  • Thanks for the comment. I did not download MPLAB X for the road test, as I used Atmel Studio 7.0, so I don't know the answer. Sorry I couldn't of any further help.

  • Great detail on the evaluation. Nice job.

    One thing that puzzles me, as you pointed out: I’m assuming they are referring to other downloadable options, such as MPLAB X IDE, for example, which could also be used

    If I choose to use MPLABX, will the EDGB selection work? Are there any examples?

  • Hi


    Of course, just because you are using an M23 it doesn't mean you have to use its security features - if you made everything "trusted" it would still work.


    Yes, you make a very valid point. You could indeed make everything "trusted" and TBH I never investigated that option. My presumption, as a non-computer scientist, would be that if all code and memory was under "trustzone" there would be some sort of computational penalty associated with additional encryption validation. But I would need think this through.


    You are correct that there is a "cost" in using TrustZone: it makes the software development considerably more complex. You need to plan what features are secure and non-secure, and how information and control flows between secure and non-secure regions. Chained interrupts can require a lot of care! These are the sort of issues that newcomers find particularly challenging.


    Yes indeed, you've explained it perfectly. It is the complexity of the software development process that makes it difficult to optimise the code.


    My thinking is that with TrustZone you are more likely to be constrained by the amount of dynamic memory resource available during runtime due to the trust zone segmentation. Hence my comment about resource constraints. I don't know enough to have worked out how the dynamic memory process works, so I could well be wrong here.


    However most developers would find it much more relevant to read how someone had implemented security features on a "real" project, such as this RoadTest. That is what I was hoping to see.


    That was not really my goal for this road test.


    For me, my approach is more holistic as I try to look at all the resources provided to enable someone to grasp from scratch and then develop something meaningful with a new piece of hardware, by going through and documenting the learning process myself.


    Too often in the past I've come unstuck when buying a new product for a project and more often than not, due to tight project deadlines, I found it is much easier to simply switch to a different product than persevering (and wasting time) with what you have - this is especially the case for Proof of Concept projects where you simply want to demonstrate an outcome rather than a perfect system. Hence my approach is born out of this early stage development experience.


    My own personal view, is that TrustZone is very much application specific. So, for example, I was thinking that if I used TrustZone for an NFC-based application, for example, to store sensitive information then this transaction-type application would probably be quite different in how memory is used compared to say a Bluetooth Low Energy example, where there the connection, the connection validation handling and then the ongoing application data transfer would be more dynamic. Another example, could've been a security PIR which transmitted encrypted alarm messages rather than simple High or Low signal triggers, but was not sure what this would really demonstrate for a road-test compared to the existing examples.


    Anyhow the only thing these examples would highlight, in my opinion, is as you say - they would simply illustrate the additional complexities for the firmware development process and in my case it would really just highlight my own idiosyncrasies when it comes to proof of concept software development. I would doubt I would be able to demonstrate a decent enough blueprint for others to work off. Hence, I still feel that the ready made examples provide ample explanation of using this feature.

  • Security of embedded systems is a hot topic and becoming increasingly important as more devices become connected. The idea behind TrustZone in the v8-M architecture is to separate code into "secure" and "non-secure" regions at a hardware level, like an extension of the memory protection unit (MPU) in some existing MCUs. Placing code that interfaces to the outside (untrusted) world in the non-secure region ensures that a would be attacker cannot use it to gain access to critical (trusted) code in the secure region. This does not involve "using up valuable resource on the M23 MCU" - it is managed by the Security Attribution Unit (SAU) or Implementation Defined Attribution Unit (IDAU) that is provided on the chip.


    You are correct that there is a "cost" in using TrustZone: it makes the software development considerably more complex. You need to plan what features are secure and non-secure, and how information and control flows between secure and non-secure regions. Chained interrupts can require a lot of care! These are the sort of issues that newcomers find particularly challenging. There is plenty of information about TrustZone on the web and Microchip have written several application notes explaining how to use the SAM L11 security features. However most developers would find it much more relevant to read how someone had implemented security features on a "real" project, such as this RoadTest. That is what I was hoping to see.


    Of course, just because you are using an M23 it doesn't mean you have to use its security features - if you made everything "trusted" it would still work. That would be similar to the current situation where many embedded systems based around a Cortex M4 with a built-in MCU, do not take advantage of any of its MPU features. And people wonder why things get hacked?

  • Thanks for the comment.


    I'm not sure what you mean by "add something more about the TrustZone features".


    From what I gathered TrustZone is basically secure memory allocation within the CPU that is obfuscated so that no one outside can see what is there inside that memory allocation. There is plenty of information on the web about it. E.g. https://developer.arm.com/ip-products/security-ip/trustzone and https://genode.org/documentation/articles/trustzone


    As I noted in my review, I found that the examples given, were pretty good at demonstrating the principles behind using TrustZone.


    I also noted that in my opinion using TrustZone comes at a cost (i.e. you using up valuable resource on the M23 MCU) and as such optimisation will be important to get best use out of this feature. My hypothesis, which I had noted, was that as the M23 had the lowest capability and resource compared other CPU's offering trustzone, like the M33 for example, then there is a higher likelihood that you will hit some constraint.


    Unfortunately, my skill set is limited and it would take me a good while to figure out how to stress test all this (in my view security and memory testing is very specialised - there are generic reviews of trustzone security testing found on the web: https://www.arm.com/products/silicon-ip-security  and https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html ). Nevertheless, it would be near impossible for me to determine if any weakness I found could be directed at the SAML11 itself. Only real-world usage over an extended period of time will determine this (IMHO).


    So, if you had a specific use-case maybe then I could look at it and try and make comment.

  • A good review of the board and IDE for beginners. It would be great if you can add something more about the TrustZone features, which after all, is one of the main reasons why someone might select this MCU.

  • Very nice roadtest review.  These boards seem to be very capable, with plenty of features.  It will be interesting to see how these boards function as you push them a little harder and proceed further on your projects.


    Well done!