Group Actions
Engagement
  • Author Author: shabaz
  • Date Created: Date Created
  • Views 3019 views
  • Likes 11 likes
  • Comments 61 comments
Related
Recommended

EasyL1105: A Dev Board for the TI ARM Cortex-M0+ L-Series

shabaz

Table of Contents

 

TLDR Section

The easyL1105 is a TI MSPM0L1105 Development Board that can be DIY'd. Here are the links:

Schematic PDF

PCB Gerber Zip file

Parts List PDF

For more blogs and information: Use the searchbox, tags are easyL1105 or MSPM0

easyL1105 GitHub repository page

Introduction

I was browsing the Texas Instruments (TI) website, and noticed they had some very low-cost, very basic ARM Cortex-M0+ microcontrollers. I was keen on finding something low-power, small (but hand-solderable), and cheap. I aim to eventually use such a chip for interfacing to simple sensors for a few possible projects (one requires some sort of low-accuracy current sensor, and another requires an presence sensor), so all I require is a basic built-in ADC, I2C, SPI, or perhaps UART, and either control an output, or send text to an I2C LCD display, or perhaps write to external SPI storage.

In the end, I decided to order a few parts from the TI MSPM0 L-Series, which they class as low-power, and I found a 28-pin variant which has a fair amount of general-purpose input/output (GPIO) connections.

The microcontroller doesn’t have any particularly remarkable features, other than the very low power consumption and cheapness, and the fact that it doesn’t require many components at all, not even a crystal oscillator. Just a few decoupling capacitors are all that’s technically required.

image

(Image source: Microcontroller PDF Datasheet)

In shutdown (with GPIO wakeup capability), current consumption is apparently 61 nA, which seems pretty low. RAM can be maintained and timers can be running in a ‘standby’ mode, where current consumption is 1uA, which also seems reasonable.

One more thing I really liked; it has an in-built bootloader that can accept firmware over the serial (UART) port, so that no separate programmer device is required for in-the-field updates. You could just attach it directly to a PC and program it up.

The particular part I went for is the L1105 (the full name is MSPM0L1105TDGS28R), which has 32 kByte of Flash memory and 4 kByte of RAM, but there is a pin-compatible L1106 upgrade part with 64 kByte of Flash if needed.

In terms of major downsides, there’s no ability to add a crystal oscillator if you need such precision. Interestingly, as a compromise, the chip can use an external 0.1% tolerance 100k resistor in order to create a reasonably precise internal oscillator, but it won’t compare with a crystal, of course. I would have liked an accurate RTC, but I suppose that could always be an external I2C peripheral chip, perhaps with a separate backup battery.

TI doesn’t actually have a dev-board for this particular L1105 part, but since it’s a simple chip, I’d much rather make my own dev-board, so I can get used to working with the chip without all the extras that many dev-boards have.

Circuit Description

The circuit is split up into three main sections, described next. For the PDF version of the schematic and the project files, see the easyL1105 project repository on GitHub.

1. Microcontroller Core

The core of the circuit is shown below (click to enlarge).

This doesn’t do much, other than breaking out most of the microcontroller connections to 0.1” pin headers. I took a reasonable guess at how the pins might be used, and so some are labelled with I2C and SPI connection names. A couple of pins are useful for timer-based input/output capabilities; for instance, one could use them for attaching a rotary encoder. As a simple user interface, the circuit has a single button (SW3) and a couple of LEDs attached to GPIO pins; it’s up to the user to write code to make use of that button and the LEDs.

There is a 5-pin header, J5, that can be used to attach a traditional SWD JTAG programmer device if required.

The BSL_RX and BSL_TX connections are used for uploading firmware via serial. To enable this, there is a BSL_BOOT button that needs to be held down during a reset. There are some non-populated resistor pads attached to the BSL_BOOT switch, because I’m unsure if that pin floats, or if the user may wish to permanently set that to a particular level.

image

Note: It was later discovered that this Rev 1 circuit is missing a 47k pull-up resistor, from the *RST pin (pin 6 on the microcontroller) to +3.3V. It was easy to patch onto the underside of the PCB.

image

2. USB UART

Since I was keen to use the serial bootloader, the dev-board contains a USB-UART adapter. It’s based around a CH340K USB-UART chip, which I’ve never used before. The chip is a little unusual in that it uses pull-up resistors on the UART side if the chip is powered from 5V and not from the (lower) microcontroller voltage; that’s the reason for R16 on the right side of the circuit (R18 is not fitted, otherwise the microcontroller will always start in bootloader mode!). After some discussion with   it's likely R16 is not needed, so it could potentially be removed (depending on if the RX pin is floating or not on the microcontroller). The microcontroller reset pin is wired through a jumper on J3 to the RTS line, in case it is possible to automatically reset the board from the PC (if you're using the official TI app, UniFlash, then it's not possible, and the jumper needs to be removed). You would still need to manually press the BSL_BOOT button (although, if the microcontroller is new from the factory with the Flash erased, then for that first time the BSL_BOOT button doesn’t need to be pressed).

