Freescale introduces the S12P family

[Steve]

FYI we just announced a new S12 family for cost-sensitive applications.

The announcement is here.

The product page is here.

S12P MCU features

• S12 core, 32 MHz bus
• Up to 128K of on-chip flash with ECC
• Up to 6K RAM
• 4K DataFlash® with ECC
• 1 MSCAN module supporting CAN protocol 2.0 A/B
• 1 SCI supporting LIN communications
• 1 SPI
• 8-channel, 16-bit timer supporting input capture, output compare, counter and pulse accumulator functions
• 10-channel, 12-bit resolution successive analog-to-digital converter (ADC)
• Pulse width modulation (PWM) module with 6 x 8-bit channels
• Phase locked loop (PLL) frequency multiplier with internal filter
• 4-16 MHz amplitude controlled Pierce oscillator
• 1 MHz internal RC oscillator
• Autonomous periodic interrupt (API)

[Lundin]

This MCU pretty much has everything I need: 48-pin, CAN, 12-bit ADC.
But it has no EEPROM.

Are there any plans for S12 devices with the above features that have EEPROM?

I took a look at this "data flash" and it is too slow for my needs, assuming the S12P goes with the same speed as the older S12 devices. With the old S12 devices, the following applies:

A HCS12 running with 20MHz oscillator will get the optimal flash prescaled clock at 192kHz (The flash clock needs to be between 150 and 200kHz to program the flash properly).

A sector erase with a 192kHz clock will take 20.83ms. Writing one word of data will take 2.5us. 256 bytes need to be written, so it will take

20.83ms + (256/2) * 2.5us = 21.15ms

Not counting algorithm execution time with copy down old data to RAM, CRC calculations etc. The CRC has to either be calculated on the whole 256 segment, which will be incredible slow, or on sub-segments, which will be memory inefficient as I would have to store checksums all over the place.

Why must the segments be so big? The EEPROM for the old S12D family would have been so much better than this rather useless data flash. The S08DZ family with its EEPROM is for example perfect for me, but I'm sitting on a lot of assembler code written for HC11/HC12 and would prefer a mcu with a compatible instruction set.

[kef]

Lundin,

On S12C I'm using my own EEPROM emulation. I'm not updating whole flash sectors on every write to EEPROM. I enumerated EEPROMable items (few tens) and am noticing their value in EEPROM "notepad". Dedicated 2 or more flash sectors get filled this way:

<item#word><valueword><item#word><valueword> etc

When sector is full, I not erase old sector immediately but continue writing next fifo sector. After each write I check if free EEPROM space is below or above some threshold (big enough to store all my items + some extra space). When low I don't need to free oldest EEPROM sector immediately (there's still free space available), instead I wipe oldest "notepad" page when appropriate, for example at power on or other times when I can justify >20ms erase lag.

