...when you didn't have a design review!
Started stuffing & testing the purple board that arrived yesterday.
Power section first, of course.
Now I note that the 5V regulator doesn't have a ground fill area under it, let alone vias to the ground plane.
Also, while I'm at it, I observe that some of the other ground connections are stupidly autorouted, optimizing for minimal via count instead of shorter traces.
Oh, well. Should work anyway, though some parts may be seeing more noise than they should.
3.3V and 1.8V came up just fine.
5V didn't come up at all, until I replaced the regulator chip. I'm guessing the original had gotten damaged during the multiple iterations of reflow soldering (both of the little DFN-packaged switchers floated out of place the first time around, and needed to be nudged along with the solder melted for a second or third time).
Anyway, all the power stuff is working now, and the lack of proper heat-sinking under the 5V regulator just means I won't be able to do as much as planned with the 5V output from the board - everything on the board should be fine (it's all low-power stuff).
Next up: install the rest of the passives (mainly bypass caps) and the MCU, and see if I can talk to the MCU with the emulator pod. Then the sensors and incidentals, and it'll be (from a hardware perspective) all ready for show'n'tell.
Update: in among other stuff, I found time to install the MCU. Hooked up the debug pod, and thence the SWD from the Discovery board. Wouldn't talk to the SWD. SWDIO was pathological... like it had a huge capacitive load on it. Hmmm? Ah: too much solder paste on the debug connector; it had wicked up and shorted SWDIO to, indeed, a power line (fortunately not one that was actually in use, but one with considerable capacitance present).
Since unshorting vertical FFC connectors never seems to work for me, it was time to pry the housing off, unsolder all the contacts, clean up the pads, apply a thin layer of paste, and install a fresh connector. After that, the debugger came up.
Alas, when I try to run one of the test programs for the Discovery board, it chokes partway through initialization. Um. The Discovery board appears to have an 8 MHz crystal on it; my board has a 16 MHz MEMS oscillator. Obviously, the difference between quartz and MEMS technology is to blame. Or, y'know, trying to run a 168 MHz processor at 336 MHz, assuming the demo code is trying to set the critter for full speed.
Ah, well. The day is officially over, and the board is at least showing signs of life. Between now and Halloween, I want to get some sort of code running and the sensors installed (and maybe even tested in some minimal sense).
Update 1a: a little more tracing reveals that, just after the demo program sets up the PLL for high speed and selects it as the clock source, the whole thing goes BLATZ!
Sounds like I need to figure out which register needs dividing by 2, and which #define corresponds to that.
At least there appears to be a good excuse for the malfunction.
Update 1b: found the two, count 'em, two places that "8" needed to be changed to "16" - one in a header file, and the other in a nominally-immutable source file. Change those, rebuild, debug: the debugger is now happy and seems to be behaving itself. So, a working CPU core, at least. (Also working flash, and RAM, and so forth.)
Comments