Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM

View table of contents ...  

image

 

{tabbedtable} Tab LabelTab Content
About

From Maxim Integrated, the Darwin microcontroller  is an ultra-low-power, highly-integrated microcontroller designed for battery-powered devices and wireless sensors. It combines a flexible and versatile power management unit with the powerful Arm® Cortex®-M4 with floating point unit (FPU). It enables designs with complex sensor processing without compromising battery life.

image

 

It also offers legacy designs an easy and cost optimal upgrade path from 8- or 16-bit micro controllers.The device integrates up to 256KB of flash memory and 96KB of RAM to accommodate application and sensor code. It supports SPI, UART and I2C communication in a tiny form factor: 1.6mm x 1.6mm 16-bump WLP or 4mm x 4mm 20-pin TQFN-EP, or 3mm x 3mm 24-pin TQFN-EP.

image

The MAX32660 evaluation system offers a compact development platform that provides access to all the features of the MAX32660 in a tiny, easy to use board. A MAX32625PICO-based debug adapter comes attached to the main board. It can be snapped free when programming is complete. The debug module supports an optional 10-pin Arm® Cortex® debug connector for DAPLink functionality. Combined measurements are 0.65in x 2.2in, while the main board alone measures 0.65in x 0.95in. External connections terminate in a dual-row header footprint compatible with both thru-hole and SMT applications. This board provides a powerful processing subsystem in a very small space that can be easily integrated into a variety of applications.

 

Additional Information

MAX32660 User Guide

MAX32660 Evaluation System

Important Dates

Enrollment Begin: Nov 1 1018

Enrollment Ends:Nov 19 2018

RoadTesters Selected: Dec 3 2018

Product Shipped: Dec 4 2018

RoadTesting Begins: Dec 11 2018

Reminder/Update Email: Jan 11 2019*

Submit Reviews By: Feb 11 2019*

*The element14 RoadTest Staff will send this reminder/update email.

**If a RoadTester is unable to meet the deadline, please notify the RoadTest Program Lead, , as soon as possible before the deadline

RoadTesters

Terms and Conditions

RoadTest

Terms and Conditions

These are the terms and conditions which govern the Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM RoadTest contest. This Contest requires participants to submit an application indicating their previous experience with this type of equipment/component, information on what they would do to test the equipment/component, and the applicant’s desire to post a thorough review of their experience with images, photos, or other supplemental materials. Participants will be required to meet the Conditions for Participation.  The winners of this RoadTest will receive the item(s) listed below. RoadTest Reviews are due no later than 60 days after the receipt of the item(s). No other prizes are offered.

The Principal terms of the Competition:

The following words and phrases are used in these terms and conditions and have the meanings given to them below.

Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM

(RoadTest or Contest)

Key dates:

Applications Close: midnight (GMT) on  Nov 19 2018

Announcement of Winner (estimated): Nov Nov 20 2018

Prize: Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM

Additional Prizes: none

Competition Site: https://www.element14.com/community/groups/roadtest?ICID=menubar_resources_roadtest

Site or element14 Community: www.element14.com/community

Judges: members of the element14 community team chosen at the Organiser’s discretion.

Judging Criteria, All of the following which will have equal weighting:

· Demonstrated competence with the technologies including links or descriptions of past projects

· Qualifications as indicated by current job role and/or schooling/vocational training;

· A thorough description of how the prize would be tested;

· Likelihood that the Applicant will blog about the prize and provide a review on element14.com;

· Originality;

· Innovation.

Organiser: Premier Farnell plc (registered in England and Wales under company number 876412) whose registered office is at Farnell House, Forge Lane, Leeds, UK

Conditions for Qualification: in addition to meeting the requirements of these terms, all persons applying to take part in the Contest (each one an Applicant) must:

· Provide a RoadTest application describing what he/she would do if awarded the Prize including similar previous projects, product experience and qualifications

Terms: these terms and conditions which govern the Competition and to which the Organiser reserves the right to make changes from time to time and the latest version of these Terms from time to time will be posted to the Site.

  1. Eligibility
  2. Applications:
  3. Selecting Winners:
  4. Liability:
  5. General:

1.1 Save as set out in these Terms, the Contest is open to any natural or legal person, firm or company or group of natural persons or unincorporated body.

1.2 All Applicants must be aged at least 18 at the time of their application.

1.3 Applicants must not enter the RoadTest if doing so or taking part may:

1.3.1 cause the Organiser and/or themselves to be in breach of any agreement (including but not limited to any contract of employment) to which they are a party or in breach of any law, regulation or rule having the force of law to which the Organiser or the Applicant may be subject or any policy of the Organiser or the Sponsor;

1.3.2 Require the Organiser to obtain any licence, authorisation or permission to deal with the Applicant; or