Before erasing oldest sector, it's necessary to provide that there's no items that are recorded only in the oldest sector. Simply all items may be stored again in free space (free space threshold is big enough so there's always enough free space).

At poweron I scan dedicated EEPROM sectors to find oldest nonempty sector and pointer to free words in the sector, then I read all records and initialize my RAM variables from above mentioned item#-itemvalue records (some get initialized tens times, some just once or not at all).

Drawbacks: At least two sectors are necessary. More than 2x space overhead, every word consumes 2 words of flash, every double word - 4words. Every byte - 2 words etc. I can't allocate variables in EEPROM, all NV variables must be allocated in RAM. Maybe quite difficult implementation, maybe more code space is necessary, etc

Advantages: dedicated for EEPROM sectors do wear out uniformly, reduced number of erasures, usually short write times. 

That's just an idea, I think you could create better scheme. And dataflash has at least one advantage, it allows you no keep executing from program flash, you are not pushed to disable interrupts and so on.

Regards

[Lundin]

I did something similar on S12C once, as an experiment. Since the application is a safety-critical one, I must have duplicates of each data, and checksums as well. I am also dealing with a lot of data.

On top of this, I need to write data to NVM memory in runtime, and the application is a time-critical one. I ended up with huge execution time overhead because of the 512 byte large sectors.

On top of that, I needed checksums for the dangerous programming code I had to put in RAM.

My experiment showed that I wouldn't be able to use the flash on HCS12 for fast, real-time applications. That is, the HCS12 flash is unsuitable for the kind of applications the part was designed for: typical automotive applications.

But the worst thing with the S12C and many of the new S12 parts is really not the huge sectors of 256/512 bytes, but the fact you can't run the flash programming code from NVM, you have to run it from RAM. And that is a very questionable method in any application with just a tiny bit of safety requirements. You can certainly not do that in safety-critical/automotive applications. -Especially- not such sensitive code as a NVM programming algorithm that has the potential to give your program completely random behavior if failing.

On the S12D family parts with more than 64k of flash you can use one bank of the flash to program data in the other. On the newer S12 parts I don't think you can't do this, as I believe they have only one single bank and thus only gives you the option to put the NVM code in RAM.

If you aren't doing time-critical, safety-critical or automotive applications, the flash will suffice. But then you have to ask yourself why you are using Freescale and not the cheap hobbyist micros.

[kef]

Duplicates, checksums and a lot of data is not a problem for my implementation, it's just a matter of how many flash sectors you need to allocate.

My aplication is also very time critical.

you wrote:  "On top of that, I needed checksums for the dangerous programming code I had to put in RAM."

Continuig what you said, no code is 100% safe, no matter does it sit in RAM or in ROM. More over you are copying your dangerous code from ROM to RAM.

you wrote: "My experiment showed that I wouldn't be able to use the flash on HCS12 for fast, real-time applications. That is, the HCS12 flash is unsuitable for the kind of applications the part was designed for: typical automotive applications."

Let me ask, was HC11 suitable for fast, real-time applications? HC11 had both, program and erase times close to 10ms, 10+10=20ms. On S12 you have <<100us program and ~20ms erase. Pretty the same. But you point is taken.

you wrote: "But the worst thing with the S12C and many of the new S12 parts is really not the huge sectors of 256/512 bytes, but the fact you can't run the flash programming code from NVM, you have to run it from RAM. And that is a very questionable method in any application with just a tiny bit of safety requirements. "

Agreed. Note also that on S12P you don't have to run dataflash programming routines from RAM.

you wrote: "If you aren't doing time-critical, safety-critical or automotive applications, the flash will suffice. But then you have to ask yourself why you are using Freescale and not the cheap hobbyist micros. "

Time-critical, safety-critical, not automotive, not hobbyist. Do I deserve permission to use Freescale chips? Freescale, because they suit me the best.

[JimDon]

"On top of that, I needed checksums for the dangerous programming code I had to put in RAM."

Huh? What is dangerous about it? Other than how well it is written.
What make you think that any of us will tolerate bugs or crash in out applications?

Or do you still believe that this RAM just magically forgets?

[Lundin]

Avoiding code allocation in RAM is part of defensive programming: to protect the program against unexpected behavior. There are two dangers of unexpected behavior with RAM:

First of all, its volatile nature. If you have code or variables sitting in RAM during longer periods, you cannot trust the values of the variables, unless they are continously refreshed from a ROM source. This will of course depend a lot on the manufacturers implementation of the RAM.

Second, RAM is read/write. Any bugs, stack overflow or unexpected behavior of your program could destroy the code. That isn't possible if the code is allocated in ROM.

[JimDon]

Ludin,
Well, that is interesting, because many embedded systems run entirely from RAM (they copy from slow flash to ram at startup). Also, many critical systems use PCs with and without windows (no rom - all from RAM).


While it is true you could have a bug that over writes ram, that will probably crash the  system or cause incorrect behavior as well, so I am not sure of your distinction. A bug is a bug.

As for the statement:
"you cannot trust the values of the variables, unless they are continuously refreshed from a ROM source."
This means every time you increment a variable it must be written to rom, since you can not trust it's value in rom.

All I can say is a friendly "hogwash". That is pretty unrealistic, and not correct at least in a general sense.
I suppose you might be able to cook up some hypothetical scenario, but in general, just not true.
 

[Lundin]

: Well, that is interesting, because many embedded systems run entirely from RAM (they copy from slow flash to ram at startup). Also, many critical systems use PCs with and without windows (no rom - all from RAM).

Would you fly with an airplane controlled by a PC? Would you buy a car which breaks were controlled by a PC?

RAM is more likely to get corrupted than ROM, because it is a volatile memory. The problem is this: what happens if you get a voltage dip in a RAM cell? Or if the voltage of the RAM cell is leaking? If you know how Freescale, and every other manufacturer have implemented their RAM to ensure that such things are literally impossible, ie if you are bold enough to say that RAM is 100% safe, yes then you could run your systems entirely from RAM.


: "you cannot trust the values of the variables, unless they are continuously refreshed from a ROM source."
This means every time you increment a variable it must be written to rom, since you can not trust it's value in rom.

Every time you write to a RAM cell, its value is refreshed. The RAM circuit itself may or may not do this, depending on the type of RAM. Again, I have no idea how the manufacturer of a certain microcontroller has implemented their RAM.

[JimDon]

"Would you fly with an airplane controlled by a PC? Would you buy a car which breaks were controlled by a PC?"

Well first of all, I was not referring to all pc's. Second, if was not running windows, yes, and finally many safety critical systems are run by PCs using windows running from RAM (for better or fro worse). Not off the shelf "Dells" but none the less PCs running from RAM.

"RAM is more likely to get corrupted than ROM, because it is a volatile memory."

Perhaps this true, but maybe not - just like incorrectly made ram can get corrupted, improperly burned flash can grow back. If things are done correctly, both very unlikely.

Myth busted.

[kef]

Whould you fly or drive anything having ... D-triggers :-)? Also CPU registers are RAM, that refreshed or not, if not reliable, can fail millions of times per second. Yeah, we should be paranoic to some extent, but your technique of refreshing RAM from ROM doesn't really work. In my opinion, provided RAM is not reliable, it's just a matter of time when your system will crash. I think you are doing even worse, because you are reducing (and not eliminating) the risk of crash, making it more hard to catch defective hardware and defective software. It could even pass all your tests but fail in a real life! I think it's well better, as a preventive measure, to examine and examine not used free RAM all your processors spare time. The more free RAM you have, the better, you could interleave your vars with not used RAM. You could even construct your software so that one powerup you are using 1st half of RAM and testing the 2nd, another powerup you keep your variables in 2nd half and test the 1st. More tests you perform - more chances you'll catch defects.

