Interactive web site of Télécom ParisTech's ELECINF344/ELECINF381 Robotics and Embedded Systems classes (a.k.a. ROSE, 2012 session).


Re-chosing the microcontroller

Last Thursday we had a quick meeting with our teacher, when we discussed about the general status of our project. One of the topics was the micro controller choice. They suggested we checked the STM32 low power and connectivity lines, so we did a little research on it today.

We wanted to eliminate JTAG programing interface and program directly by USB or Zigbee (by UART/USART). The STM32 have boot mode that starts a embedded boot loader which is capable of receiving an image by a communication interface, and loading it in flash. The difference between the STMs is from where they can get this image. They all can get it from USART, but only some of them can get it from USB. The  one we had  chosen before can get it only from USART, so we need to change.

Having that in mind, we got to two possibilities;

  • A  STM32F105 or F107, from the connectivity line, allows flashing from USB, USART and CAN.
  • A STM32L151/152 with flash size of 384kB, from the low power line, allows flashing from USB and USART. For example the STM32L151VD.

With the low power devices, we have the following inconveniences:

  • The datasheets and reference manuals say we can flash from USB, but the system boot loader manual says nothing about them. The only information we have from this manual is that the low power medium density F151/152xx devices can’t flash from USB, only from USART.
  • The low power devices with the 384kB memory seem to be difficult to find. We couldn’t find them at Digikey or Farnell (Radiospares is offline today).  So we know nothing about the price now. The lower memory versions are availlable but don’t allow flashing from USB.

With the connectivity line devices:

  • They consume a little more than the low power devices (obviously). While the low power needs a supply current of 230 µA per MHz, the connectivity line needs 393 µA per MHz.
  • One option is  STM32F105RB, featuring 128kB flash, 64 pins. It is available at Digikey for 7,50 €. There is also the F105RC, for 8,60 €, featuring 256kB flash, 64 pins.

To choose memory size, we checked our communication challenge’s program size, imagining we would have for our robot something at least this complex. Its about 100kB, so we thought that 128kB might not be enough.

Having all this in mind we are deciding for the F105RC. It’s only one euro more for double the flash of the F105RB, and we have clear documentation about the system boot mode for USB programming. Also, if we use a clock as low as the low-power’s , we won’t be consuming so much more current.

If you have any suggestions don’t hesitate to leave a comment =)


4 comments to Re-chosing the microcontroller

  • Phh

    Why totally forget JTAG ? With proper tools/IDE it would help quite a lot to have it for debugging purposes, and it can be all integrated within a FTDI chip afaik (you can take a look at beaglebone’s schematics which integrates a jtag over usb).

  • Gabriel Teixeira

    Honestly, this used to be the choice of the group, but according to our market research (i.e. talking to the professors), the interface won’t be needed for a number of reasons. The main one is the increase of the number of devices to perform the development. One JTAG probe costs around 60€ to the school and have to be replaced very often. Another reason is the number of I/O ports that are used by JTAG.
    My original solution was to integrate a JTAG to USB bridge in the board, exposing a USB interface, which is available in most personal computers, but this still doesn’t solve the problem of the number of ports used by JTAG. I could find the chip you said at Digikey for 3€51 and will be considered if we can afford both price and ports used. Yet, according to the BeagleBone website, the support for BeagleBone’s JTAG bridge “is still a work in progress”, so we get concerned to adopt a still little supported solution given the little time that we have to develop everything.

  • Phh

    The reference you gave only does UART, not JTAG. Concerning the “work in a progress”, my guess is that it’s because they have problem with the omap3, rather than the jtag bridge itself. School’s jtag probes are FTDI based (or just ftdi compatible ?).
    Here is a proper reference on Digikey.
    Concerning the number of ‘ports’, you mean number of pins available ? If so, i don’t think you’re very limited by the price of “big” µCs. If it’s the number of plugs, you can use an usb concentrator (like this one, which is the one used in the beaglebone).
    That makes a total increase of 2.71€ (usb concentrator)+ 5.54€ (FTDI) + perhaps 2€ to go to a “wider” µC. I agree it’s not negligible for your project, but considering the level in C programming of first year students, i feel like it’s needed. Without a jtag you can’t know where your code crashes… (and on a side note, you should consider protecting address 0 against read/write/execute to avoid null pointer problems.)

  • [...] talking to the professors, the interface won’t be needed for a number of reasons : not quite. We told you that you should offer the possibility to reflash over USB, not to abandon JTAG !