User accesible sections of chip flash?

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

 

i've been trying to find out, mostly out of curiosity, which and what for, are the portions of flash that a user can read&write and which are factory locked/burned.

I'm talking about the mega328, but any mega/tiny chip for that matter.

So far i managed to find:

 

User accessible: app flash, I/O registers, general purpose registers

Factory preset: device signatures, ... ???

 

Is anybody knowledgeable about, which flash parts are factory preset and immutable and possibly what are they used for?

 

Much appreciated

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like a school assignment?

 

Reading the Fine Manual i.e. the M328 datasheet should give you the answers your seeking.

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope for you you're curios enough to read some datasheets.

 

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not a school assignment exactly, but i'm brainstorming for possible (memory) failure points for a hobby project of mine, high temp + EMI + possible supply issues.

I just thought i'd get a bit more educated about reliability in this regard.

 

I did read the DS. But i'm not sure if i got everything.

The register summary does list the mostly user accessible.

There's not much talk bout factory presets, except a few sentences in in the memory chapter somewhere.

 

I thought i'd ask here.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
User accessible: app flash, I/O registers, general purpose registers
alpha1 wrote:
portions of flash

What makes you think "registers" are made out of "flash"?

 

What >>does<< the datasheet say about writeability of the signature row?

 

alpha1 wrote:
r a hobby project of mine, high temp + EMI + possible supply issues.

Why don't you explore the automotive-qualified information?  You should be able to get all the qualification reports.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Jan 25, 2018 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At the very least, you need to learn about the distinction between Harvard and Von Neumann architectures. Thinking in the framework of a single type of memory will get you into trouble with most microcontrollers.

 

Jim 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's what i was afraid of. On the surface it seems calm, but underneath lurks a huge monster i'm not sure i'm willing to tackle with.

I guess the question would be...how much do i need to take into account data corruption?

 

The application in mind, will fill up most of the available flash with user data... calibration, reference data, numerous strings etc . I won't be using any external chips for this.

I was thinking along the lines how to make everything more redundant, duplicating same functions.

But obviously, what's the point of it, if you have single points of failure in-between those.

Why i'm focusing on RAM? Just seemed the most vulnerable part outside analog stuff on the chip.

Last Edited: Thu. Jan 25, 2018 - 09:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Insure the power is within spec as to min/max ratings(i.e. good power filtering), use the BOD, put it in a metal box with filtering on all input/outputs (good engineering practice).

If you need redundancy then AVR may not be the mpu of choice....

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't follow the bit about " will fill up most of the available flash with user data... calibration, reference data, numerous strings etc " Strings, yes, at least those defined at compile time. Calibration stuff usually goes into EEPROM. Depending on what you mean by "user data", that might be in either SRAM or EEPROM. Reference data, if you mean program constants, might be in flash if they are known at compile time. 

 

While it IS done, not many applications write to FLASH at any time except when loading a new application via bootloader.

 

FLASH corruption is very rare. When it is known to happen is almost always because of malfunctioning bootloader. I recall that the data retention time for FLASH is spec'd at something over 10 years (it is shortest at the high end of the spec'd temperature range).

 

But, again, I am confused because you first write about flash then say "Why I'm focussing on RAM?", Yet you did not write one word about RAM in the whole message! So, like I say, I am confused.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The RISC (reduced instruction set computers) like the AVR have most of their instructions be the same size: 16 bits for the basic op-code and some instructions having an additional 16-bits for an address.  The AVRs with greater than 64K flash space get a little more complicated.  Memory in the AVR is in three types, a flash section for program instructions that has a basic unit size of 16-bits, a static RAM section that holds the configuration registers for the peripherals like input/output ports, TWI, and USART, followed by general static RAM for the user's application, and a relatively small user EEPROM section.  The program flash is rated at 10,000 writes and, as I understand, many devices can handle 15,000 or so flash writes.  The SRAM has no lifetime usage limit, but the data disappears on power-down.  The EEPROM has a 100000+ write limit.  The SRAM has IN and OUT instructions that work on the first 32 bytes, which are always peripheral control registers.  Above that, the code uses LDS, LD, STS, and ST instructions.  One of these instruction groups requires adding 0x20 to the address value when it's used in assembler programs; a situation that has led to many hours of debugging and head-scratching among assembler programmers over the years.  The data sheet is written in terse, brutal electronic engineering style that makes it quite difficult to use as a tutorial for beginners and non-engineers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I and kki0bk pointed youto the datasheet is that you question was so general you coul get wildly different answers without anyone being sure what you really wanted to know.

