You should be able to edit the “default” settings so a reflash or factory reset would go back to them.
I do not know how.
You can backup and restore your EEPROM with all your settings. You can also keep the EEPROM intact when updating the firmware. The problem with this is: It might not work with an updated firmware because the memory addresses might change! Also they will all be gone after a reset. So the best way is to create a custom configuration with all your preferences.
Very helpful. So, since I cannot create my own hex files, I should NOT do a Factory reset.
…. testing now…
It Works! I Can backup and reflash my personal settings! woohoo!!
So I’m nearly ready to share my Anduril 2 HDR boost drivers (Oshpark and Aisler) with building instructions, I designed three ones with different clearance diameters :
- BST15 : for 17+mm drivers, 60*0 inductor, 3333 RPP PFET, double sided, 1*AUX LED, also supports Mike C’s OTSM
- BST18 : for 20+mm drivers, 60*0 inductor, 5060 RPP PFET, double sided, 3*AUX LED. With a BST18-FWxA version.
- BST21 : for 23+mm drivers, 70*0/ 60*0 inductor, single sided with 3333 RPP PFET and an additional 5060 emplacement on the back. 4*AUX LED. With BST21-KRx version.
But I need a modification in Anduril to solve the startup current spike, this issue is actually also present to a lesser extent in the Noctigon boost drivers (also based on the MP3431), several people have complained about it. In my drivers this spike is exacerbated by the higher value of the Op Amp compensation capacitor used to eliminate the (acoustic) noise with the high value current sense resistor I use for low/ultra low modes.
This happens when the light is powered ON at the bottom of the high power range (in the low power range the high value current sense resistor greatly reduce this spike, altgough not completely). And also during various Anduril flashes, the most problematic one is the Anduril powering up flash that happens when using the programmer, since USB doesn’t provide enough current the voltage drops and it just power up/down endlessly. The only solution is to disconnect the LED or use another power source.
There are two solution for this :
- The first one is to delay the HDR FET (Q2) (LED_ENABLE_PIN) for a configurable amount of time after Boost Enable (LED2_ENABLE_PIN), basically the LED would always turns ON on the low power range first, this greatly reduce the spike.
I asked Gchart about this earlier this year and he added some code for this ( Revision 608 and 609 ), but in my tests this does the opposite, it delays Boost Enable (LED2_ENABLE_PIN), I haven’t looked into it since.
- The second and better solution, which would also apply to Noctigon boost drivers if they make a small hardware revision, is to pull down the control signal at the Op Amp at turn ON. This idea comes for Mike C, at first he used a MCU pin directly but that caused some issue when it was not pulled down, so a small Nfet (Q3) is used instead, this completely eliminate the current spike and is the preferred solution. The pin controlling Q3 needs to be pulled up (control signal pulled down to GND) after Boost Enable for some amount of time, otherwise pulled down.
I have a couple of other requests, but that’s the most important one for the drivers to be ready.
Oh I also have a bunch of buck drivers to share, they do have a very faint start up spike, not problematic in my opinion, again it’s about balancing the op amp comp value and stability. I didn’t add Q3 to them, but they might benefit from the first solution, again it’s not very important.
I thought I had accomplished that by using this command sequence:
pymcuprog read -m eeprom -m flash -f ~/Desktop/SP10backup.hex -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
BUT, I did a factory reset before reflashing, and when I reflashed with the backup, using this command sequence:
pymcuprog write -f ~/Desktop/SP10backup.hex -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
NONE of my options, such as floor, and ceiling, were reinstalled.
what am I doing wrong? or better yet, can you please teach me
HOW to save EEPROM settings, and How to reload them?
I’ve never tried to backup and restore the EEPROM with pymcuprog and don’t know if you have to specify all sections when flashing. But I see that you don’t use —erase while writing. Not using this option will cause all set bits to stay set, i.e. your updated firmware will misbehave.
You can also try the latest release of avrdude which should support the tinyAVR-0/1. There are some examples in this thread: Adventures in TinyAVR 1-Series - #294 by gchart
to be clear, I have installed gchart’s SP10 Pro hex file. I then set my preferences for floor, ceiling, turbo style etc, and do a backup. But my backup does NOT restore my eeprom preference settings…
I would really like to be able to restore my custom eeprom settings… request a proper command sequence.
> I see that you don’t use —erase while writing
true, -erase is a separate command line in my reflashing sequence
it comes before I restore from backup hex
it makes no difference whether I erase or not, I still lose my eeprom settings to a factory reset, done Before restoring from the backup that I saved the eeprom to
fyi: avrdude in not compatible with my 7 year old iMac
pymcuprog works to reflash, I just dont know how to save and restore my eeprom settings… these are the steps I use:
1. ping the light
pymcuprog ping -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
2. make a backup of the existing hex (note the -m eeprom command)
pymcuprog read -m eeprom -m flash -f ~/Desktop/SP10backup.hex -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
3. erase the mcu
pymcuprog erase -m flash -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
4. write the new firmware (takes 5 minutes btw)
pymcuprog write -f ~/Desktop/SP10backup.hex -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
Does anyone have a suggested command sequence to save and restore eeprom settings?
I just gave this a shot… I’m pretty sure I have it working:
pymcuprog read -m all -f ~/Desktop/SP10backup.hex -t uart -u /dev/tty.wchusbserial1420 -d attiny1616
It looks like the “read” command only process one argument for memory locations. So when you included two memory locations, I’m pretty sure it just used the second one - grabbing only the flash and not the eeprom. So instead, tell it to grab memory “all” and it’ll get all user-writeable memories (in my test: flash, eeprom, fuses, and user_row).
Oh, and my write command took around 12 seconds. Yours taking 5 minutes seems… unusual (but unrelated to the issue you posted about).
After saving everything with “read -m all”, I suggest to flash only flash and eeprom – fuses might cause issues and what is user_row, something calibration related?
Factory calibration settings are in signature_row which isn’t part of the “-m all”, it’s a read-only area of memory. Here’s user_row info from the attiny1616 datasheet:
It looks like user_row is essentially more eeprom, but it can be written even when the chip is locked? At least that’s how I’m reading that.
I personally don’t foresee any issues by doing a write using the “-m all” file. If the fuses came from that model of light (or even that same exact light), shouldn’t they be the same values anyway? Those will hold default clock speed, brown-out settings, etc which I would think should be transferable.
If it end up working with pymcuprog then that’s good, but are you sure about that ? It seems that the installation package is only compatible with 10.15 and up (which the 8 years old mac book I borrowed has), but with a quick googling it can be installed on older versions with something called Homebrew.
Also AVRDUDESS which you might prefer because it has a GUI, is installed via Mono (10.9 and up).
YES!
I can now save all my custom floors and ceilings, and reflash as desired
I can still kill the custom floors and ceilings with a factory reset… win win
Thank You!
Yes, I did use homebrew, python3, pip, and pymcuprog…
pymcuprog does work on my iMac w IOS 10.12.6, but I had to first download a special driver…
thanks, my avrdude install failed last time I tried… and I do not know where to find AVRDUDESS for iMac
Installed is the wrong word sorry, you instal mono first and then you run AVRDUDESS with it , the download links for AVRDUDESS are the main page : AVRDUDESS – A GUI for AVRDUDE | Zak’s Electronics Blog ~* and the command to run AVRDUDESS.
thanks for the coaching
Im retrying to install avrdude with this brew command:
brew install avrdude
(it took 15 minutes)
I got this series of error messages:
===
Last 15 lines from /Users/jonathan/Library/Logs/Homebrew/confuse/02.make:
-
TOTAL: 24
-
PASS: 22
-
SKIP: 0
-
XFAIL: 0
-
FAIL: 2
-
XPASS: 0
-
ERROR: 0
See tests/test-suite.log
Please report to Issues · libconfuse/libconfuse · GitHubmake[3]: * [test-suite.log] Error 1
make[2]: * [check-TESTS] Error 2
make[1]: * [check-am] Error 2
make: * [check-recursive] Error 1
Do not report this issue to Homebrew/brew or Homebrew/core!
Error: You are using macOS 10.12.
We (and Apple) do not provide support for this old version.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew’s GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
old version.
===
downloaded and installed mono successfully from this link:
https://www.mono-project.com/download/stable/
downloaded AVRDUDESS successfully from:
https://github.com/ZakKemble/AVRDUDESS/releases/download/v2.14/AVRDUDESS-2.14-portable.zip
I dont know what the next steps would be, to use AVRDUDESS, or whether it relies on a successful install of AVRDUDE first…
but fortunately, pymcuprog works fine, thanks to the command sequence from gchart
===
Received a new TS10 Black w Blue Aux
default is High Aux when off, low Aux when On, and 90 lumens start in Simple stepped mode.
this is true
I tried to just reflash from my backup file, it did not work, the light would not turn on.
I erased first, and then reflashed to my custom backup, and Viola! All my preferences loaded…
now it turns on in advanced ramping at 10 lumens, with aux off, and when off the aux are on low
much better!
no grief at all, just plug and play… 15 minutes later… all is Great!
fwiw, the blue aux are MUCH brighter than the Red, I can actually see the blue during the day. I had to check to make sure the blue were on low, and yes, this is low on both colors:
.
I’m excited
And so are my Nichia emitters
just received my flashing kit from Daddy Hanky
but i never flashed a flashlight and it’s a lil bit confusing… i have a K9.3 E21A without tint ramping and now i want to ramp it so i guess i need to flash it with anduril.2021-05-07.noctigon-k9.3-nofet.hex right?
Just check the model code in the version check (15C) and match the last four digits: http://toykeeper.net/torches/fsm/anduril2/MODELS
thx!
Hi, everyone!
Has anyone made an Anduril 2 hex file for Astrolux EA01/Mateminco MT01?
Is Astrolux FT03/Mateminco MT35 mini compatible with it?
Unfortunately, I’m not at the level to compile firmware for it.
What would peoples thoughts be on a quick way to get to strobe from ON? Like make 3H go to strobe from ON or OFF. I just think it would be handy so you could go straight to strobe while already using the light