EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Writing to MCU flash

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Electronics Design - Writing to MCU flash

Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next

Phil Hobbs
Guest

Thu Jan 24, 2019 4:45 pm   



So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

John Larkin
Guest

Thu Jan 24, 2019 4:45 pm   



On Thu, 24 Jan 2019 10:25:08 -0500, Phil Hobbs
<pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs


We have a serial flash cal table on most of our products, written by
the onboard ARM, with a checksum. That works fine.

We have a default cal table in the program, which gets loaded at first
powerup or if the flash table is corrupted. Users are informed of we
are running the default.

The cal table also includes cal table type ID, model number, dash
number, serial number, and cal date.

The cal table resides in a separate soldered-down flash chip from the
program/FPGA code, so we can mail a new plug-in code chip to a
customer without trashing the calibrations.

We sometimes self-cal some things every powerup, like ADC gains and
offsets, and keep those in ram. But with Susumus, you could cal at
test time. You probably need some nonvolatile cals.





--

John Larkin Highland Technology, Inc

lunatic fringe electronics

Phil Hobbs
Guest

Thu Jan 24, 2019 5:45 pm   



On 1/24/19 10:42 AM, John Larkin wrote:
Quote:
On Thu, 24 Jan 2019 10:25:08 -0500, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs

We have a serial flash cal table on most of our products, written by
the onboard ARM, with a checksum. That works fine.

We have a default cal table in the program, which gets loaded at first
powerup or if the flash table is corrupted. Users are informed of we
are running the default.

The cal table also includes cal table type ID, model number, dash
number, serial number, and cal date.

The cal table resides in a separate soldered-down flash chip from the
program/FPGA code, so we can mail a new plug-in code chip to a
customer without trashing the calibrations.

We sometimes self-cal some things every powerup, like ADC gains and
offsets, and keep those in ram. But with Susumus, you could cal at
test time. You probably need some nonvolatile cals.


So you don't ever have firmware write stuff to MCU flash?

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com


Guest

Thu Jan 24, 2019 5:45 pm   



On Thursday, January 24, 2019 at 10:25:20 AM UTC-5, Phil Hobbs wrote:
Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?


Is there anything behind the lore? Or is it just random mutterings on the idle packets streaming the Internet?

Many products, many MANY products have the ability to update their firmware. To do that requires they write to their own flash. How bad can it be?

Rick C.

- Get 6 months of free supercharging
- Tesla referral code - https://ts.la/richard11209

Lasse Langwadt Christense
Guest

Thu Jan 24, 2019 6:45 pm   



torsdag den 24. januar 2019 kl. 17.30.32 UTC+1 skrev gnuarm.del...@gmail.com:
Quote:
On Thursday, January 24, 2019 at 10:25:20 AM UTC-5, Phil Hobbs wrote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Is there anything behind the lore? Or is it just random mutterings on the idle packets streaming the Internet?

Many products, many MANY products have the ability to update their firmware. To do that requires they write to their own flash. How bad can it be?


the update procedure does in some cases involve the host
loading a flash programmer into RAM, so if you are the belt and suspenders
type you avoid the small risk of having flash programming code in the product
that could be triggered by accident

John Larkin
Guest

Thu Jan 24, 2019 6:45 pm   



On Thu, 24 Jan 2019 11:25:23 -0500, Phil Hobbs
<pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Quote:
On 1/24/19 10:42 AM, John Larkin wrote:
On Thu, 24 Jan 2019 10:25:08 -0500, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs

We have a serial flash cal table on most of our products, written by
the onboard ARM, with a checksum. That works fine.

We have a default cal table in the program, which gets loaded at first
powerup or if the flash table is corrupted. Users are informed of we
are running the default.

The cal table also includes cal table type ID, model number, dash
number, serial number, and cal date.

The cal table resides in a separate soldered-down flash chip from the
program/FPGA code, so we can mail a new plug-in code chip to a
customer without trashing the calibrations.

We sometimes self-cal some things every powerup, like ADC gains and
offsets, and keep those in ram. But with Susumus, you could cal at
test time. You probably need some nonvolatile cals.

So you don't ever have firmware write stuff to MCU flash?

Cheers

Phil Hobbs


Users can do soft upgrades to the runtime code, but it's often easier
and safer to mail them a chip rather than have them upgrade over
ethernet or USB. There's a lot less to explain.

(Some people just take the box home and plug in the chip there, rather
than dealing with their IT Prevention Department. These people also
take their laptop to Starbucks to get files from us.)

We have two program images in each box, "factory" and "upgrade." A
user can run software (sometimes just a browser) to flash the upgrade
image.

