My little ARM board

Hi
I have been thinking of designing a controller board myself for a while now and have recently started drafting up a schematic. Since I am not very good at programming I was hoping to stay in the comfort of 8bit but have given up on xmega that I hoped to be embraced by the devs. Now when Arduino due is here I thougt that if I choose a MCU in the ATSAM3 family maybe I could manage porting to a smaller chip.
What I want to do is make a simple bare minimum controller board that focuses on robustness and reliability rather than flexibility and lot of functionality. With help from Ambrop7, the developer of APrinter firmware, who also have offered to help me with software, I decided to make a board with ATSAM3SxA. The chip is available with 64k, 128k and 256k flash.

I am starting out with making a developement board with just the MCU, voltage regulator, USB and the pins fanned out on sockets to evaluate the chip and decide on functional pinout. The board is 50X50mm in size to fit prototype PCB service outline. Step 2 is to make a plug-in board with the driver circuitry.

The component values in the present version of the schematic should be considered under investigation but I thought I can present it here anyway to see if I can get som feedback and suggestions.

Any input is welcome

Edited 1 time(s). Last edit at 03/21/2014 05:49AM by Mallgan.O.

Will only make one suggestion:

Make sure that the USB connector shield is NOT connected to ground by default. Provide a jumper for this purpose (if people want it), but don't make it hard wired.

A lot of these development boards (Arduino, ARM boards, etc) have the USB shield and USB ground tied together. If you use the USB for power, this is fine but as soon as you add another mains PSU to run things (such as heating elements, stepper motors, etc), you can get all sorts of problems caused by ground loops - especially if both sides have an AC earth connection and for whatever reason they disagree on the DC offset between AC earth and DC ground.

This leads to current flowing through the shield of the USB cable, which can lead to all sorts of problems. Disconnecting the shield on the dev board allows you to mitigate this in a simple way. It also allows you to test (with a multimeter) if there is a voltage difference before you decide to connect the jumper.

This ground loop thing is right, but ignoring the shield doesn't help, you get the loops through the data lines anyways. In fact, I found connecting the housing to GND to be neccessary even in my low EMF environment.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

The schematic details are hard to see because of resolution, but i think i see some caps (100nF/10nF?) on every I/O pin? I think it drastically limits the use of such pins, by changing the pin capacitance. If you want to drive a fet with that pin, or generate a step signal, that cap would change the waveform perhaps not in a good manner. Also i cant see the diodes type, i assume zenner (or transil?) but which type exactly? I assume are meant to add 5v tolerance, but usually have to check the Vbr which depending on parts it could be like 10-20% confidence, and it may get lower than vdd, so have to check that out, and maybe leakages. I am saying because i think all those change the pins input properties and sometimes its good to have a pin with low capacitance, or without increased leakages. Just saying.

NoobMan:
Actually I aim for 12V tolerance as I hope 12V will be enough for my purposes. I agree you have to be careful with diodes and that is why I removed any part info in the schematic as I want to measure and verify the part first. They are intended to clamp at VDD and be sized to handle the current if you source 12V at the connector.
I realise that the pictures are to small to be of much use. I´ll fix that. The schematic shows what is intended to be a first step developement board to play around with MCU and hopefully avoid most pitfalls before it is time to proceed with a fully functional controller board. You could consider the pin protection components as placeholders for series and/or parallell components to be determined when they are assigned their function later on. The default configuration I consider will be 1k series resistance and 3V3 zeners wich I think is pretty good protection to start with and remove them when neccesary. The capacitors will be omitted on signals who needs it but I try to always limit the bandwith of signals just enough to fulfill its intended use. I will probably have to use gate drivers for FET switching as this MCU have to weak drive to start with even without any limiting components.

Cefiar:
Can you elaborate or point to a thread where this problem has been investigated? I am curious to see under what circumstances these problem shows up and if it is absolutely determined that it is a ground loop problem and not interference that causes this behavior. Many, if not most, dev boards are also missing filtering that is commonly used in commercial products to pass EMC compliance tests. I want to try making this board as reliable as I can and that is why it is going to be limited in functionality so I can put more effort in verifying and testing, hopefully. I am aware it is not a trivial task to make a board with an MCU working at its limits, communicating over USB while switching the currents involved here on the same board so I hope I am not percieved as critical, I just want to try to understand and learn.

