Small-footprint Due

Hi Guys -

Need your expert feedback on the Due board we are designing.

We wanted to build a smallest possible footprint Due-compatible board for embedding into our products (such as our Open Source EV Charging stations, EV chargers, etc - some info for the curious ones: http://www.emotorwerks.com/products/online-store/product/show/44-emw-juicebox-level-2-15kw-ev-charging-station-kit-or-assembled-unit).

We have sifted through all the posts I could find on various relevant topics to try to collect all gotchas (e.g., errors in Schematics, suboptimal I2C pullup resistor values). We have also looked for various types of user feedback to help us design a board that can not only be useful for us but also could be interesting for others making small production runs based on SAM3X8E. E.g. we have added a 64Kbit EEPROM on board, broken out AREF pin, etc.

At this moment, we were able to get a 4-layer layout containing LQFP-144 package to fit into a 1.2"x1.4" footprint. It would have an external programming board with Due programming circuit on it. This way small production runs are way more economical as you don't have to spend all that $$ and board space on programmer circuits you don't use in production.

See the screenshot below for some details. The picture is admittedly a bit messy with all layers visible - SAM chip is mounted on top of board, all other components - on the bottom. 68 .1" pins on perimeter. Main design objective was the smallest footprint while maximizing the number of peripheral types broken out. The trade-off is a smaller number of broken-out Digital I/O pins. You will also notice there are no reset / erase buttons. Again, we do not expect those to be useful in production environment. And they would take a huge amount of space + cost of electromech components is non-trivial.

In addition to general feedback, would be cool to hear your opinion on some open questions we still have:

  • What should we do with VBUS / UOTGVBOF / VBG lines? We are NOT breaking out Native USB at this point so none of the USB hardware would actually be used but I am wondering what we need to keep from the original Due schematics so the system still works. E.g., should we provide VCC to VBUS input? Should we still have an RC network on VBG pin? Etc.

  • Should we try to break out native USB? The reason it's not on right now is that a micro-AB slot would take 20% of our board space and in fact would make the board at least 40% larger. Soon enough the space benefit from having this MicroDue board is diminished. So unless one can see extremely high utility for native USB, we would keep it out. IMO given that there is going to be a separate programmer board, native USB is ONLY useful for USB HOST mode. I am just not sure what % of target users this will be important for. Maybe I am missing some uses other than USB HOST?

  • Are there any other gotchas we should be aware of?

Thoughts? Would you want something like this? :wink:

Thanks,
Valery.

This is interesting.
How much do you think it will cost you every fully assembled board?

Any chance of a schematic, it's hard to tell much from the PCB, for example why do you have 5v pins?


Rob

If you can include the neglected slave select pin NPCS3 (LFBGA pin A2) for SPI, then it would be possible to use the external decoder support to allow up to 15 peripherals. That one wire could expand SPI peripherals to 4 (or 15 with decoder). It looks like the Arduino software already supports this pin, but its left unconnected on the Due board.

Nice mini-board - I was (am) considering something similar - a mini core board with LFBGA that breaks out all pins.

Thanks guys. Will post schematics shortly.

This IS based on 144 lqfp. Very hard to deal with bga without using very expensive pcb process.

5v is there to allow plug into boards with 5v supply.

Good idea on adding usb pins. Would you want the associated circuitry on this board or leave out for the shield?

Same on the 4th spi Cs pin.

Cost wise I expect $13 all in. Assuming good volume of course

Good idea on adding usb pins. Would you want the associated circuitry on this board or leave out for the shield?

Depending on space. The most important point would be, to have the pins available. If there is space left on the board for the circuitry, the shield would be very easy. Without pins however, the functions are not accessible.
Better leave the circuitry off, if that gives you space for other pins.

Cost wise I expect $13 all in. Assuming good volume of course

I assume, that this should be no problem with a good crowdfunding campaign.

thx. added a row of pins to break this out. circuitry on board so you just need to connect the pins to VUSB, D+, D-, ID, UGND. I wonder if there are some creative ways to simplify addition of the connector to these...

Used some extra space to add 4 additional digital pins and better layout for AREF reference.

gogol:

  • make VDBU available

what is VDBU pin? It's not in SAM's datasheet...

Sorry, I missed a "D": VDDBU ...

gogol:
Sorry, I missed a "D": VDDBU ...

got it. but why would this need to be broken out? why not leave it permanently tied to +3.3V supply?

What might need to be broken out is RTC crystal pads, right? I mean, if we go to the trouble of breaking out NRST, we should make RTC fully functional, right?

valerun:
got it. but why would this need to be broken out? why not leave it permanently tied to +3.3V supply?

Figure 5-3 in the Atmel-Dokumentation shows the purpose, when you wish to connect the backup-batterie like a small coin package. That may need some kind of solder-pad, where the connection to +3.3V can be cutted/solder-closed as needed.

valerun:
What might need to be broken out is RTC crystal pads, right? I mean, if we go to the trouble of breaking out NRST, we should make RTC fully functional, right?

Right with that, but the second advantage is, that the NRST is bidirectional, so that external components can be reset through it.
If you connect the external components to NRST they are reset, whenever the reset-controller resets the chip, even when caused by software! That means, that you need no code, which uses GPIO-pins to reset your peripherals.

gogol:

valerun:
got it. but why would this need to be broken out? why not leave it permanently tied to +3.3V supply?

Figure 5-3 in the Atmel-Dokumentation shows the purpose, when you wish to connect the backup-batterie like a small coin package. That may need some kind of solder-pad, where the connection to +3.3V can be cutted/solder-closed as needed.

Thanks. I read through that section but can't understand if there is going to be any residual consumption on rest of VDD pins if the chip is put into a backup mode... If the consumption is zero on all other pins (chip is down, after all), then one could just keep the battery connected to all supply pins at all times. This does assume that the user would move the chip to backup mode once loss of 3.3v external power is detected (perhaps using one of the digital pins to sense that). But this does sound like a kludge. Will try to break this one out, as well. Running out of space, though :wink:

The SAM has a SHDN pin that is supposed to be used to shut down external regulators, that may imply that this should be done to get the best low power operation, but I think it's just to kill external circuitry, the CPU itself has this well handled.

One would assume as you say that the current used on the VDD pins is next to nothing, in fact if you look at Fig 46-4 they have all the VDD pins shorted to GND for testing the VDDBU current, so it's fair to say there is nothing but some leakage current on those pins under a normal shutdown situation.


Rob

ok got the USB pins out (R5, R6 39R resistors fitted on board but varistors don't fit so a shield would have to implement those).

Also got the VDDBU out (bridged to +3.3v - would need to be cut if this feature is used).

Finally, was able to fit in 32khz crystal and caps - at the expense of one digital pin breakout :wink: I just would hate to have sensitive crystal circuitry broken out via huge 0.1" pins...

All this cost ~8% increase in board size. On the plus side, that allowed adding one more analog and a few digital pins

Will post new board and schematics shortly

...got to stop adding pins...

added one more row on the 109-144 side of the chip which allowed a few additional digital pins but more importantly placing a 3.3v CAN tranceiver to be able to use an excellent CAN-DUE library by collins80 and a few others. These tranceivers run in our EV chargers and work like a charm. So now we have a fully plug-and-play CAN channel on board.

1.4"x1.4" board with 91 pins in 2 rows along the perimeter. The original idea was to have ~40 pins... lol

Sample chips arrived from ATMEL today.

Any other suggestions before we order the first ~10 boards for testing?

V

That really sounds like a boost-board for the DUE-family. A fraction of the size of the original, with an estimated price, where you have not to think about letting the board in a project.

yes, that's the idea.

someone mentioned something about breaking out EBI data bus... What do you guys think about that? Better be very critical as I REALLY don't want to add a third row of pins

just checked - full EBI bus is ~50 pins. so perhaps sometime in the future...

Will you consider breaking out the Ethernet?