At powerup, a boot loader checks for a valid upgrade image, and runs
it if it looks OK. Otherwise it runs the factory image. If we mail the
user a plugin flash chip, it has only a factory image. RMAs get
reflashed with just the appropriate factory code.

With a hundred or two products having revs and dash numbers and ECOs,
and multiple code revs, and corresponding cal tables, and factory cal
software, we have a nontrivial configuration management problem. It's
important that a user can tell us exactly what is the state of his
box.

We made our own plugin DIP8 adapter for surface-mount serial flash
chips, with room for a label.


--

John Larkin Highland Technology, Inc

lunatic fringe electronics

Joe Chisolm
Guest

Thu Jan 24, 2019 7:45 pm   



On Thu, 24 Jan 2019 10:25:08 -0500, Phil Hobbs wrote:

Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs


I did not go through the 804 data sheet but on other LPC I've used:
1 - minimum size is going to be 4K blocks
2 - everything is going to stall while the flash operation is in
progress, no interrupts, no nothing.
If you are going to do some type of self cal you need to run the cal,
gather the data and then do the write (well, erase and write).

If you are going to be updating the calibration table many many
times I think it's best to have a SPI or I2C eeprom or flash.


--
Chisolm
Republic of Texas

John Larkin
Guest

Thu Jan 24, 2019 7:45 pm   



On Thu, 24 Jan 2019 09:40:56 -0800 (PST), Lasse Langwadt Christensen
<langwadt_at_fonz.dk> wrote:

Quote:
torsdag den 24. januar 2019 kl. 17.30.32 UTC+1 skrev gnuarm.del...@gmail.com:
On Thursday, January 24, 2019 at 10:25:20 AM UTC-5, Phil Hobbs wrote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Is there anything behind the lore? Or is it just random mutterings on the idle packets streaming the Internet?

Many products, many MANY products have the ability to update their firmware. To do that requires they write to their own flash. How bad can it be?


the update procedure does in some cases involve the host
loading a flash programmer into RAM, so if you are the belt and suspenders
type you avoid the small risk of having flash programming code in the product
that could be triggered by accident


Our presumably bug-free boot loader resides in the same flash as the
runtime code images. In the improbable event that the loader gets
trashed, we can send them a new plugin flash or they can send the box
back.

Some simpler products use a single-chip approach, no outboard flash.
They may not be field upgradable.


--

John Larkin Highland Technology, Inc

lunatic fringe electronics

Lasse Langwadt Christense
Guest

Thu Jan 24, 2019 7:45 pm   



torsdag den 24. januar 2019 kl. 16.25.20 UTC+1 skrev Phil Hobbs:
Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?


I do it on an STM, but there is the small risk of having code in the MCU that
can program flash possibly being triggered by some cosmic event,
supply glitch etc.

bitrex
Guest

Thu Jan 24, 2019 7:45 pm   



On 01/24/2019 10:25 AM, Phil Hobbs wrote:
Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice.  The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs



No on-board EEPROM on those parts? Maybe 8 bit has a life after all.
Even the 50 cent ATTiny85 has 512 bytes of 100k-cycle EEPROM on die it
can come in very handy

bitrex
Guest

Thu Jan 24, 2019 8:45 pm   



On 01/24/2019 12:48 PM, John Larkin wrote:
Quote:
On Thu, 24 Jan 2019 09:40:56 -0800 (PST), Lasse Langwadt Christensen
langwadt_at_fonz.dk> wrote:

torsdag den 24. januar 2019 kl. 17.30.32 UTC+1 skrev gnuarm.del...@gmail.com:
On Thursday, January 24, 2019 at 10:25:20 AM UTC-5, Phil Hobbs wrote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Is there anything behind the lore? Or is it just random mutterings on the idle packets streaming the Internet?

Many products, many MANY products have the ability to update their firmware. To do that requires they write to their own flash. How bad can it be?


the update procedure does in some cases involve the host
loading a flash programmer into RAM, so if you are the belt and suspenders
type you avoid the small risk of having flash programming code in the product
that could be triggered by accident


Our presumably bug-free boot loader resides in the same flash as the
runtime code images. In the improbable event that the loader gets
trashed, we can send them a new plugin flash or they can send the box
back.

Some simpler products use a single-chip approach, no outboard flash.
They may not be field upgradable.



I've done a (proof-of-concept at least) field-upgradeable ATTiny 8 pin,
a 512 byte bootloader is sufficient to hold code that can receive a
bit-banged in serial stream with a "magic sequence" that the bootloader
waits for a couple seconds to see if it receives on start-up, if it
shows up it's saying "Attetion, bootloader, new program data coming in"
and it writes out the stream to program memory and reboots when it's
complete after performing a checksum.