1.3.3 Be in breach of any policy or practice of their employer. Some employers prohibit or restrict their employees from taking part in competitions such as these or receiving prizes under them and the Organiser respects those policies and practices.

The Organiser reserves the right to disqualify any Application made in breach of these Terms and to reject any Application which it reasonably believes may be or become in breach. The Organiser reserves the right to require evidence in such form as the Organiser may reasonably require of any Applicant’s compliance with any of these Terms and to disqualify any Applicant or Participant who cannot provide such evidence reasonably promptly.

1.4 Multiple applications are not permitted.

1.5 Applications may not be submitted by an agent whether acting on behalf of an undisclosed principal or otherwise.

1.6 The Contest is NOT open to:

1.6.1 Any person or entity who is a resident or national of any country which is subject to sanctions, embargoes or national trade restrictions of the United States of America, the European Union or the United Kingdom;

1.6.2 Any employee, director, member, shareholder (as appropriate) or any of their direct families (parents, siblings, spouse, partner, children) (“Direct Families”) of the Organiser and Sponsors; or

2.1 Each Applicant must fully complete and submit a RoadTest Application by the Application Close.

2.2 By submitting a Registration Form, each Applicant:

2.2.1 Authorises the Organiser to use his or her personal data (as defined in the Data Protection Act 1998) for the purposes of running and promoting the RoadTest;

2.2.2 Authorises the Organizer to copy, reproduce and publish their application should they be accepted as a Participant;

2.2.3 Will be deemed to have read, accepted and agree to be bound by these Terms. Applicants are advised to print and keep safe these Terms;

2.2.4 Authorises the Organiser to copy, reproduce and use the Application and/or Review for the purposes of the RoadTest and as otherwise contemplated by these Terms. The Organiser will not be responsible for any inaccuracy, error or omission contained in any reproduction or use of the Project Blogs.

2.2.5 Licenses the Organiser to use the intellectual property in the Project (IP) for the purposes of this Contest. As between the Applicant and the Organiser the IP remains owned by the Applicant.

2.2.6 Grants the Organiser the right to use his or her likeness, photographs, logos, trademarks, audio or video recordings without restriction for the purposes of Contest or the promotion of it or the Site;

2.2.7 Agrees to participate positively in all publicity surrounding the Contest;

2.2.8 Agrees to be responsible for all expenses and costs incurred by him or her in preparing for, entering and participating in the Contest (save for any expenses expressly agreed by the Organiser to be borne by it in these Terms);

2.2.9 Confirms that he or she owns all IP used in his or her application or Project or Blogs and indemnifies the Organiser from any claim by a third party that use of any material provided by an Applicant to the Organiser infringes the intellectual property rights of any third party;

2.2.10 Agrees not to act in any way or fail to act in any way or be associated with any cause or group which would have a negative impact on the reputation of the Organiser and/or the RoadTest.

2.3 All applications submitted to this RoadTest must meet the following criteria:

2.3.1 Applicants must be the author, creator and owner of the proposed review idea. Applicants must not submit someone else’s idea;

2.3.2 The proposed application must be reasonably achievable by the within the time constraints of the Contest;

2.3.3 Applications must not include or propose any of the following, the inclusion of which shall render any proposed application ineligible:

(a) Applications which relate to socially taboo topics, such as illicit drug use or sexual gratification;

(b) Applications that are or could reasonably be considered to be illegal, immoral, discriminatory or offensive as determined by the Organiser;

(c) Applications in relation to them which if accepted would infringe or breach any of the policies or terms of access or use of the Site.

2.4 No Application may contain any of the hazardous substances identified by Article 4 of Directive 2002/95/EC of the European Parliament on the Restrictions on the Use of Substances in Electronic and Electrical Equipment ("the Directive") or the use of such hazardous substances in the in any such Project must not exceed the maximum concentration values set out in the Directive.

3.1 Winners will be selected by the Organiser on the basis of the quality of his or her application and its adherence to these Terms.

3.2 The total number of Winners selected will be at least the minimum number set out above but the actual number is at the sole discretion of the Organizer and/or the Sponsor, if applicable.

3.3 The Organiser will use all reasonable efforts to announce the Winners via an update to the RoadTest page by the date listed above.

3.4 Winners agree to take part in all publicity which the Organiser or the Sponsor wishes to use to promote the RoadTest, the Products featured or other Contests with which the Organiser may be connected from time to time.

3.5 Details of the Winners may also be published in the media.

3.6 Winners are responsible for all applicable taxes, duties or other charges payable in relation to any prize.

3.7

4.1 The Organiser hereby excludes all and any Liability arising out of the Contest or the acceptance, use, quality, condition, suitability or performance of any Prize, even where that Liability may arise from the Organiser’s negligence.

