Progression from XPLAINED board to production

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Afternoon all,

 

I've recently received my ATSAME70 Xplained board, and am about to start developing, with the intention of incorporating the ATSAME70Q21 MCU into my embedded device design. I've not played with discrete MCUs before, and am somewhat lost when it comes to production programming and debugging. I've read through the datasheets for the Xplained board and the ATSAME70 series MCU, and am relatively comfortable with the embedded programmer/debugger in use on the Xplained board. My questions are as follows:

 

  1. If I use Atmel Studio to develop with the Xplained board, can I simply implement the exact same embedded debugger and micro USB design in my custom board and continue to use Atmel Studio to flash the ATSAME70Q21?
  2. If the answer to 1 is 'no', what is the standard/recommended programming approach for a low volume production? I don't need multi-site programming support, and would be happy to program the MCU either off- or on-board.

 

Any guidance here would be greatly appreciated. The need to resolve this isn't urgent as I haven't yet begun development, but I'm working on my board schematics at the same time, so any pertinent design considerations regarding the MCU need to be accounted for in the shorter term.

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
can I simply implement the exact same embedded debugger and micro USB design in my custom board

No - the EDBG is not available as an end-user part.

 

It would not make sense to that, anyhow.

 

For development, what you would do is to have some means of connecting a separate debugger/programmer to your board; eg, Atmel-ICE, Segger J-Link.

 

ARM specify a standard header for Cortex-M debug: http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf

 

Something like a TagConnect saves a connector on the board: https://www.avrfreaks.net/commen...

 

For production, you would probably not fit the connector, and just use "pogo pins" in the same "bed of nails" used for testing.

 

You should discuss this with your board house.

 

Alternatively, chips can be preprogrammed; eg https://www.microchipdirect.com/programming/

 

 

EDIT

 

Read the chapter, 'Schematic Checklist' in the datasheet - it has a section on the debug/programming connection.

 

IF you are seriously going into commercial production with this, you should certainly be getting some proper "Design For Manufacture" (DFM) advice ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jun 19, 2018 - 07:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

jars121 wrote:
can I simply implement the exact same embedded debugger and micro USB design in my custom board

No - the EDBG is not available as an end-user part.

 

It would not make sense to that, anyhow.

 

For development, what you would do is to have some means of connecting a separate debugger/programmer to your board; eg, Atmel-ICE, Segger J-Link.

 

ARM specify a standard header for Cortex-M debug: http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf

 

Something like a TagConnect saves a connector on the board: https://www.avrfreaks.net/commen...

 

For production, you would probably not fit the connector, and just use "pogo pins" in the same "bed of nails" used for testing.

 

You should discuss this with your board house.

 

Alternatively, chips can be preprogrammed; eg https://www.microchipdirect.com/programming/

 

 

EDIT

 

Read the chapter, 'Schematic Checklist' in the datasheet - it has a section on the debug/programming connection.

 

IF you are seriously going into commercial production with this, you should certainly be getting some proper "Design For Manufacture" (DFM) advice ...

 

Thank you for your considered and helpful post awneil, it is greatly appreciated. Since posting this morning I have discovered and investigated the Atmel ICE, which seems to offer the functionality I'm after. There's a good amount of information available, both written by Atmel, and presented by third parties (guides, YouTube videos, etc.), so I should be able to get that working when the time comes.

 

As for your last comment, I plan on engaging with a design house/consultancy prior to production to review and mark up my design. I prefer to learn and implement myself in the first instance if at all possible :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's no need to quote the entire post verbatim - just enough to give context.

 

Or just use the 'Reply' button, and the forum automatically identifies the post you're replying to:

 

 

 

jars121 wrote:
I plan on engaging with a design house/consultancy prior to production to review and mark up my design.

DFM isn't something you can just bolt on at the end!

 

The trouble with this approach is, you then end up with a whole load of stuff that needs to be re-worked - which could have been avoided with some timely advice earlier in the project.

 

This is what design houses call a "rescue" project ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jun 19, 2018 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
DFM isn't something you can just bolt on at the end!   The trouble with this approach is, you then end up with a whole load of stuff that needs to be re-worked - which could have been avoided with some timely advice earlier in the project.   This is what design houses call a "rescue" project ...

 

I understand, and in an ideal world I would do just that. Unfortunately self-funded projects are subject to considerable compromise, and I can't justify the not insignificant expense at this stage. It's certainly on the agenda for the near future though :)