If the process is interrupted or cheksum fails it's OK the bootloader
section is untouchable so just try again.

Tauno Voipio
Guest

Thu Jan 24, 2019 8:45 pm   



On 24.1.19 17:25, Phil Hobbs wrote:
Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice.  The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs


I have thousands of AT91SAM and STM32 -based Cortex devices
in the field, having the capacity of writing into the internal
Flash.

The devil of the details depends on the particular chip, but
in general you have to copy the innermost parts of the write
loops into RAM and run them from there, as the Flash is inaccessible
durin an erase or write. The minimum write unti depends on the
chip (again), but it usually is from 1 byte to 8 bytes. Some
manufacturers are not happy even to specify it.

Usually, the write code has to be linked so that it is prepared
to run in the RAM addresses.

--

-TV

JM
Guest

Thu Jan 24, 2019 8:45 pm   



On 24/01/2019 15:25, Phil Hobbs wrote:
Quote:
So we've got this custom product that includes a voltage-controlled
amplifier.

VCA chips as used in ultrasound and so on have nice low noise at the
highest gains, but at low gain they stink on ice. The same is true of
all transconductance-based VCAs unless you use a zillion stages.

Sooo, we're faking it with a dpot, an op amp with a mux-controlled
resistor ladder, and an LPC804 Cortex M0+.

The resistor ladder is made out of standard-value Susumu 25-ppm
resistors, so it's better than the dpot except that the switchable gains
aren't exactly powers of two.

The simple way of handling this is to have the thing self-calibrate.
That could be done at power-up and the cal table kept in RAM, or at test
time with the table in flash.

There's some lore on the net that having the firmware write to the MCU
flash is a bad idea.

Experiences? Opinions?

Cheers

Phil Hobbs



Have done it for years.

John Larkin
Guest

Thu Jan 24, 2019 8:45 pm   



On Thu, 24 Jan 2019 19:08:45 GMT, <698839253X6D445TD_at_nospam.org>
wrote:

Quote:
Lasse Langwadt Christensen wrote
the update procedure does in some cases involve the host
loading a flash programmer into RAM, so if you are the belt and suspenders
type you avoid the small risk of having flash programming code in the product
that could be triggered by accident

I use the code protection feature of Microchip PICs when I do not want to show the code in some cases.
So releasing code memory update using that boot loader is out.
I agree with J Larkin that it is better to simply send a new chip (are on sockets for that reason anyways).
User settings and calibration are in EEPROM in the chip, or an external chip.
Having default settings in code is a nice idea (have not done that, EEPROMs are programmed to default when programming).
There is a small risk in using sockets, those can fail, good quality sockets are OK.
I am wondering about J.L's security (especially the companies that go to starbucks for coffee and updates),
WiFi has been completely hacked,
Theoretically you could simply pose as the manufacturer and send a fixed update etc etc.
Would be a no-no for me.

Replacing chips on sockets is easy, just added some features to some project today...
however that also needed adding some hardware... Drone flight recorder
can record flight and then you can have it fly that again and again all by itself.
Saved as a text file, can edit it too.
lat lon alt speed heading.... other commands.... to / from SDcard...
Just for fun.



Sometimes we use a socketed SD card instead of a plugin dip flash
chip. The Zynq SOCs know how to boot off SD cards.


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Guest

Thu Jan 24, 2019 8:45 pm   



Lasse Langwadt Christensen wrote
Quote:
the update procedure does in some cases involve the host
loading a flash programmer into RAM, so if you are the belt and suspenders
type you avoid the small risk of having flash programming code in the product
that could be triggered by accident


I use the code protection feature of Microchip PICs when I do not want to show the code in some cases.
So releasing code memory update using that boot loader is out.
I agree with J Larkin that it is better to simply send a new chip (are on sockets for that reason anyways).
User settings and calibration are in EEPROM in the chip, or an external chip.
Having default settings in code is a nice idea (have not done that, EEPROMs are programmed to default when programming).
There is a small risk in using sockets, those can fail, good quality sockets are OK.
I am wondering about J.L's security (especially the companies that go to starbucks for coffee and updates),
WiFi has been completely hacked,
Theoretically you could simply pose as the manufacturer and send a fixed update etc etc.
Would be a no-no for me.

Replacing chips on sockets is easy, just added some features to some project today...
however that also needed adding some hardware... Drone flight recorder
can record flight and then you can have it fly that again and again all by itself.
Saved as a text file, can edit it too.
lat lon alt speed heading.... other commands.... to / from SDcard...
Just for fun.

Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next

elektroda.net NewsGroups Forum Index - Electronics Design - Writing to MCU flash

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map