A part of the problem is probably that you do not have enough experience to ask the right questions.

You probably are a beginner with uC stuff and it seems to me you are worying about the wrong stuff.

 

Just dive into it and start by making a uC do anything.

 

There are several billion uC's made every year and they are used in almost every application imaginable.

Induststrial (PLC's) automotive, aerospace etc.

 

As a beginner you have very few things to about.

Most important for reliability (I think that that is your underlying question, just guessing) is a decent power supply. It needs some inductor(s) or a common mode filter, voltage regulator and buffer and decoupling caps in all the right places.

When using eeprom it's reccommended to use the brownout detector and some checksum to verify that the eeprom data is correct (multiple copies of your data in eeprom).

Data in eeprom can get corrupted if the powersupply is turned of suddenly during an EEprom write.

 

About reliability and quality in software...

Writing "good" software is an art which takes years to learn and a lifetime to perfect.

Most people don't ever get there.

Even writing "high quality" comments is a non-trivial thing.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Jan 26, 2018 - 03:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I don't follow the bit about " will fill up most of the available flash with user data... calibration, reference data, numerous strings etc "
Like Jim I wonder if you have thought this through? In a 328 you can run the SPM opcode in the last section of flash (I think it's going to be from 30K upwards) and it can actually write to any other location in the flash (though you would usually arrange to protect those 2K or whatever so the writing code cannot damage itself!).

 

However the flash in a 328 is grouped in small pages. Can't remember but it's likely 64 or 128 bytes at a time. To make a write in any particular page that would involve any bit in the 64/128 bytes making a 0 to 1 bit transition can only be accomplished by erasing the entire 64/128 bytes and then rewriting it with the new information where some bit changed back to 1 (because flash program only ever involved making 1 to 0 transitions and the only want to make 0 to 1 transitions is to completely erase an entire page so all the bits in all the bytes return to 0xFF).

 

The thing that is likely to "hit you" here is that each page in an AVR is only guaranteed to be able to erase 10,000 times and after that it may be that some bits "wear out" so they will then always be stuck at 1 or 0 (thus making that entire page redundant).

 

So does your proposed data storage account for this. How much data do you plan to store and how often and are you ready for the bunching it into 64/128 byte pages and the handling of page copy/erase/rewrite modified operations any time there is a 0->1 bit transition?

 

As Jim said for small amounts of data (again I forget but the 328 is going to have 1K or 2K) then EEPROM is a better place. It can handle individual byte activity and the bytes each has a 100,000 rewrite life.

 

Beyond that some kind of external storage like SD/MMC cards or AT45 Dataflash or SPI EEPROM or similar may be a better choice for larger amounts of data storage.

 

The flash in the AVR is only really good for having the program itself replaced a few thousand times - it's not really suitable for non volatile buffering of data.

 

The 328 datasheet has a chapter about bootloaders which explains the flash writing mechanism (SPM) and these kinds of limits etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ka7ehk

Well, yes. Arrays of constants, user data. I'm making sort of a lookup table. Everything at compile time of course. It will have no self programming or any other ability to program flash during runtime.

I meant SRAM/FlashROM.

 

@Simonetta

I'm more of a backyard tinkerer rather than a ele. engineer. Lacking knowledge of Assembly is quite a hindrance in this regard.

 

Now that i think of it. In such extreme conditions, SRAM will probably glitch sooner than flash. And if the glitch happens in a critical section, if could very well freeze the chip. But a restart gets it going again.

However, if the app area gets hit...reprogramming is needed. If a fuse, or especially a factory preset section dies (signature)...you're potentially looking at a bricked chip, device.

That is why this whole question started bugging me. What parts are user un-refreshable and essential for proper operation.

The app itself is pretty simple. A few external sensors, some timers, etc.

 

@Paul

Yes. The first thing i find, when reading about reliability is power supply. Which i took into account as much as i can.

 

@clawson

 

As mentioned. Flash will not be written to after upload. Only read from during runtime. The array/table stored in the flash will hold data "essential" for the specific code.

I created once an external programmer, chip-to-chip, so i'm aware of the page/byte style of access, which is actually standard for flash based memory. EEPROM is usually per byte.

Last Edited: Fri. Jan 26, 2018 - 03:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
Flash will not be written to after upload. Only read from during runtime.
Then I don't understand the purpose of this thread? You started by saying:

alpha1 wrote:
, are the portions of flash that a user can read&write and which are factory locked/burned
The answer then is that no part is burned/locked and all 32K can be used (when you ISP the chip) to hold whatever code and data you like. It's up to you how you want to split the usage. Clearly you will want to use PROGMEM/__flash or whatever other mechanism your development system uses to say "this data to be held in flash only" for the data you want to place there. Something like:

const __flash uint8_t my_lookup_table[] = {
    1, 13, 17, 23, 29, 34, 63
};

That data is then placed in flash alone.

Last Edited: Fri. Jan 26, 2018 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
Lacking knowledge of Assembly is quite a hindrance in this regard.

Why would this be a "hindrance"?

 

C and C++ are both wonderfull languages for small embedded systems / uC's such as AVR.

98% of the programmers will never have a need to fall back on assembly.

C is often called a macro assembler and there are very good reasons for that.

 

Chances of Flash or fuses changing randomly is virtually non existent.

If Ram gets corrupted it is usually your own fault ( bad power supply) bad isolation from environment, lack of shielding.

Just don't put your AVR in space or in a nuclear reactor. They don't work well in such environments.

 

To me it seems that your worries fall into the category of "Will my blinking led still work if it gets hit by a speeding freight train".

If you have a proper schematic / power supply / pcb (ground plane) then almost every bug will be because you put it there by writing bad software.

Concentrate more on the quality of your software.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson

 

Read&write in terms of being programmable, i.e. the user has R&W ability at a given point.

I contrasted it with factory burned, ROM-ish, parts. My bad, if it wasn't clear enough.

 

I know about const. Yes.

 

@Paul

 

You're mostly right. That's why my intention was more of an open discussion, rather than a specific problem solving thread.

I did some reading up about reliability in terms of externalities.  The internals are more of a blind spot.

So much so, that i was thinking of using an external watchdog, rather than the internal, which is fuse dependent.

The thing will run hot. It will be placed within the engine.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
If Ram gets corrupted it is usually your own fault ( bad power supply) bad isolation from environment, lack of shielding.
Also stack overflow and memory leaks...

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
If Ram gets corrupted it is usually your own fault ( bad power supply) bad isolation from environment, lack of shielding.

Not to mention bad software - e.g. buffer overruns and/or rogue pointers..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
It will be placed within the engine.

 

Engine? or Engine compartment?

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@frog

 

It's a simple app, I'll try to do everything as tight as possible with the least amount of variables and functions.

 

 

@ki0bk

 

Within the crankcase.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
Within the crankcase.
   Ouch, why?  Most ECU's are located in the passenger compartment, only the sensors/accuators are attached to the block?

I see why your concerned with lifespan.

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
I contrasted it with factory burned, ROM-ish, parts.
Then you don't understand AVR - there is no "ROM" or anything else "burned" into it. If you wonder how it is able to accept "ISP programming" without any firmware then that is not some AVR executable code that is burnt into it but actually some kind of SPI state machine implemented in the silicon which is able to implement the programming interface with no code actually executing on the AVR core. In fact during ISP the _Reset signal is held active so the AVR CPU core could not start to execute anyway! This is all explained in the datasheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:
Also stack overflow and memory leaks...
JohanEkdahl wrote:
Not to mention bad software - e.g. buffer overruns and/or rogue pointers..
  Those are examples of bad software, which I mentioned 2 lines lower...
alpha1 wrote:
It will be placed within the engine.
Sounds automotive.

Automotive parts have their own rules.

I'm not even sure if there are AVR's which are rated for automotive applications.

One very important thing for automotive applicactions is that your circuit has to be able to withstand "load dump". This is basically a short pulse on the power supply of voltages between 60V and 90V depending on which stanard you follow. If your ciruit is low powered a single extra resistor might suffice (With a large Buffer cap), and/or add an overvoltage zener shunt after the resistor.

Temperature is probably not the biggest problem.

There is loads of electrial noise under the hood of a car. (high voltage sparking thingies etc). Youll need loads of shielding. Full metal enclosure with metal gaskets & carefull design of each wire which crosses the boundary of your box.

 

Another problem is mechanical vibration.

Crystals are not good at working under vibratory conditions.

They might skip a few beats under shock load (your AVR will hang) or the thin legs of the crystal might break after prolonged vibration (This is pretty common failure mode).

Use RC oscillator if timing is not important.

 

Ther are uC's which can detect when the crystal oscillator fails, and then switch to an internal RC oscillator and trigger an interrupt.

 

I do not see much use in an external watchdog.

 

If you're really that conserned about your circuit you should consider using 2 uC's which constantly check each other's operation.

Then if one fails, the other can take appropriate actions.

But such software is pretty difficult to write reliably.

 

When thinking a bit more about it...

Your concern about your circuit seems to indicate that serious things might happen if your circuit fails.

What's it doing? ABS? Motor mangement? Power steering?

 

If your circuit comes anywhere near circuits like that I have only one advice for you:

Don't Do It !!! I'm serious. Don't.

I do not say this out of a viewpoint of lawyer / lawsuit disclaimer, but simply because you do not have the experience to meddle with such circuits.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Jan 26, 2018 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ki0bk & paul

 

No point going into details, but it's 50% just for kicks, the other part is challenge+potential idea. Off-road, enthusiast stuff.

The guinea pig it probably gonna be me.

 

Regarding your tips paul, i must say i've already consider most of them them. But thank you anyway. I don't know if avr has a clock fail-safe mechanism, but i did see it in some TI uC's.

 

@clawson

 

yes, i'm aware ISP is hardware based. But for ISP programming you need to first get the correct program mode byte back, as well as device signature (amongst other things).

I'm not sure if these are also hardware based, or if they are "locked" flash (the DS seems to suggest so). That's why i'm referring to it, as "ROM".

Last Edited: Fri. Jan 26, 2018 - 06:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you asked the question “is it possible for the flash or ram to get corrupted?” Then the answer is yes. How do you mitigate these? Proper hardware design will avoid most problems. You’ll find even back in the 80’s the manufacturers of auto electronics were doing a checksum/crc of the rom/eprom and a checksum of critical ram blocks.
Bosch in their 8051 based ECUs would have blocks of code to perform certain calculations. The block of ram for each of these calculations would have their checksum checked on entry. If it was wrong, then the data would be re-initialised. The calculations were done and a new checksum calculated and stored.
Reliability - there’s two sides to this: ensuring the device is operational and ensuring the device does nothing wrong. The first is mainly hardware - design and chose components that are rated for the operational environment and understand component life and failure modes.
The second requires understanding how your system may fail and how to identify a failure. The basic rule is: tolerate one failure but be able to detect any failure.
With your inputs, you need to be able to determine if it is correct. On one of my designs have a current sensor that is critical to the safety of the system. How do i check this? I can switch a resistor to apply a known load so my system can determine very quickly if the current sensor is operational. Also, in various operational modes, i expect a certain current to flow, so my software checks for this.

You need to be able to check your outputs. What happens if a mosfet fails? How does it normally fail? (Usually short circuit). Can you detect this? How would you mitigate such a problem? Eg: mosfet might be controlling a fuel pump or heater where failure might create a dangerous situation.

Interestingly, there’s a EU requirement for whitegoods to have a degree of protection with their electronics where you have to detect a number of potential failures. The EN number escapes me but most manufacturers have app notes and example code to check registers, flash, ram, timers etc.
I’ve recently done a project with an infineon xmc1100. It has ecc on the flash and parity on the ram - in a $1 chip. You can move up to the safety rated processors like the TI hercules, Infineon tricore and NXP/Freescale have a range of powerpc based automotive devices that have two cpu cores lockstep checking each other and extensive ecc/crc checking on flash/ram/peripherals.

If you keep on asking the question: “if this fails, what is the outcome?” .this is the initial phase of a FMEA. Google that term.
It pays to be creative in this phase. Seems the people at Rolls Royce weren’t too creative on the day. What happens if this oil line fails? Oh, the compressor disk overspeeds, explodes, destroys the engine and the bits slice through anything they hit - like the plane wing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Self diagnostics, yes. I'll probably have a CRC mechanism integrated.

Bi-core CPUs. I just might take a look into it.

Appreciate the tips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alpha1 wrote:
No point going into details,
theusch wrote:
Why don't you explore the automotive-qualified information? You should be able to get all the qualification reports.

...and discussion of applicable factors, and references to standards and test procedures, and similar. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.