Wednesday, July 8, 2009

chicken before egg before chicken before egg before...

I've been a bit quiet on here lately, but I thought it was time for an update.
I could be silent about the difficulties I face, and present the "business is good" smiling face of a salseman, but hey, this is real life, and you have to crack eggs to make the omlette !

Firstly, when I designed the board, I'd intended to run it with MOSFETs for my general purpose power outputs. However, when I looked up the specifications of the MOSFETs I still had a part tube in stock of from some years back, my suspicion was proved right, that their gate drive requirement was too high. For some strange reason, I decided to use darlington transistors, which were pin compatible, but I forgot that the base can sink a lot of current. All went well,until I decided to try ramping the PWM output on a motor that will take around 10 amps, as the ramp speed built up, I overloaded the darlington transistor, and it fed back a nasty spike to my arm microcontroller, and cooked it. :(

At that point, I realised that I hadn't designed in base resistors either, because I didn't need them when driving MOSFETs !

So... I flamed the centre of the chip until I could lift it off.
By this time, my first board was getting a little bit too much action around the fragile 100 pin TQFP package traces, and some were starting to lift off.
My attempt at resoldering a new arm onto the same footprint didn't go particularly well, so I started a new board, while also hunting for my super magnifying goggles, which took a while to surface.

Eventually, I found my goggles, by which time I'd partially assembled a new board.
By the time I'd tidied up my PCB traces and alligned them , improving with each session, I felt like a highly skilled surgeon, only without the Kudos, the nurses to hand me forceps etc, and without any sign on the horizon of even a smidgeon of a surgeon's generous sallary package.

Currently, I have my original board, of which a couple of the stepper motor control traces may or may not work since my last microsurgery, and my new board, which seems to be all good so far.. brand new components, all tested so far, in good working condition.

However, I designed in USB and SD card functionality to my hardware, and it's pretty pointless loading up a coordinate file, or gcode file into flash or the microcontroller to prove my stepper motors work, that's not a deterministic test.

Determinism is the stuff that happens in real life, not on someone's test bench. Determinism, when I read about it many years ago in an excellent book called "The Holographic Paradigm", is basically the theory that if you want to know how something will turn out in real life, the very best simulation requires maximum similarity to the actual situation, an is in fact, tha actual situation itself ! A bit tough for people like weather forecasters, but they do the best they can.

So, I started on merging the USB Virtual com port project with my project.

EEEEK !!!!@$!@# ! ~~~~ incompatible libraries !!!

After a late night edit of some source files to try and achieve a degree of compatibility, when I wasn't at my freshest either, I broke my project.

So, where I'm at now, is I have a working backup prior to the attempted merge, and lots of my own new code which also runs fine when it's got coherent source libraries.

I've decided that the best way to progress now (after going to Jaycar and picking up some more USB printer sockets and SD cards SMD sockets), is to use the USB Mass_Storage sample project, and get that working on my custom hardware, that way, I have the most difficult (to me) part of the whole project running, and then I can take my custom code (which I know), and merge that to the USB Mass Storage project instead.

Until I have the USB code working, I can't test out gcodes sent from my PC,so it's pointless writing the gcode processing routines yet, the way I see it.


  1. Just an observation from the field here - if you have to choose between working on sending G-codes over USB or an SD card, aim towards the SD card. The problem with sending Gcodes over USB is that any interruption in the stream of G-codes results in a lump of extra plastic in the when you're extruding. Buffering the G-codes on the firmware side helps, but you still can run into trouble.

    You're essentially adding a whole series of new failure mechanisms when you add a PC into the mix; I'm really looking forward to getting some sort of SD card printing solution working. I had all sorts of issues getting smooth printing out of a PC - I had to try three different computers before I got one running smoothly. Plus, you can't touch that computer then during a build (which can last for days) for fear of messing up the print. That sucked, as only my favorite, fastest computer would print smoothly.

    Interesting stuff though - good to see some more options for the electronics side of things.


  2. Understood Wade,

    The ST32F103VBT6 that I'm using has 20K RAM. I believe 4 K is reserved for USB, though I haven't delved into that properly yet.

    The new ones are available with 512K Flash (1000 erase cycle rated), and 64k Ram. That might do quite well for a buffer, though the PC protocol would have to be very robust to handle random interruptions to it's connection if you were doing things like restarts. Otherwise though, I can imagine it being able to run standalone with the big chip... for maybe half an hour ?

    A pity the flash erase cycles are so low... still, there is scope for saving a favorite shape to it, or embedded objects that could be refered to at a higher level.

    I hadn't noticed that USB needs some form of pullup on the + line, just soldered in a 1k8 resistor to 3.3 volts, and now my windows PC is seeing it (my circuitboard), as a Mass storage device.

    However, when I insert my SD card, I loose the USB pheripheral from my My Computer list.

    I'll have to double check all my USB connections to the uC again, or it could be the SD card, which is a functional 60x 256MB Kodak. I have to check the demo application also, to see if anything is different about their hardware implementation of the SD.

    I remembered a couple of days ago to check the settings on the STM phase locked loop crystal clock multiplier, I'd completely forgotten ! Looks like I can go faster by a factor of 10... Zroooooooom!

  3. Ah... just checked, and the demo STM3210B-EVAL PCB appears to use SPI1.
    Great news, I'm using SPI2 on my board, so I need to hunt down the SPI1 references, change them to SPI2, and set the SPI2 pheripheral up correctly ! then.. hopefully, I'll have a glorified SD card reader/writer !

  4. I sympathise with the switching device woes.

    May I suggest that in future use MOSFET s and driver chips? They aren't expensive and will run cooler than Darlingtons. Additionally, MOSFETS should have a few Ohms of gate resistance (10 Ohms is usually good) to prevent oscillation between the stray inductance in the gate wiring and the gate capacitance inside the FET. This can cause RF interference, hot MOSFETS or even complete faliure.

    Good luck reworking your code / comms / USB! I spent some time wondering what went wrong with a devboard on my desk because every time I put a serial comms jumper in the bally thing disconnected from the USB port! I eventually realised that I was putting the jumper on the reset header by mistake :-)

  5. Ah !

    Well, at the moment I've found out this:
    The SD card isn't recognised by the demo software when I have a permanent 1k5 pullup resistor to 3v3

    If I make a spare Microcontroller pin my 3.3 V for pullup, and set the demo SW to control the pin, on and high, or an input, then I get USB errors on the PC.

    There is a transistor pair controlling a 1k5 pullup on DP in the demo schematics.. but I never thought to look for an extra like that when I was making the board.

    My next step, is to try a signal diode from my control pin in series with the 1k5 resistor, if that doesn't work, THEN I'll try the transistors.

    In the mean time, I made a super small pocket jet sprint boat last weekend, 250mm long x 140mm wide. intended for high power brushless motor and LiPo batteries.

    My one is the one under "grael" posts on this thread:

    More incentive to get my machine operational, hand machining of such a small jet unit is very delicate work, the jet flow diameter will be only finger width.