29

While looking for some detailing on part number construction for Texas Instruments's MSP430 series, I came across this wiki page: TI MSP430

There is a statement,

"L" as in the MSP430L09x series, which indicates a RAM-only part; it must remain continuously powered to retain its programming

While I haven't able to validate the above after going through the datasheet on the official website, the question that bumps me is, if at all there is one such part, what could be the appropriate application to use it?

WedaPashi
  • 1,670
  • 17
  • 29
  • 16
    Maybe a peripheral where the program is always uploaded from the host at power on? – Jack B Dec 18 '17 at 11:10
  • 2
    Indeed a valid point, but what real-life application do we see that does it this way? – WedaPashi Dec 18 '17 at 11:14
  • 12
    All FPGAs do this. It probably also has the benefit that RAM is faster to read from and write to than Flash. But beyond that I can only speculate. – Tom Carpenter Dec 18 '17 at 11:17
  • 2
    I used the ADSP-21xx parts, which were RAM-only. They included a boot process on power-up where they could fill that memory from an external EEPROM, for example. I haven't looked at the part you are discussing, though. So I can't tell you about its case. But that's the kind of thing I'd look for. – jonk Dec 18 '17 at 11:18
  • 8
    Some types of secure applications may want to "burn after reading" - think locks or bank security tokens. –  Dec 18 '17 at 11:20
  • The freescale DSPs I used were RAM only and had a bootloader similar to what @jonk describes, but got their program code via SPI. – Colin Dec 18 '17 at 11:20
  • Yes, the datasheet links to a loader: http://www.ti.com/lit/ug/slau324/slau324.pdf and references this as being for "development". – pjc50 Dec 18 '17 at 11:27
  • An example of the "secure application": old arcade machines had self-destructing code tied to a backup battery to impair copying of the software. https://hackaday.com/2016/09/15/desuiciding-capcom-arcade-boards/ – pjc50 Dec 18 '17 at 11:29
  • Thank you all, I didn't have an insight on how it could be used. I'll read further! – WedaPashi Dec 18 '17 at 11:59
  • 1
    This could be a related case. I've seen PCI card designs which had an FPGA which didn't store its own firmware. There was no Flash memory on the PCI card. The host CPU downloaded the firmware into the FPGA from the hard drive. – Nick Alexeev Dec 18 '17 at 18:41
  • 1
    @TomCarpenter - I'm pretty sure FPGAs are RAM-based because the lithography process used to make them either can't make flash, or can't make flash inexpensively. – Connor Wolf Dec 19 '17 at 06:01
  • @ConnorWolf CPLDs are flash based. Albeit they have fewer gates. – Tom Carpenter Dec 19 '17 at 08:01
  • 1
    @NickAlexeev That's a reasonable design for a PCI card that always has a host, though. (At least until Linux kernel developers run into your legal team) – user253751 Dec 19 '17 at 08:40
  • @BrianDrummond: or "burn after tampering". Quite a few anti tempering mechanisms are based on that. – PlasmaHH Dec 19 '17 at 10:14
  • @immibis sounds like you have a particular story in mind there. Anything you can share? IIRC, nvidia graphics cards work that way too. – Baldrickk Dec 19 '17 at 11:12
  • @Baldrickk Just about all moderately complex hardware actually. Network controllers and graphics cards seem to be particularly bad, but have a look at all the stuff included in linux-firmware. Those are all firmware "blobs" (files) needed by Linux drivers... some were contributed voluntarily by the hardware companies, some probably had to be cajoled out of them, and quite possibly some are there illegally (but the company is out of business or just isn't bothered to sue). – user253751 Dec 20 '17 at 09:39
  • @immibis I hadn't realised that it was so common. I thought that the usual process for firmware on PCI cards was to store it, and a new 'blob' would only be transfered for a firmware update. At least, when I last checked (which would be a while ago) AMD(ATI?) cards had installed firmware, while nvidia cards had a bootloader and not much else, relying on a blob being uploaded each boot. – Baldrickk Dec 20 '17 at 11:06

2 Answers2

45

The point of the "L" series is to support very low supply voltages (0.9 V; what you'd get from a single battery cell); the web page says:

Typical applications for this device include single-cell systems requiring a full analog signal chain.

The missing flash is not a goal; it's an unfortunate side effect of the voltage range. Chapter 8 of the User's Guide says:

This chapter describes how the MSP430L092 loader code is used to build an autonomous microcontroller solution. The loader approach is chosen as nonvolatile memory is not available for native ultra-low supply voltages.

You are supposed to ask TI to create a chip with your code in ROM (this is what the "C" series is for). However, during development (when you do not yet know what goes into the ROM), or when you do not have many devices (so the fixed ROM overhead would be too expensive), you have to use an "L" chip without ROM:

MSP430x09x debugging scenarios

CL.
  • 19,292
  • 5
  • 42
  • 68
14

Many PC-connected devices are build without a ROM, since they can be easily programmed by the host. For instance, all WiFi modules I have seen are programmed by their driver when the said driver is loaded. This saves money on expensive flash-ROM (storage on the PC is much cheaper) and makes firmware updates seamless for the end user.

This concept is not unique to WiFi, but it turned out to be very useful in this case in particular, because many WiFi chipsets are released while the corresponding specification is still in the draft stage, so frequent firmware upgrades are to be expected.

Dmitry Grigoryev
  • 25,816
  • 5
  • 45
  • 107
  • 4
    Also any embedded processor that works alongside other processors. Typically the master processor starts up all the other processors and sends them their code. – David Schwartz Dec 19 '17 at 04:26