The pin headers labelled J3 are used with shorting jumpers to redirect the USB-UART from the BSL pins to alternative pins for UART0. This is so that the same USB-UART can be used for general program serial input/output, too.

image

3. Voltage Regulator

The final bit of circuitry is a 3.3V regulator, which can be powered either by the USB connection or from a 5V labelled connection that is exposed on the GPIO pin headers. The two shorting jumpers can be used to separate the power to the microcontroller portion of the circuitry from the rest of the board. By removing the shorting jumpers, you could wire in a separate power supply if desired, or attach current measurement circuitry.

image

Circuit Board

An approximate render of the circuit board is shown below; it is about 60 x 40 mm.

image

Underside:

image

Building and Running an Example Project

All the steps are described at the README file in the easyL1105 GitHub repository. Scroll down to the Example Project section to see the detail. By following the steps there, it is possible to build using either Keil or with GCC. The Keil steps were tested with Windows. GCC was tested with Windows and Linux.

The steps to use TI's UniFlash tool, for uploading the built .hex firmware file to the board, are also described at the same location.

Summary

TI’s MSPM0 L-series microcontrollers offer low-power and low-cost, and a simple development board was created for the 28-pin L1105 part (32 kByte Flash and 4 kByte RAM). The dev-board brings out most of the connections on the microcontroller, and also allows the testing of the serial bootloader capability of the chip, so that it can be programmed in the field, by connecting to a PC without any programmer hardware required.

The KiCad files and PCB files for sending to any PCB manufacturer are in the EasyL1105 GitHub repository. Although the board has not been tested yet (Edit: it has now been assembled and tried out. See the comments below for information about how to use the board). If you give it a go, it would be interesting to hear any feedback.

Also, if you have any ideas/uses for such a board or a similar one, it would be great to hear about them.

