SmartMic SM1000 Part 1

So the parts and PCB arrived from the SM1000 last week, and yesterday I started loading. I use a stereo microscope and hand solder each part. It’s actually fun, a nice change from software.

Here is the current (Rev B1) SM1000 schematic if you would like to follow along.

First I assembled the 5V switching supply, this worked OK except I had the tiny surface mount LED R33 around the wrong way. Then the 3V3 regulator, and this morning I spent a few hours soldering all the parts around the micro-controller (bypass caps, pull ups), and finally the STM32F4 uC.

I connected power but to my dismay couldn’t see any waveform when poking around the uC crystal. After a bit of head scratching I looked at the data sheet. The STM32F has many clock oscillator options, and it turns out that the default (factory) state is to have the external high speed crystal oscillator switched off.

So I connected a STM32f4 Discovery as an STLINK emulator pod, fired up the “st-util” GDB server program on my laptop and it didn’t work:
david@bear:~/stlink$ sudo ./st-util -f ~/codec2-dev/stm32/fft_test.elf
-f arg; /home/david/codec2-dev/stm32/fft_test.elf
2014-07-07T13:47:33 INFO src/stlink-usb.c: -- exit_dfu_mode
2014-07-07T13:47:33 INFO src/stlink-common.c: Loading device parameters....
2014-07-07T13:47:33 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Chip ID is 00000000, Core ID is 00000000.

Hmm, that doesn’t look good. I started worrying that there was some other trick I needed to flash a bare-metal uC from the factory state. Then I checked the PCB. Turned out I has soldered R20 (a STLINK series termination resistor) in the wrong position. So I moved it and it still didn’t work. Then I looked again and found out I had moved the wrong resistor! So then I moved two resistors to fix my mistake and:
david@bear:~/stlink$ sudo ./st-util -f ~/codec2-dev/stm32/fft_test.elf
-f arg; /home/david/codec2-dev/stm32/fft_test.elf
2014-07-07T13:51:06 INFO src/stlink-usb.c: -- exit_dfu_mode
2014-07-07T13:51:06 INFO src/stlink-common.c: Loading device parameters....
2014-07-07T13:51:07 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2014-07-07T13:51:07 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
Chip ID is 00000413, Core ID is 2ba01477.

Yayyyyyyyyy! I then flashed a test program (that does not use any I/O) and proved the uC was working just as well as the Discovery boards:
GDB connected.
kiss_fft 0.59 msecs
fft 0.56 msecs

Cool! That’s a FFT speed test program, that shows kiss_fft runs slightly faster than a FFT routine “optimised” for the SMT32F4. This was a test program I had laying around last year when I ported Codec 2 to the STM32F4.

OK, next step is to load one of the analog interfaces and see if I can output a modem signal.

5 thoughts on “SmartMic SM1000 Part 1”

  1. Hi David,

    Getting the chip to talk at all is always the biggest problem for me!

    Sounds promising :).


  2. David,
    Glad to see(literally) the SM1000 coming together.
    Most of the hiccups , so far have come from component issues. For the uninitiated, about 1/3 of the design/layout effort comes from researching parts. First you have to spec the right part, then, you have to get it on the BOM correctly. For those interested, I’ve started a change log on the SVN site. Changes to REV-B1 are being incorporated int REV-B2. The next build of boards should have these included.
    Keep up the great work!

    Rick Barnich

  3. Congrats David et al,

    I was a little disappointed that your first program wasn’t to the blink the led that you had around the wrong way… Embedded developers equivalent to “Hello World”. I guess you have a bit more grunt than some of the small micros around these days.

    When you’re ready to reflow your first board you’re welcome to use my Arduino controlled toaster oven, works good 😉


Comments are closed.