On 01/24/2019 10:25 AM, 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? > > Cheers > > Phil Hobbs > >It's probably FUD. On AVR at least it's easy to declare a static program-memory-space buffer in the .data section that will never be used to put executable code. Then there are op-codes to write Flash memory space from executing code though they sometimes have to be executed from a certain address range in the Flash itself (bootloader section.) There are function tags and compiler flags to ensure your write function is executed from the proper location. I would assume ARM has something similar. With the caveats that Flash is only good for ~10k write cycles and that it can only be read and written to in "pages" of some size it would seem the worst that could happen is your Flash-buffer gets corrupted from a power loss during a write-out so CRC to test for it.
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 24, 20192019-01-24
Reply by ●January 24, 20192019-01-24
On 01/24/2019 01:51 PM, bitrex wrote:> On 01/24/2019 10:25 AM, 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? >> >> Cheers >> >> Phil Hobbs >> >> > > > It's probably FUD. On AVR at least it's easy to declare a static > program-memory-space buffer in the .data section that will never be used > to put executable code. Then there are op-codes to write Flash memory > space from executing code though they sometimes have to be executed from > a certain address range in the Flash itself (bootloader section.) > > There are function tags and compiler flags to ensure your write function > is executed from the proper location. I would assume ARM has something > similar. > > With the caveats that Flash is only good for ~10k write cycles and that > it can only be read and written to in "pages" of some size it would seem > the worst that could happen is your Flash-buffer gets corrupted from a > power loss during a write-out so CRC to test for it. > >On that platform for C/C++ all the grunt assembler bullshit is macro-ified and there's a header to simplify the process avr/boot.h
Reply by ●January 24, 20192019-01-24
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 accidentI 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.
Reply by ●January 24, 20192019-01-24
On 01/24/2019 12:48 PM, John Larkin wrote:> On Thu, 24 Jan 2019 09:40:56 -0800 (PST), Lasse Langwadt Christensen > <langwadt@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.
Reply by ●January 24, 20192019-01-24
On 24.1.19 17:25, 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? > > Cheers > > Phil HobbsI 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
Reply by ●January 24, 20192019-01-24
On 24/01/2019 15:25, 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? > > Cheers > > Phil Hobbs > >Have done it for years.
Reply by ●January 24, 20192019-01-24
On Thu, 24 Jan 2019 19:08:45 GMT, <698839253X6D445TD@nospam.org> wrote:>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
Reply by ●January 24, 20192019-01-24
On Thursday, 24 January 2019 10:25:20 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? > > Cheers > > Phil Hobbs >There's EEPROM emulation code out there for that MCU. It should work okay, provided you don't need smooth functioning to continue during the write and are not too tight on the code space so that granularity matters. I also note the endurance is claimed to be 200K for that part, which is not terrible (typically it's 1,000,000 for a serial EEPROM). On the other hand, I think I'd at least consider laying out the PCB for an I2C EEPROM such as the AT24xx series. If even one piece of product gets bricked that would pay for a lot of 15 cent EEPROMs. I'm using an external EEPROM with an M7 ARM because it's there anyway for the MAC address. --Spehro Pefhany
Reply by ●January 24, 20192019-01-24
On Thu, 24 Jan 2019 12:59:16 -0800 (PST), speff <spehro@gmail.com> wrote:>On Thursday, 24 January 2019 10:25:20 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? >> >> Cheers >> >> Phil Hobbs >> > >There's EEPROM emulation code out there for that MCU. It should work okay, >provided you don't need smooth functioning to continue during the write and >are not too tight on the code space so that granularity matters. > >I also note the endurance is claimed to be 200K for that part, which is not >terrible (typically it's 1,000,000 for a serial EEPROM). > >On the other hand, I think I'd at least consider laying out the PCB for an I2C >EEPROM such as the AT24xx series. If even one piece of product gets bricked >that would pay for a lot of 15 cent EEPROMs. > >I'm using an external EEPROM with an M7 ARM because it's there anyway for the >MAC address. > >--Spehro PefhanyWe have one instrument where we want the front panel settings preserved over a power cycle, so we write to flash often. We use a 16 kbit FRAM that claims 1e14 writes. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●January 24, 20192019-01-24
On 1/24/19 3:59 PM, speff wrote:> On Thursday, 24 January 2019 10:25:20 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? >> >> Cheers >> >> Phil Hobbs >> > > There's EEPROM emulation code out there for that MCU. It should work okay, > provided you don't need smooth functioning to continue during the write and > are not too tight on the code space so that granularity matters. > > I also note the endurance is claimed to be 200K for that part, which is not > terrible (typically it's 1,000,000 for a serial EEPROM). > > On the other hand, I think I'd at least consider laying out the PCB for an I2C > EEPROM such as the AT24xx series. If even one piece of product gets bricked > that would pay for a lot of 15 cent EEPROMs.Not a bad idea at all. In this case the cal will be pretty stable--the dpot only has 256 steps--so we can avoid that problem by doing the cal once at test time. Thanks 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