Thanks for reading.

  • This is the 16-pin variant (I'm not using this currently, I'm using the 28-pin version). It's tiny.. photographed next to a SOT-23 part. No TI microcontroller in this series has a pin pitch larger than 0.5 mm unfortunately. But it's still feasible with hand-soldering.

    image

  • in reply to shabaz

    (Now added the steps for Linux with GCC too, at the same repository link).

    So far so good, this is a lot smoother than using TI CCS, and since a normal makefile is used (I'd like to eventually use cmake) any desired editor/IDE can be used, from both Windows and Linux. 

  • I've placed a starter project at the GitHub repository, here: https://github.com/shabaz123/easyL1105/tree/main/MyStarterProject 

    The instructions are in there for how to set up a PC for either Keil or GCC, and how to then build the code.

    If you end up giving it a go, please let me know if there are any problems in the instructions, since I've only tested briefly on my PC. I have not tested Linux nor Mac so far, just Windows. The instructions don't currently explain how to upload the firmware to the device, since I've not tried that yet.

  • Finally got both Keil and ARM GCC builds working! I'll stick the files on GitHub. Of course, I have no way of running this on real hardware currently (still waiting for the PCBs).

    Anyway, I decided to get some AI opinions from the output (obviously, the difference should be large, because they are two completely different compilers) - I misspelt ARM but it didn't seem to mind:

    image

    Here’s a tight, practical diff of your two HEX images:

    Big picture

    • Address coverage

      • Keil: 0x00000000–0x00000287 (648 bytes)

      • GCC: 0x00000000–0x00000257 (600 bytes)

      • ⇒ Keil is +48 bytes longer, all of it at the end (0x0258–0x0287).

    • Overlap comparison (0x00000000–0x00000257, 600 bytes)

      • Identical bytes: 185 (30.8%), of which 162 are zeros (mostly the reserved vector slots).

      • Different bytes: 415 (69.2%).

    Where the differences cluster (top blocks)

    • 0x014F–0x01CB (125 bytes)

    • 0x00C0–0x0105 (70 bytes)

    • 0x011B–0x014D (51 bytes)

    • 0x020D–0x0239 (45 bytes)

    • 0x01D8–0x01F7 (32 bytes)

    • Tail present only in Keil: 0x0258–0x0287 (48 bytes, non-zero in Keil; all zeros in GCC)

    Vector table & reset/ISR entries

    • Initial SP (word 0): both 0x20001000 (same).

    • Reset & ISRs (words 1–…):

      • Keil uses several distinct handler addresses: 0x014D, 0x0151, 0x0153, 0x0155, 0x0157, 0x0159, 0x015B…

      • GCC mostly points many vectors to a single default handler: 0x0161 (with reset at 0x0165).

      • This is typical: GCC’s startup often routes many interrupts to one Default_Handler, whereas Keil emits separate weak stubs or a different layout—hence the early vector differences.

    Record/format differences (metadata)

    • Keil includes:

      • Extended Linear Address record (type 04).

      • Start Linear Address record (type 05) with value 0x000000C1.

    • GCC includes:

      • Start Segment Address record (type 03).

      • No extended linear address records (everything lives in the low 64 KB here).

    • These record-type differences are formatting/metadata and don’t materially change what gets programmed for a Cortex-M device given these addresses.

    Checksums (of the mapped image bytes)

    • Keil (648 B): CRC32 AB7B ADCE, MD5 2bd74a31947158c7b1ae4ae4140bd0d5

    • GCC (600 B): CRC32 4D05 AF30, MD5 ec25dbbc69cafbb1fde5267dd8b5dfd2

    In short: the GCC build is smaller (no final 48-byte block) and centralizes many interrupt vectors to a common handler; Keil’s image is larger with distinct ISR stubs and extra tail data/code. Most of the overlapping region differs (≈69%), with identical bytes largely being the zero-filled gaps in the vector table.

    If you want, I can also produce a per-address CSV or a heatmap of differences.

    (yes please!)

    image

    The heatmap looks about right (I only checked the first row or so). Anyway, the next question response was more interesting:

    image

    Here’s a focused compare of the Cortex-M0+ vector table in your two HEX images (MSPM0L1105).

    High-level differences

    • Initial SP (word 0): both 0x20001000 — identical.

    • Reset (word 1): Keil 0x0000014D vs GCC 0x00000165 — different entry points.

    • Default handler fan-out

      • GCC routes most exceptions/IRQs to a single stub at 0x00000161 (Default_Handler).

      • Keil uses small distinct weak stubs for core exceptions (NMI 0x151, HardFault 0x153, SVCall 0x155, PendSV 0x157, SysTick 0x159) and a shared IRQ stub at 0x0000015B for most device IRQs.

    • Reserved/unused slots are 0x00000000 in both images.

    • Device IRQ map (for MSPM0L1105 the used NVIC lines are 0,1,2,4,9,13,15,16,18,20,24,25,31). Texas Instruments

    image
    TL;DR

    • Both images share the same MSP (stack pointer) and zeros in reserved slots.

    • GCC concentrates almost everything at 0x00000161 (one default stub).

    • Keil uses 0x0000015B for most IRQs but distinct stubs for core exceptions; Reset vectors differ (0x14D vs 0x165).

    • All device-relevant IRQ entries differ (point to their toolchain’s default stub) except I2C1 (IRQ25), which is zero in both—meaning no handler is installed for that line in either image. Texas Instruments

    Final question (this is related to the actual hex files):

    image

    Short answer: it doesn’t have to match—and in your Keil image it’s intentionally different.

    On Cortex-M, the CPU ignores the Intel-HEX “Start Linear Address” (type 05) when it boots. It instead:

    1. loads MSP from 0x00000000, then

    2. loads PC from the Reset vector at 0x00000004 (which must have bit0=1 for Thumb).

    In your Keil HEX, the Reset vector contains 0x0000014D. At that address the code is just a tiny trampoline that immediately jumps to 0x000000C1—and that 0x000000C1 is exactly what Keil writes into the type 05 record.

    Proof from the bytes:

    • At 0x0000014C: 48 06 47 00 → LDR r0, [PC, #24]; BX r0

    • At 0x00000168 (the literal it loads): C1 00 00 00 → 0x000000C1
      So the Reset handler at 0x014C/0x014D loads 0xC1 and branches there. The code at 0x000000C0/0xC1 is the real C runtime entry (Keil’s __main-style start).

    Why Keil does this

    • Keil uses the Start Linear Address to advertise the program’s entry point (__main/runtime start), not the Reset vector address.

    • Many flash tools and debuggers ignore type 05 for Cortex-M anyway; the hardware always uses the vector table.

    So your HEX is consistent:

    • Vector table Reset → 0x014D (trampoline)

    • Start Linear Address (type 05) → 0x000000C1 (actual runtime entry)
      No problem here.

    I think I now understand the generated output sufficiently enough to be able to write a converter to send that over serial in the required BSL format, although it might be some weeks before I get around to that.

  • in reply to shabaz

    I was wondering if it was hard coded.

    The AT parts do have some support for bootloaders, like re-assignable interrupt vectors and limited ability to define memory spaces (boot, app, and non-app).  The reset vector can be forced to the boot space, allowing the boot to run or simply invoke the app.