4.2 Nothing in these Terms will affect any Liability of the Organiser for death or personal injury arising from its negligence, for breach of Part II of the Consumer Protection Act 1987 (in the event that any entrant is entitled to claim rights under the Consumer Protection Act 1987) or for any matter in relation to which it would be illegal for the Organiser to exclude or to attempt to exclude its Liability.

4.3 Subject to 4.2, neither the Organiser, any parent company nor any subsidiary of the Organiser or such parent company or any of their directors, officers and employees (together referred to in these terms and the ‘Associates’) makes any guarantee, warranty or representation of any kind, express or implied, with respect to this Competition or the Prizes potentially available under it. Neither the Organiser nor any of its Associates shall be responsible for any Liability that may arise out of or in connection with person’s participation in this Competition, the claiming, redemption or value of any prizes under it, the use or enjoyment of such prizes or any events or circumstances arising out of or in connection with any of them. Any implied warranties of condition, merchantability or suitability or fitness for purpose of any of them are hereby expressly excluded. Wherever used in these Terms, ‘Liability’ shall mean any and all costs, expenses, claims, damages, actions, proceedings, demands, losses and other liabilities (including legal fees and costs on a full indemnity basis) arising directly or indirectly out of or in connection with the matter concerned.

5.1 The RoadTest is organised and sponsored by the Organiser. The Organiser reserves the right to delegate all or any of its powers, rights and obligations arising in relation to the RoadTest to any Associate and certain such rights and powers are assumed by the Organiser on behalf of itself and each Associate. Reference to “Organiser” shall be deemed to include reference to each Associate.

5.2 The RoadTest may be terminated at any time if there are, in the sole opinion of the Organiser, an insufficient number of entries, or if the Applications are not of an appropriate standard for a competition of this nature. The Organiser has the right to cancel or suspend the RoadTest at any time due to circumstances outside its reasonable control.

5.3 The Organiser shall have the sole discretion to disqualify (without correspondence or right of appeal) any Applicant it considers to be adversely affecting the process or the operation of the RoadTest or to be in breach of these Terms or to be acting in a disruptive manner or with intent to annoy, abuse, threaten or harass any other Applicant or Participant.

5.4 The Organiser has the right to amend or add to these Terms from time to time. Revised Terms and Conditions will be posted on the Contest Site and it is a condition of entry to the RoadTest that Applicants agree to comply with these Terms and, if appropriate, such Terms as amended from time to time.

5.5 Headings are for convenience only and do not affect the interpretation or construction of these Terms and Conditions.

5.6 These Terms and the operation of the Contest shall be governed by and construed in accordance with English Law and any claim or matter arising under these Terms shall be subject to the exclusive jurisdiction of the English courts.