[kef]

---

Lundin wrote:
Second, RAM is read/write. Any bugs, stack overflow or unexpected behavior of your program could destroy the code. That isn't possible if the code is allocated in ROM.

---

Not possible if whole code sits in ROM? Hm, is all You code a single big function, no interrupts and no function calls, only goto's? If not, then what about volatile nature of return address on stack? I believe that effects of stack overflow, destroing RAM function or destroing return address are always the same - runaway.

[Steve]

Lundin, thanks for taking the time to look at the part.

I can't comment on what unannounced parts may have but I can briefly comment on the EEPROM vs data flash situation.

Essentially this is a cost/feature tradeoff rather than an arbitrary decision to sideline EEPROM. Basically, traditional EEPROM becomes much more expensive with each technology step and for many applications it is simply more cost-effective to implement emulated EEPROM using software and a comparatively big data flash. I appreciate this may not be the case for you but hopefully you at least understand the rationale. You can find out more about flash/EEPROM comparisons from the various online encyclopedias/technical sites.

Thanks,

Steve

[Lundin]

Well... we like to call it EEPROM, but as I understand it, it is really just an implementation on a different kind of flash memory. I very much doubt it is expensive in comparison to the rest of the peripherals on the circuit. HCS08DZ with eeprom is half the price of a HCS12C (which lacks eeprom), and we can get the former for less than $3.

And even if eeprom is expensive, which doesn't seem to be the case, the Freescale customers seem willing to pay for it. Take S08 as an example. When it was released, it was said to be a general-purpose CPU that would never been used in automotive apps, always work on 3.3V, never have any EEPROM etc. S08 has all those features now and that can only be because the customers demanded it.

Also, if I buy an equal automotive 16-bit mcu for a better price from the competition, I can get "virtual eeprom", that is probably also another flash implementation.