My first P2 PCB (single axis servo)
ManAtWork
Posts: 2,178
in Propeller 2
I'm just about routing my first PCB with the P2. It's a single axis servo controller (to avoid confusion, I mean a brushless motor controller for use in CNC machines, not a model size servo used in RC cars or robots). The basic design was already there from my previous attempt with an ARM CPU. Replacing that with a P2 added a bit to part count and space due to added voltage regulators, EEPROM and passives. But it also greatly reduces routing complexity because pin assignment is far less constrained.
On the left side is the power stage and two big terminal connectors for AC power, motor and (abs) encoder. The left one of the pin headers goes to the power module (IGBTs) on the heatsink. The relay (K1) is for soft start. On the right side is the low voltage part with the big P2 chip in the middle. the small pin header left to it is for programming (prog plug) the big on the right for expansion (resolver, +/-10V command input). The connectors at the bottom side are for command input and (incremental) encoder. On the right side are terminals for low voltage power supply (24V) and cooling fan.
On the left side is the power stage and two big terminal connectors for AC power, motor and (abs) encoder. The left one of the pin headers goes to the power module (IGBTs) on the heatsink. The relay (K1) is for soft start. On the right side is the low voltage part with the big P2 chip in the middle. the small pin header left to it is for programming (prog plug) the big on the right for expansion (resolver, +/-10V command input). The connectors at the bottom side are for command input and (incremental) encoder. On the right side are terminals for low voltage power supply (24V) and cooling fan.
1093 x 874 - 129K
Comments
dimensions: heatsink 100x100mm, PCB 100x80mm
You might want to get an idea of power needed and temperature management of the prop2 as well. I'm assuming you'll be pushing the MHz for max maths performance. If some of that air flow circulates past the prop2 area then that would be good for it.
Here's a table of some test loops using both one and eight cogs and the amount of VDD current needed - https://forums.parallax.com/discussion/comment/1482622/#Comment_1482622 Pgm0 is simple cogexec, pgm1 is lots of WAITX's, pgm2 is the cordic unrealistically maxed out, pgm3 is same but with hubRAM bandwidth also maxed out, pgm4 and 5 are similar to pgm0 but in hubexec with different extremes of hubRAM bandwidth.
1) switching regulator 24V to 5.3V, 600mA max
2) linear LDO 5.3 to 3.3V for P2 digital VIO and expansion (<100mA expected)
3) switching regulator 24V to 5.0V 200mA max for encoder, ModBus and command interface (P2 stays alive if this one is shorted)
4) linear LDO 5.3 to 3.3V for P2 analogue VIO (<100mA)
5) switching regulator 5.3 to 1.8V for P2 VDD, 2A max
6) linear LDO 5.3V to 5.0V for current sensors (~30mA)
and on the AC side:
7) switching regulator 320V to 14V for IGBT gate drivers
8) linear regulator 14 to 5V for slave CPU and optoisolators
I think the P2 will not be loaded to anything near 1A. Single axis PID and a bit park transformation should be pretty boring for it. Everything can be handled with smartpins, streamer and cordic unit. There's not much actual math work to do for the CPU. I just want to try out what is required and scale it up if it also could be done for 6 axes simultanously. With the multi axis project I'll probably come close to the limit...
Don't mind the odd signal names (USART, SSC, TC and so on...) they are remainings of the older ARM design. I was just too lazy to delete them.
I hope I've connected the EEPROM and supply correctly. Please tell me if you find a problem. I know, the XI/XO is rated for 10..20MHz. I just have some 25M crystals in stock and use them for the prototype. Can be changed to 20M later if necessary.
Doing the solder stop and paste mask for exposed pad QFN or QFP boards is always a bit "vodoo" science. If too little paste gets printed on the exposed pad or if there are too many or too big vias then the molten solder will drain into the via holes. If there's too much paste then the chip will swim on it and possibly not all of the gull wing pins will solder correctly.
I've made good experience with having around half the copper surface open in the paste stencil. It's a prototype... If the amount of paste is wrong I could adjust the stencil later.
There are two bypass capacitors for VDD and two for VIO at each edge adding up to 16 altogether. I think that should be enough.
Sorry, meant vias.
I also notice that in your pick'n'place that there were a lot of caps that weren't sitting on both pads. I take it that you did a final alignment but I find that a photo after the alignment is more useful for when things go awry after reflow.
I can only say that soldering worked well. To tell wether the thermal connection of the P2 case to the ground plane is good I'd need an X-ray machine. But I'm optimistic. If the HAL is done well and there's not too much solder paste so that the chip swims or there are side balls then everything should be fine.
I order prototype boards from jlcpcb.com (if it's not urgent). They are cheap and have a nice online gerber preview so you can spot the most obvious errors before ordering. Production boards and urgent prototypes I buy at multipcb.de. They have better process quality (drill alignment, trace width and copper layer thickness tolerances).
The current sensors are IC1 to IC3 and have nothing to do with the header pins. If you look carefully you can see the isolation barrier shining through as a bit brighter "trench" across the board from the relay at the bottom left to the 6-pin header on the top right.
Yes, this was caused by my sloppiness. Normally, when I assemble two sided boards I have to make a support structure to place the top side. I was too lazy for only 2 boards so the PCB tilted and clattered sitting unevenly on the already placed bottom side components. That caused the misalignment. But the reflow-soldering process is very forgiving. If all paste dabs are touched somehow capillar force of the melting tin will re-align the not too heavy components automatically. I only had to manually re-align two or three caps.
I was looking at the final pcb but I just glanced at the pcb artwork and those sensors do seem to go to 0.1" header pins. Am I wrong?
The smaller 1x5 and 2x3 pin headers are for programming of the P2 and the HV-side slave processor (IC21). The 2x12 pin header on the right side is for extensions (resolver and tacho analog front end). The 3-pin header on the top right is for the cooling fan.
Ah OK, I know what you mean. Yes, pins 7 to 12 of the sensor are connected to two pins of the header. This is the center tap of one IGBT half bridge. The IGBTs sit on a separate aluminium core PCB on the heatsink below the main board. Pins 1 to 6 of the sensor go to the motor terminal via the inner layer. Remember, it's a 4 layer board.
* Full duplex UART communication between P2 and slave processor is running now at 10MBd
* CRC generation and verification sorted out
* Timeout and re-connection supported (power stage could be switched off at any time)
* 3-phase PWM is working
* Clock synchronisation between PWM (slave CPU) and ADC cycle (P2) is working. This is done with a PD control loop in software which compares packet reception times against PWM counter phase and tunes the PWM frequency accordingly. There is no hardware link between the clocks. The P2 runs on a crystal and the ARM has a built in calibrated RC oscillator that can drift about 0.5% or something.
* A/D conversion of the current sensor signals works with auto-calibration
* Measurement of DC bus voltage and temperature works. Temperature measurement required quite some math. The (cheap) NTC I used is non-linear and requires 3rd order polynomial approxximation to get nice linear readings.
* Park transformation and inverse transformation works
* PID control calculations are implemented and tested to some degree
* Parameter storing in the boot flash rom is working
* Interface for optical absolute encoders is working (Tamagawa and SanyoDenki serial protocol, 2.5MBd RS485)
It still runs open-loop (without encoder feedback and velocity control loop) and only with 48V power supply. But at least it demonstrates that the slave processor for PWM, the power stage and the park transformation is working.
That is a thing of beauty!
But I'm a bit weird
Great job Nicolas 👍👍👍😎
BTW, I'm currently porting all the code that that is dedicated to this project to C. I try to keep the part of the code that could also be used for other purposes (encoder drivers) in Spin. Any objections? (For the case that I make it opensource, later)
It's amazing, the P2 can deal with two serial connections, one for debugging (230kBd) and one for the scope and monitor (1MBd RS485) and all that in a single cog. I also learned how to talk to an FTDI USB device directly. Those VCP drivers and especially the handling of COM ports in Windows suck!
I hope I can finish the scope software soon so I can go back to the actual task: programming the propeller.
Years ago, I tried to use the VCP driver for the FTDI chips and was like a brick wall. How do you talk to the FTDI USB directly?
1 cog for command interpreter (user interface for tuning + scope)
3 cogs for current PID control loop
(6 counters required for ADC and PWM, many multiplications also used up almost all the computing power of those 3 cogs)
1 cog for velocity and position PID loop
1 cog to handle encoder or resolver feedback
1 cog to handle command input
1 cog for serial communication (either debugging or user interface, both at the same time was not possible)
Now with the P2 it's like this:
1 cog for command interpreter
1 single cog for current control (cordic unit is extremely useful and reduces computing time to a few µs)
1 single cog for two serial ports (user interface + debugging)
3 cogs for vel+pos loop, command input, feedback
If I ran out of cogs I could even run the vel+pos control loop in an interrupt of the interpreter cog. Feedback and command input could surely be done in a single cog, too. But as long as I have enough cogs I leave it that way because it's more flexible. I can simply swap out objects to handle different types of encoders, for example.
I use the ftd2xx driver. You have to check the "Load D2XX Driver" option in the FT programming utility. Then no VCP driver is loaded when the device is connected to USB. You can then use the ftd2xx.dll to talk to the device directly. It's possible to open a connection by name (string descriptor programmed into the FTDI EEPROM) instead of port number. So you don't have to scan all ports to find the right device.
BTW, the propeller tool handles COM ports quite well. I always had problems providing correct timeout handling in my own software. I used to take an open source library (ctblib) but it no longer works reliably with Windows10. COM ports above COM10 are treated differently and are no longer found on all PCs.