RoadTest Reviews
Comments
Anonymous
  •   wrote:

     

    The contents of max32660_hdk.cfg are as follows:

     

    https://gist.github.com/Megabytte/4398302ff049d4e4b076739dcf00d38e

    New automatic update, new bug image. When starting Eclipse forMAXIM, it asked to update the MAX32660 modules.

    Building works. Debugging fails:

     

    Open On-Chip Debugger 0.10.0+dev-snapshot (2019-09-11-16:33)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    D:\Maxim\Toolchain/share/openocd/scripts/interface/MAX32660_hdk.cfg:15: Error: invalid command name "swd"
    in procedure 'script' 
    at file "embedded:startup.tcl", line 26
    at file "D:\Maxim\Toolchain/share/openocd/scripts/interface/MAX32660_hdk.cfg", line 15

     

    This time it doesn't seem to be the content of the .cfg file. openocd compains it doesn't know "swd"

    (this command was there since in preious CFG scripts too)

  • Thanks, Michael. Clear.

    It doesn't help me with my project though, where I need PWM with an open drain. Only works with timer0 when P0_3 is an output pin.

    I may get by using an interrupt and setting a GPIO to input and output based on a timer tick, but I feel dirty when doing that image

  • I think you need to set it for input with no pull (up or down).

     

    They don't quite say that but the clue for me is on page 58 of the user guide:

     

    • Input Mode Features

    − Standard CMOS or Schmitt Hysteresis

    − Input data from the input data register (GPIO0_IN) or to a peripheral (alternate function)

    − Input state selectable for floating (tri-state) or weak pull-up/pull-down

     

    That last line suggests that they see input floating as the same thing as tri-state.

     

    MK

  • Does anyone know how to put a GPIO pin in 3-state mode? Is that by setting it to Input?

    I've been searching the User Guide and the register settings. It mentions tri-state but I didn't find which register combination sets that.

  • Here we go.

    I added the flag --print-memory-usage to the linker:

     

    Memory region         Used Size  Region Size  %age Used

               FLASH:        5236 B       256 KB      2.00%

                SRAM:        1293 B        96 KB      1.32%

  • I'm still trying to understand the map file for GCC. I know the TI one, but this one I haven't found the code and data sizes yet.

    479560 is the byte size of the elf file.

     

    I have now set the optimizer to -Os, and removed the MXC_ASSERT_ENABLE define from the build. Brings the file size down with 20000 bytes.

    Let me check the MAP file once more ...

  • Hello Jan,

     

    Sorry, I don't understand the two part number, there can't be 0.560 bytes, 479k and a bit seems rather too much.

     

    479 bytes doesn't seem anything like enough .....

     

    Could you explain it a bit more (the Keil tools tell you separately how much code, const and ram is used).

     

    Thanks.

     

    MK

  •   wrote:

     

       wrote:

     

    Hello Jan and all other roadtesters.

     

    ...

    Another question I have, the Keil GPIO example is about 3.8k of code (it toggles 1 output pin and makes the other follow a button), even after removing the 'printf' calls it seems hugely bloated - if the same example exists for other tool sets how big is it ?

     

    MK

    With the MAXIM SDK, the GPIO example, built without debug info and printf commented out:

    479.560  bytes

    I'll have to double-check the settings for the release build, because when I look at the map file after building a release, I see debug artefacts, such as debug assertions and the likes ...

  •   wrote:

     

    Hello Jan and all other roadtesters.

     

    ...

    Another question I have, the Keil GPIO example is about 3.8k of code (it toggles 1 output pin and makes the other follow a button), even after removing the 'printf' calls it seems hugely bloated - if the same example exists for other tool sets how big is it ?

     

    MK

    With the MAXIM SDK, the GPIO example, built without debug info and printf commented out:

    479.560  bytes

  • I've created the review: Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM - Review .

    This was a great experience. Thank you to all that helped me.

  • I'm writing the road test review. Here's a preview of the size of the MAX32660.

    Spoiler Alert. This is one tiny baby.

     

    image

     

    Also a thank you to Maxim to send them to me as samples (in just a few days!). That helps me to complete the road test.

  •   wrote:

     

    Thanks for the story.

     

    The device is dead again - now for another reason.

    ....

    I got some good help from Maxim technical support on the ticket I created for this. image

  • Thanks.

     

    I'm done for now - until 29th at least.

     

    I've written a demo FPGA app. and the code to boot it from the MAX32660 (and some decent pin set/clr macros) - put it all together and of course it doesn't work.

    I need to make a little debug lead to access the comms between the uP and the FPGA (there is a debug connector) but I think it's time to go and make a Christmas chocolate cake !

     

    MK

  • I have not gone to the register level. I used the hal that comes with the SDK.

     

    It seems that the examples for Keil / iAR are the same ones as for the Eclipse flavour that comes with that SDK. I’ll try to create an example without the printf and without debug info to check the size. Maybe the map file gives some insight on what are the biggest contributers.

     

    The eclipse version of MAXIM has a custom register view that I haven’t used yet, but I hope it shows the registers you are talking about.

  • Hello Jan and all other roadtesters.

     

    As some of you may know I have designed my own board for the MAX32660 with an FPGA to keep it company. I've built a couple and hit a snag which maybe some of you may have more info about.

     

    The best data I can find on the chip is the User Manual (4.7Mbyte pdf) and it documents the GPIO registers like this:

     

    image

     

     

    But this is NOT what the chip is actually like !

    at 0x0018 there is certainly a GPIO output register with bits you can set and clear which will set and clear any enabled GPIO pins,

    but at 0x001c and 0x0020 there is a GPIO set register and a GPIO clear register so you can do a set or clear without needing to check the current state.

    The Maxim pin set and clear functions use these undocumented registers and the "system viewer" support for the Keil tools (from Maxim) has visibility of these registers and names them.

     

    Have any of you noticed this, found better documentation, got an explanation or whatever.

     

    And, while we are on the subject, the official Maxim pin set and clear functions are disgustingly slow - achieving  a pin toggle rate about 1/3 of the optimum.

     

    Right now I'm concentrating on testing my board so the next stage is to get the FPGA going (which needs code pushed into it by the MAX32660) and I have enough running to get on with that.

     

    Another question I have, the Keil GPIO example is about 3.8k of code (it toggles 1 output pin and makes the other follow a button), even after removing the 'printf' calls it seems hugely bloated - if the same example exists for other tool sets how big is it ?

     

    MK

  • I've ordered a new evaluation kit. I can order element14 products at my brick and mortar shop in Brussels.

    They order from element14 and it saves me from paying the delivery fee. I don't need to be at home for delivery and I support a local shop image

    By the time I'm back from holidays they should have it.

  • Have a good holiday.

     

    If demands of family (who do)  and customers (who don't) know it's Christmas allow, I might get my from-scratch boards built and have made a start with code when you get back.

     

    MK