• Reset: Electrical Engineering from the Front Lines

    Thursday, February 13, 2014

    2/13/2014— Eric Kolker

    Hey Tesselators, Eric here.

    As many of you have heard by now, we found a problem with the main Tessel board about a week ago related to how quickly different parts of the board turn on (we’re talking microsecond timing here). We’re hard at work gathering data about the existing system and testing out possible fixes.

    The “reset issue”

    When I started this post on Friday (after one or two days of data collection but before parts had arrived from DigiKey), we were pretty sure that the SPIFI flash chip’s boot time was to blame for the behavior we were seeing. The theory was that the LPC1830 (our main processor) was trying to communicate with the flash chip, which contains all user code, before the flash was ready. Because the flash was unresponsive, the code entered a 60-second countdown after which the LPC reset itself and tried again. Since the flash had stabilized by this point, the Tessel would boot normally and detect as a USB device in “application mode.” Translation: Tessel would work after it sat untouched for a minute, but not immediately after being plugged in.

    The easiest way to cut through the ridiculous 60-second timer was simply to hit the reset button on the board, which resets the LPC, thereby restarting the boot sequence. Assuming you hit the button more than about 300 microseconds after the board is plugged in (the time it takes the flash to init), the Tessel would boot properly and become usable. We decided, though, that the need for user intervention was unacceptable (read: not shippable), so we’ve been looking into other ways to make the Tessel reset immediately after being plugged in.

    Fast forward a few days and we’ve found that the flash is definitely to blame. For a variety of reasons (hysteresis, indeterminate state inside an IC during power up, etc.), we believe that the best way to fix this issue is to add a rest control chip to the board. All that this chip does is keep the LPC’s reset line asserted for a few milliseconds after the board is powered, thereby eliminating the need for the user to hit the reset button (although this may sound like a hack, trust me that this technique is very common).

    Pull resistors

    However, one additional change is also required in order to guarantee that the reset chip does the trick. Some of the lines the LPC uses to talk to the RAM (not the flash) can serve the dual purpose of controlling how the LPC boots. More specifically, when the LPC is in its default boot-mode configuration, these lines control what software runs when the LPC boots, a feature which we’ve been exploiting to make it easy to update the firmware on Tessel. This also makes the Tessel unbrickable, which is a really nice feature.

    In order to make use of the versatility of the default configuration, we have resistors on some of the boot lines to configure them to boot from flash and actually break out others to through hole test points. This allows us to switch between “normal” boot and DFU mode (“device firmware update” — a class of USB device that lets us do the firmware update) without permanently configuring the LPC one way or another. That is to say, this keeps it flexible and allows us to physically select the boot mode.

    However, the LPC also has internal resistors on these lines which are controlled programmatically. The trouble is, these resistors are not configured properly as the device is booting up (their control circuitry is turning on at the same time). Pair this with the fact that the internal resistors typically fight (pull in the opposite direction from) the external ones, and the device may inadvertently boot into an undesirable state from which it may or may not be able to recover without an external reset event.

    We have gotten good results with a workaround which involves removing the external resistors (which has the added bonus of allowing us to increase the clock rate for the entire board), but this requires that we permanently configure the LPC to boot into flash, as opposed to keeping the boot options open/configurable in hardware.

    The last piece of the puzzle is a bootloader that will live in a quasi-reserved section of the flash to ensure that the Tessel remains unbrickable (unless you try to load your own firmware…without using our tools, which will refuse to write to the restricted zones). I should also clarify that the Tessel can always be recovered using a JTAG programmer (so in this case “bricked” really means “you can’t get Tessel working again without a hardware debugger”), but that we don’t ever want to force you to use anything outside of USB and WiFi to program Tessel.

    What else is new

    We’d like to take this opportunity to tweak our power input stage. We’re looking to move from a low dropout regulator (a subset of linear regulators) to a switching regulator because it will give us more current available on the 3.3 V rail. A part swap may also allow us to increase our maximum input voltage (for powering the Tessel from an external battery/supply).

    A switching regulator would allow us to draw more current from the 3.3 V rail. The two families of voltage regulators (linear and switching) differ in how they deal with the power available to them. Linear regulators, for a given output voltage and load current (P = IV), burn any excess power by dissipating it as heat. In other words, for a given regulated voltage Vout:

    As you can see, these regulators dissipate the power that comes from “extra” voltage as heat, and are poor choices when there’s a large difference between the input and output voltages.

    Switching regulators, however, conserve power from input to output and can therefore provide a higher output current at a lower output voltage (or a lower current at a higher voltage):

    Here’s to physics! (NOTE: no process is 100% efficient, so we’ll always get less than the theoretical maximum.)

    In our case, dropping from 5 V USB 2.0 down to 3.3 V allows us to get ~750 mA out (in theory). The absolute maximum is, at that point, governed by the rating of the regulator, so as much as ~1.8 A might be possible with 12 V in.

    While we’re on the subject of input voltage, right now the Tessel can be powered from a maximum of 5.5 V, which is fine for USB and single cell LiPos. We’d be looking to move to a system that gets us up to 12 V in, which would let the Tessel run off of two-cell LiPos, 6/12 V sealed lead acid (SLA) batteries, and even everyday 9 V batteries. We’re in the midst of testing parts and propagating the necessary changes to the rest of Tessel, and should have a new design by the end of next week.

    Changes wrap-up/most recent state

    We’ve found a switching regulator we like, a reset controller, and have parts in the mail for a power multiplexer (one of those changes that needed propagating). We need to test everything together, update the design files, and then place an order. We continue to live in interesting times…

    The original post - or - “Eric, your handwriting is terrible”

    Finally, I leave you with the contents of my lab notebook, complete with the scope data I took as a way of showing you what the hardware debugging process can look like sometimes. Fair warning, what follows was copied verbatim from my notebook, so it’s dense, cryptic, and a lot of the supporting information elsewhere in my notes. The general pattern it follows is:

    • graph description/experimental setup
    • graph
    • notes/comments/musings on the most recent graph

    If you’d like to try your hand at interpreting the graphs, keep the following things in mind:

    • I only had a 2-channel scope; if I had had a larger one, many of these graphs would have been combined
    • Timing is important. Be sure to look at the values on the x axis.
    • Conditions inside an IC (voltages, memory state, etc.) are highly unpredictable during boot-up, so we can’t know what’s going on inside our chips until they tell us that they’re ready. This is why it’s important to turn things on in the right order.
    • On a related note, hysteresis exists in many of these chips

    Finally, as a refresher, we’re looking into an issue which we believe has its roots in when different chips on the Tessel turn on after the Tessel is plugged in. I’m measuring voltages.

    Enjoy, noodle, and hit me with questions.

    From my notebook

    Want to diagnose boot behavior…

    ch1 - 3.3V
    ch2 - reset
    1V/div, 200us/div

    w/ reset button
    1 - 3.3V 2- reset

    ch1 - DFU
    ch2 - reset
    1V, 400us

    1 - DFU
    2 - reset
    1V, 10s

    chip did not come alive
    reset chip to blame?

    chip power disconnected
    run it again!

    board instantly came alive on 3.3V wire cut to reset controller. …what?

    05 DFU/reset 1V, 200us

    06 3.3V/reset 1V/200us

    60 second timeout is definitely not working
    hypothesis: it is hysteresis. Cap time
    added 1uF to reset
    still no 60s boot…
    but the button works…
    button on power plug does not work.
    repeated plugging in rapid succession also doesn’t work…
    ~3s delay before button push works edit: no, it doesn’t
    long wait be
    plug + reset + 3s delay to lift works

    with or without the cap, plugging in + arbitrary delay + reset button works

    07 DFU/reset 1V, 100ms

    [ NOTE: data file unreadable and data omitted for CH1 (DFU) ]

    1uF cap button push after plug

    08 no cap, same as above


    …for using Excel. My D3-fu is weak but, frankly, I really just miss MATLAB right about now.



    #eric kolker #technical machine #tessel #setback #electrical engineering #nxp #debugging #startup

  • Potential Hardware Delay, Software Making Progress

    Monday, February 10, 2014

    2/102014— Updates

    It’s been snowing like crazy here in Boston, but we’re warm, indoors, and hacking away on Tessel and its modules.

    Last Friday we had one of the roughest days of our company’s relatively short existence. We discovered a bug in our hardware design just days before we were going to give our assembly house the go-ahead to start assembling all 1450 Tessel PCBs that were manufactured. The bug caused Tessel to hang each time it was plugged into USB, necessitating a push of the reset button to be able to use it.

    A Bug on the Hardware

    The tough part for us as engineers, was that we had known about this bug since July, but had diagnosed it as a minor “software issue” during several independent investigations. The root cause is a race condition between the bootup of the NXP chip (the main microcontroller) and the external flash chip. Our hardware debuggers attach to the reset pin of the Tessel, so we were changing the behavior during debugging.

    The microcontroller powers up around 100 to 200 microseconds before the flash chip, which contains the firmware. The NXP boot code (in read-only memory) checks for the firmware in flash, doesn’t find it, then only checks again 60 seconds later. We’re not the only crowdfunding team to hit NXP’s bug, and it’s not something we’re comfortable shipping out to our users.

    There is not an insurmountable problem, it’s just a matter of reconciling the consequences. Here are our options:

    Solutions and Consequences

    1. NXP has documented that they fixed the “60 second bug” on their recently manufactured Cortex M4 series chips. We’re currently trying to get in touch with someone at NXP who knows if it was fixed for the M3 series as well. If this turns out to be true, we’ll just need to make sure we have those newer chips, then we can still use the same PCB. This is the most ideal situation as our shipping schedule will likely stay the same. That being said, the current chips we have were all manufactured in the last weeks of 2013, so it is unlikely there would be newer chips with this bug fixed.

    2. We could add a reset controller to our main board, which will allow us to delay the propagation of the reset signal to the microcontroller, thereby eliminating the race condition. This will require another board revision, but allows for minimal changes to Tessel’s functionality and has the silver lining of allowing us to make a handful of incremental improvements to Tessel including making USB more robust and picking a better voltage regulator. This our most likely solution and will push our shipping schedule back to late March or early April.

    We’re still learning how to create a sustainable hardware company, and this issue was a real eye opener in terms of much more time and energy we need to dedicate towards testing prior to getting products ready for shipping. We have a lot of pressure on us to ship to you, our backers, as close to the date we expected as possible, but quality is more important to us than schedule.

    While we honestly can’t think of anything we could have done differently to avoid this specific bug (besides fix every existing software and hardware issue), we’re taking several steps to ensure the quality of our hardware and software in the future. Specifically, we’ve set up a continuous integration rig to automatically run any new firmware on every version of Tessel prior to consolidating into the rest of our code base. We’ll soon be setting up continuous integration rigs for all of our modules as well.


    But we do also have good news! We’ve been making progress on several items recently:

    • We’re able to write JS programs to flash so that they will run as soon as Tessel is powered up.
    • We’ve fixed over 50 firmware bugs reported by our beta backers.
    • We’ve been interviewing folks for various positions within the company (want to be an intern or a full-time employee? We’re looking for engineers and designers.).
    • We’ve finished the Infrared Module hardware, driver, firmware, and testbench.
    • We’ve done a major overhaul of the Audio Module. Here’s the latest prototype:

    We now support headphones and line-out and, more importantly, the module can now record audio through an onboard microphone or a line-in jack.

    We’ll keep you updated over email as things progress.


    Kelsey, Jia, Eric, Tim, Kevin, and Jon

    #Tessel #Update #Technical Machine #NXP #bug #startup #setback #progress #hardware #hardware is hard

  • How to Write a Press Release

    Thursday, January 30, 2014

    1/30/2014— Kelsey Breseman

    Back in November, when we closed our seed round with True and others, it was a topic of some internal debate whether we should look for press coverage on the raise. On one hand, we wanted to share our excitement with our supporters, and it’s not that often you have news that interests an actual publication. On the other hand, news of a raise is honestly not that interesting most of the time. It meant a lot to us, but talking about it outside of the team is really close to bragging.

    One of the reasons we did decide to release the information across various news sources was to practice sending out a press release. It’s not as simple as it sounds.

    Press releases are extremely formulaic, concise ways to send pre-vetted information to several reporters at once.

    A press release looks about like this:

    Company Name

    (maybe your logo in or around this space)
    Contact Name (just one primary contact is best here)
    phone (swap email and phone number if you prefer to communicate by phone)

    PRESS RELEASE: Your Catchy Headline Here

    EMBARGO until Date Time Timezone

    City, State, Date to be released— First paragraph of release. The meat of your announcement, in as few words as possible.

    Second paragraph. Explain the point of your company/product/whatever you’re announcing. Still keep it brief.

    Third paragraph. Quote from your CEO or whomever is most relevant to the announcement.

    Fourth paragraph. Quote from someone outside the company. In our case, a quote from one of our new VCs.

    Possibly mention a few salient traction metrics here. I’ve received conflicting advice on whether to include coverage by other media outlets; some reporters might recognize you as a vetted company, while others might be turned off if you seem like old news.

    Where to find more information about your company/project/whatever. Particularly, link to your website and a place they can find relevant images.

    More information, in smaller text, if relevant. We included labeled paragraphs “About Technical Machine” and “About Technical Machine’s Investors”.

    More notes on the press release:

    Headlines should be very specific. Ours was “Technical Machine Raises $1M to Make Hardware Development Tools for Software Developers”.

    The press release should be concise, but contain all vital information. Organize it clearly and fact-check it.

    Sometimes, reporters will copy/paste from your press release, so make sure the writing is suitable for publication.

    Note that you’ll want a quote from someone outside the company, so it might take a little time to finish the release. Plan ahead!

    Before the press release– contacting reporters:

    If you are releasing to multiple reporters, you’ll want to set an embargo. The date and time of the embargo is the exact time at which you’re allowing reporters to release their articles containing information from the press release. We set ours for a Wednesday at 11am EST, because Wednesday is a low-press day (so we might stand out as more interesting), and because we see the most engagement from our users around 11am EST (8am PST).

    You’ll want to contact reporters approximately one week ahead of the embargo time. Initiate contact with an email that does not contain the press release, but does contain the headline and embargo date. Actually, let me give you an

    Email template:

    Subj: Your Catchy Headline Here UNDER EMBARGO UNTIL Date Time Timezone

    One sentence that gets the reporter excited but doesn’t give away any details (mostly just your headline restated).

    Something along the lines of: I can send you the press release under embargo (until Date Time Timezone), and I’m free to speak with you over the phone (Times & Dates, ~two of them, a day or two before the embargo is lifted) for a pre-briefing.

    That’s it!

    Our press release had success with GigaOm and the Boston Business Journal, two out of the five media outlets I had emailed about the raise (all five had previously written about or been in contact with Technical Machine). We also sent the press release to our investors True Ventures and Rough Draft Ventures, who supported the release by publishing related blog posts on the same day.

    The news was then picked up by Startup Beat, Crowdfund Insider, the San Francisco Business Times, and Xconomy Boston.

    In the end, I’m glad we sought press on the raise. Our families, friends, and supporters were enthusiastic; we had good exposure on the raise; and now I know how to release any further announcements to media outlets.

    I hope this is useful! Please let me know if you have any questions.



    #tessel #technical machine #kelsey breseman #marketing #press release #startup #fundraising #venture capital #PR #PR tips #public relations #media relations #reporters

  • GPRS (2G) Module

    Monday, January 27, 2014

    1/27/2014— Eric Kolker


    Hey Tesselators, Eric here.

    The GPRS module has been both a ton of fun to work on and prompted its fair share of headaches, so strap in: this post will feel a lot like the one I wrote a while back about debugging the RFID module.

    What’s that acronym?

    No shame, I had to Google it too. GPRS stands for “General Packet Radio Service,” but most people know it as a GSM (“2G”, if you will) cell connection. Devices with a GPRS radio can interact with the outside world via SMS, voice calls, and even TCP/IP. Besides enabling you to essentially build your own phone with a Tessel, the GPRS module keeps the Tessel connected outside the range of WiFi. It’s one of the Class B modules we added as a stretch goal during our crowdfunding campaign on Dragon Innovation.

    As with many of our modules, we borrowed much of the design of the GPRS module from an open source product sold by Seeed Studio. The first task, as usual, was to adapt the Arduino shield so it would play nicely with a Tessel. The biggest difference we had to overcome here had to do with the power requirements of the different components.

    Power work is never over

    Most devices you run into these days are either 5V or 3.3V. For instance, Tessel is a 3.3V device, most Arduinos are 5V devices, the RaspberryPi is a 3.3V device, etc. Taking a step back, when I say that something is an x V device, that usually means that it takes x V between its power in and ground to turn the thing on and that all of its I/O pins can tolerate a maximum of x V. In other words, if you don’t give it a high enough voltage on its power pins it likely won’t turn on (I/O may still work when driven at a lower voltage,, but check the datasheet and look for the term “logic high”), but if the voltages are too high then you run the risk of destroying the chip, or, in EE jargon, “letting out its magic smoke.”

    The chip at the center of the GPRS module, the SIM900, however is neither a 3.3V device, nor a 5V device, nor even a 1.8V device. Instead, it’s some weird hybrid of…most of those. In a nutshell:

    • The I/O for the chip is all 2.8V. This means that the pins don’t like anything higher than 2.8V coming in.
    • The chip will run off 3.2V to 4.1V. Anything higher or lower and it will try to protect itself by shutting down. As it turns out, these values play very nicely with LiPo batteries, which typically hover at around 3.6 V.
    • Last but not least, the module generally has a rather high current draw (on the order of 50mA when idle), but behaves more like a sinkhole when transmitting and can draw peak currents of up to 2A.

    The reason the last two bullet points are so important has to do with conservation of power (summarized poorly here). In so many words, the basic idea is that some devices, when pushed beyond their limit, will conserve power (in this case, P=IV) before they give up completely and shut down. In the context of the GPRS module, this means that when we transmit and the module’s current draw spikes, the voltage drops. SIMCOM, the part’s manufacturer, knows that this will happen; the graph below is from the datasheet:

    This is chart tells us a few things:

    • If the power supply rail for the GPRS drops below 3.2 V, even for some very short amount of time, then the module turns itself off.
    • If the total drop in voltage is more than 300 mV, then the module turns itself off.
    • We should expect peak current draw up to 2 A.

    If we’re running the GPRS module off the Tessel’s 3.3 V rail, then we only have 100 mV of wiggle room before the module shuts down.

    Bathtubs 101

    Before we go any further, here’s quick refresher on the E&M for capacitors, mostly in layman’s terms/in the context of household plumbing:

    • When electrons hang out on a node (the place where two or more electrical components meet), we say that charge has accumulated on that node. Charge has units of Coulombs ©, but is denoted with a “Q”. If you like, you can think of charge as a number of liters/gallons of water at a particular point.
    • Current, which is measured in Amperes (A) (or, equivalently Coulombs per second) but denoted with an “I”, is the flow of electric charge from one node to another through a component. You can think of it as the flow rate of water through a pipe.
    • Voltage, measured in Volts (V), is the difference in electric potential between two nodes, or the capacity of charge at a node to do useful work. Think of it as water pressure.
    • Capacitance, which has units of Farads (F), is the ability of a body to store electrical charge. Capacitors are the components we use when we want capacitance between two nodes. Within the hydraulic analogy, they behave like tanks with a stretchy, impermeable membrane down the middle.

    When a capacitor charges or discharges, it follows the formula:

    In English: current flow into a capacitor as a function of time is equal to the size of the capacitor multiplied by rate of change of the voltage across the capacitor with time.

    Where were we?

    Recall that we’re trying to be able to survive the theoretical worst-case scenario: a 577 microsecond, 2 A pulse, with a voltage drop less than 0.1 V. At first pass, a likely easy solution might be to simply add more capacitance to the power rail. We know I(t) and can calculate dV(t)/dt, so we can solve for the lower bound of acceptable capacitances:

    As it happens, a capacitor that size would have a lot in common with a T-Rex: it would be enormous, completely impractical, and ugly…not to mention hard to find and expensive to purchase. There must be a better way.


    The best answer turns out to be 4-12 V of external power and a buck converter that turns the supplied voltage into a ~3.5 V rail for the SIM 900, instead of enormous capacitors. Buck converters are a subset of switching converters, which harness the properties of inductors, diodes, transistors, and capacitors to generate a higher or lower voltage.

    The buck regulator we threw on is good for 3 A and ~4 - 12 V in. The datasheet is here, if you’re curious.

    Alright. It’s time to stop talking about woes of EE land and show you the fruits of our labor! The modules for our Beta backers look like this (without headers or the antenna):

    And, of course, proof that this thing works:

    That’s me on the Tessel phone: a Tessel + GPRS module hooked up to my laptop sending me texts, receiving my texts, and making/receiving phone calls. It was a good day at the office.

    If you want to see (or hear) for yourself, send me an email with your number (US only, please) and a project you’d like to build with Tessel. I have a batch of 16 boards to test this morning; might as well make use of them.




    #tessel #technical machine #eric kolker #gprs #2g #electrical engineering #phone calls #tesselphone #tessel phone #tessel texts

  • Updates: Manufacturing and Testing

    Wednesday, January 22, 2014

    1/22/2014— Updates


    We got a batch of 50 Tessels from our manufacturer this week. We will test them before we give the go-ahead to start on the rest of the production run.


    It is taking us longer than anticipated to finish up the test rigs and send the rest of the 5 modules into manufacturing. Unfortunately, this delay runs into the Chinese New Year, so our manufacturer will be taking the next week off. This will probably delay delivery beyond the amount mentioned in our last email. We’ll let everyone know by exactly how long when we get dates from our manufacturer.


    Our BLE module is a system on a chip (SoC) that runs its own firmware, separate from Tessel. We were able to write a programmer for it so that Tessel will be able to update it without a proprietary debugger. This means you will be able to select different Bluetooth Profiles to load onto the module. If you have a Windows machine, you’ll even be able to completely customize your profile with BlueGiga’s development tools (look out for a tutorial on that topic!).


    We did another revision of the GPRS board to make it a bit smaller. Here it is sending us a text message:


    A few months ago we announced that we were splitting IR from the rest of the ambient module. The change took us longer than anticipated, but here’s the new IR module:

    And here’s Jon testing it with a tv remote. Earlier, he tested from across our shared coworking space– a distance of probably around 30 ft.

    Upcoming Events

    • 1/27 Cambridge, MA– Kelsey is speaking at Rough Draft Ventures’ sketch “Women in Technology, Now and Next”. Free tickets.
    • 1/28 Cambridge, MA– Tim is speaking at Cambridge Hackspace’s “Hacking your idea into a business”. Meetup link.
    • 5/28-30 Amelia Island, FL– Some or all of us will definitely be at JSConf. Tickets.

    One more thing…

    We were nominated for Postscapes’ Internet of Things awards– we’d appreciate if you’d vote for us!

    Here’s to our final push,

    Kelsey, Eric, Jia, Tim, Jon & Kevin

    #tessel #technical machine #updates #modules #infrared #gprs #text from tessel #bluetooth #ble #production #manufacturing #testing #update

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013