Traumfug:
Can you elaborate too please? This USB reliability issues is one of the main reasons I am doing this. It is very frustrating for me trying to learn and set up my first printer when the communication with the host keeps crapping out on me.

Quote
Traumflug
This ground loop thing is right, but ignoring the shield doesn't help, you get the loops through the data lines anyways. In fact, I found connecting the housing to GND to be neccessary even in my low EMF environment.

Depends on where the link is.

On some PC's, there is no link between AC earth and DC ground, and the PSU expects them never to be in contact. If the USB shield gets connected to AC earth on the PC side (instead of DC ground), then the dev board actually provides the short between DC ground and AC earth. As long as all parts of this setup (which includes the PC) are not going to cause an issue, then it's all ok.

The problem with PC supplies (and those generic brick PSU's a lot of people use to power printers) is that they are NOT all the same, and there is absolutely no spec for whether a DC offset between the DC ground and AC earth can exist or not. Especially since people have a penchant for saving every last penny/cent on things, the chances of issues like this being present is higher.

Quote
Mallgan.O
Cefiar:
Can you elaborate or point to a thread where this problem has been investigated? I am curious to see under what circumstances these problem shows up and if it is absolutely determined that it is a ground loop problem and not interference that causes this behavior. Many, if not most, dev boards are also missing filtering that is commonly used in commercial products to pass EMC compliance tests. I want to try making this board as reliable as I can and that is why it is going to be limited in functionality so I can put more effort in verifying and testing, hopefully. I am aware it is not a trivial task to make a board with an MCU working at its limits, communicating over USB while switching the currents involved here on the same board so I hope I am not percieved as critical, I just want to try to understand and learn.

It's not so much interference. In this case, it results in possibly high current flow (the USB cable gets warm or hot to the touch) and damage could happen to either the PC's USB port, the dev board, the cable or any combination of them.

We discussed this issue with RAMPS-FD a bit, because one user had issues where the extra current draw through certain tracks (on an old revision) was actually affecting the DC ground bias for the thermistors (the ground value in the voltage divider wasn't ground any more, and this shifted the thermistor readings). As a result we beefed up the thickness of the ground track in this area (that was a fault in the design), but there shouldn't be any current flowing through the USB shield IMO. Originally we thought it was due to the hot end/heated bed current draw, but it turned out disconnecting the USB cable removed the ground loop. The Arduino Due (and the Mega) has the USB shield and DC ground connected (with no way to disconnect it).

Note: I'm not saying leave it disconnected permanently. Just make it separate and put a physical jumper there (or a cuttable track). This provides a place to:
1. Isolate the USB shield from the rest of the DC ground circuit.
2. Measure any voltage difference between USB shield and DC ground.

Quote
Mallgan.O
Can you elaborate too please? This USB reliability issues is one of the main reasons I am doing this.

To make things short: there is no way to avoid a ground connection when using USB, it's simply a shortcoming of the USB specification. This has been discussed in this forum a number of times already.

Way to get a reliable connection anyways:

- Using Ethernet instead of USB. Requires quite some complexity on the controller electronics, of course. Duet electronics does this.

- Putting an optocoupler between USB-serial converter and controller CPU. Can be done right on the controller board, but you still need the serial link in between, no on-chip USB. Also take care to keep the PC connected USB strictly separate from the printer power supply connected remaining controller.

- There are USB transceivers, sort of an optocoupler for USB. Simpler than Ethernet, more complex than when using a serial line.

- Print from SD cards. That's why SD cards are so popular.

The really silly thing about USB is, the protocol doesn't allow to recover stalled connections. Can be done manually, though, that's why some controllers have a jumper to disable auto-reset (for avoiding a reset when reconnecting).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think the simplest thing you can to about USB ground loops is to arrange the layout in a way that makes any ground loop current not affect thermistor readings. Like this: [www.pasteall.org]

Excuse me for my primitiveness (I'm not an EE), but I do believe this will prevent the issue. The problem with RAMPS-FD is that you don't have the ability to make a thick connection between USB shield and DC- and/or move the low power components (MCU and thermistor) away from the USB shield.

Edited 2 time(s). Last edit at 03/24/2014 02:46PM by ambrop7.

The problem there is that while the MCU itself on boards like the Mega and Due has a separate ground for the analog inputs, the boards (such as the Due and Mega) have one common ground plane for everything.

And if you get a decent current through any ground pin to the ground plane on the Due/Mega, it changes the readings.

On a Mega it's not so bad as your Max reading is 5V, whereas due to the lower 3.3V Max on the Due, the changes are more noticeable.

Are the analog readings a problem? Most electronics don't even try to get smooth analog voltages, so it appears to be a non-issue. Controllers with analog smoothing are Gen7 and STB, IIRC. Teacup firmare also features mathematical smoothing.

One issue with USB is, the connection occasionally stalls, apparently due to GND differences. Happens for me something like once a week.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Tramflug: If you want anything resembling accurate temp out of a thermistor, then yes. Difference between heated bed on and off (current flowing through the ground) can, in some instances, alter the temp reading by 10 (or more) degrees with 1k bias and a standard 100k thermistor if the current flow is high enough (based on a report from the RAMPS-FD thread). That can lead to quite a bit of overshoot in the wrong situation.

Specifically, think of this scenario:
You've got a hot end with a max temp of ~240, and you're printing ABS at 235 because you have a small nozzle (say 0.3). Heated bed comes on and your reading plunges to 225, so it turns on the heat till it gets to 235. Heated bed comes off, you're now at 245. Not going to do the print any good, nor is it going to do the hot end any good.

That's a lot of hysteresis caused by bad analog readings.

I've seen this issue with 2-3 degree fluctuations with RAMPS/Arduino Mega (5V) if there is a bit of a ground loop with the PC. With more electronics going to 3.3V electronics, this only gets worse.

I have skimmed through the RAMPS-FD thread now, very inspiring. I hope no one is offended if I blatantly steal from the design?
If I got it right the problem was the common node of the bed heater FET lifted and current started to flow through the USB cable? Did the layout change fix it?
My biggest concern is getting the pinning of the MCU right. I can´t really get it with the pin assignment muxing. Anyone know if there is a simple way of sorting out the configuration?
I have spent way to much time browsing for stepper drivers but keep coming back to A4988. I believe there is a reason they are popular. A while back I looked at DRV8825 but I must be remembering wrong or have they gone up in price lately? Would you recommend any other driver than A4988?
I was set on making the board 12V only to keep size/cost down but is still tempting to make it 24V tolerant. I have only a few hours of experience with 19V so I have no clue if I would regret designing for max 12V, advice highly appreciated. Less current with 24V just feel more and more like a good idea when I´m thinking about it.

I have a layout of the dev board as good as finished as it is not that much to it. Do you think it is worthwhile make a run with it or make a full design right away? Ambrop?

Mallgan: I don't think bobc would mind too much (it is OHW after all), but only he can say for sure. I've not heard from him lately though, which is slightly worrying. Last commit to his github was on the 27th of Feb, which makes it a month now.

As for the work I did on it (minimal compared to bobc) I'm happy to let other people use it (otherwise why would I be helping bobc).

As for the layout fix: I haven't made any prototypes of the new version, so I can't say for sure if it worked. The workaround that someone did solved the problem (and that's what we've tried to emulate), but only way will be to test. Some prototype boards were on order by bobc, but since I haven't heard from him, I don't know if there were any issues.

Quote
Cefiar
Tramflug: If you want anything resembling accurate temp out of a thermistor, then yes.

OK, so poorly designed electronics are apparently standard and accpeted. Has nothing to do with the ground loop problem, though.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Layout of the developement board and schematics. The protection components are of course optional.
Ambrop, do you have tools for SMD soldering?

@Mallgan.O
I do not have SMD tools.

OK. Then maybe it is best to leave out the protection on your board so you can use them as you like? Do you have any comments regarding the design? I might add that it is a 4-layer board but I only included top and bottom layer in the pdf.

@Mallgan.O
Sorry but I don't know what to say about the design, I'm not an EE. I don't know how the presence of protection components would affect me. For testing, I'm planning to hook it up with wires to my RAMPS-FD or RADDS board (got both). These are designed to work with an attached Arduino Due (AT91SAM3X8E).

well, first thoughts - it's a good idea, I'm looking at an NXP ARM device for a new board design, but I'll throw my criticisms in as well:

Your cap's near the pins will affect your sample times on the analogue reads - as for thermistor sensor reading, they have a specific source current that should not be exceeded, this is usually a part of the design of the circuit that reads the thermistor
You've tried to address the max voltage issue, but I would suggest being aware that some pads are voltage tolerant, and others aren't, so you may find that there's some that you can use specifically for high voltage tolerance (12V) and others where a voltage divider will do for input (and a BJT for output?)
EMF is a whole lot of black magic, I've had fun designing my own power supply (1A 5V Buck converter with a 9-30V input range) to filter out the unwanted noise, and it's the noisy components that need EMF protection (solenoids, switches, motors), or you need physical design to protect from it (farady cage around your board to remove it's susceptibility to EMF - think metallic powder in the plastic case)

noise protection on input lines is a fine art, and pointless if you shield the cable but do nothing about the rest of the electronics. Usually you connect one end to an earth and leave the other end hanging (or even disconnect both ends and have a central bond point for the shield), any other way and it acts more like a wave guide, transmitting noise from one side (that noisy coil in the PC power supply) to the other (your nicely shielded box housing your electronics) - ground loops in shields are an extension of the same, don't eliminate them (impossible) but try to make them as short as possible and as far away from the sensitive stuff as possible.

Thanks for the input.

I was interrupted by a flue but now the is MCU developement board sent for manufacturing. I opted for the cheap shipping so we will see when it arrives.

Heres som draft specs of what I have in mind:

ARM mcu(ATSAM3S2A)
USB
4 stepper motor drivers, XYZE (A988)
3 endstop inputs, XYZ
1 PWM extruder heater driver
1 Fan control output
1 driver for external FET(bed)
2 temperature monitor inputs(thermistors)
20V max supply voltage
Emergency stop
Software controlled motor current setting(digipot)
Unused pins on headers

Have I forgotten anything?
Do you think it would be a good idea to have an on board serial flash as file storage?

Finally a yellow tape parcel arrived



10pcs 4-layer 50x50mm for a total of $28.7 delivered 27 days after ordered. I ordered from elecrow dot com and must say I am happy with the deal.

Been a bit lazy and have not ordered the MCU's yet but I think everything else is here somewhere. If anyone is interested in a SAM3S devboard you can PM me as I don't think I will use all ten boards now. If anyone is interested in gerbers and BOM let me know otherwise I don't think I will get around to host the documentation. The board sources are in a proprietary format so I don't think they are of much use for anyone. I decided against combining this project with learning kicad or geda for practical reasons but hopefully I will take that step someday.

After some crazy weeks at work and home I finally managed to put a couple of boards together:



I have only verified that it shows up in BOSSA and I have written dummy files to the chip so I hope it is working OK. I send one to you Ambrop7 asap.

The driver circuitry is almost finished, I am going to evaluate some components before I decide wich one to choose though.

I've already got my APrinter firmware running on this.

There were some mysterious problems with the ADC, even though I was using the exact same code as on AT91SAM3X8E. After some experimentation I concluded that the hardware must be broke. So I looked into the errata and there it was:

Quote

45.2.2.3 ADC: Trigger Launch Only One Conversion
A start command initiates a conversion sequence of one channel, but not of all activated channels as expected.
Problem Fix/Workaround
Send as many start commands as the number of activated channels, or use the free run mode.

I hacked around it by setting up the ISR to trigger whenever a conversion is complete (as opposed to when the conversion of the last channel is complete). The ADC seems to be working after this. I should note that this erratum only applies to Rev A of the chip, which is what I have on the board, not Rev B.

Quick commands to try it out (Linux, maybe OS X):

git clone [github.com]
cd aprinter
./build.sh mlab install
./build.sh mlab build
./build.sh mlab upload

To be able to upload, you need to short the erase jumper and remove it, then run the upload command above. When uploading is finished, press the reset button to start the program. You can then connect with Pronterface.

I have not hooked it up to a 3D printer, but I see no reason it wouldn't work.

P.S. @Mallgan.O Please make up a name for your board

Edited 2 time(s). Last edit at 06/11/2014 06:14PM by ambrop7.

Wow, that was fast! Well done

I got to get my act together now and finish up the rest of the hardware asap. I am stuck obsessing over the heater driver. I am considering using a switch mode regulator as a variable current source but have to try it out on the bench.

I am going away tomorrow over the weekend and will not be able to test until next week though.

Thank you so much for helping me out .

I will do my best to get some hardware running asap!

Quote

P.S. @Mallgan.O Please make up a name for your board winking smiley

Pussel? (Puzzle) Is that OK do you think?

Cheers!