How to flash
jbakuwel opened this issue · comments
Hi folks,
I'm not sure where to post this question so I've posted it in a few different places. Apologies if you're coming across this multiple times.
I finally found the time to build the 2nd kit I bought from OpenEVSE so now I can muck around with the firmware without running the risk of bricking the unit we need to charge the car. I still need to create a workaround for the car charger responding to slow to pilot change.
I haven't been able to compile the firmware when selecting to use Board: [Programmer]OpenEVSE (this results in "recipe.preproc.macros pattern missing"). The code compiles fine with Board: "Arduino/Genuino Uno". This results in two firmware files but I am not sure which one to use. It's also not clear which command(s) to use to flash it to the controller. Note: I've used the firmware from https://github.com/openenergymonitor/open_evse.git and modified a few constants (OVERCURRENT_TIMEOUT from 5000 -> 10000) for example.
flash.bat suggests:
avrdude -c USBasp -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U
efuse:w:0x04:m
avrdude -c USBasp -B0.5 -p m328p -V -U flash:w:open_evse.hex
avrdude -c USBasp -p m328p -V -U eeprom:w:eeprom_24.bin -V
This article suggests:
avrdude -p atmega328p -c usbasp -P usb -e -U flash:w:<firmware.hex>
Do I need to burn the fuses or flash the eeprom or can I skip those steps? Do I need to use the erase flag or the bitclock flag? Do I need the firmware with the bootloader or without the bootloader? Is the bootloader required for future versions of the ESP firmware (for example to enable OTA firmware updates for the OpenEVSE controller)?
Your help is much appreciated.
kind regards,
Jan
Afaik the default from OpenEVSE is/was no bootloader, and as such you only need to change the fuses if you want to add a bootloader (bootsz=11 + bootrst=0) or have replaced the atmega328.
I've seen some hints to future OTA firmware updates which would require the latest version of optiboot, but I'm not sure the default build has room for a bootloader; didn't use to have it, if you can fit it, it won't do you any damage until if and when you go to upgrade and the new version doesn't fit., at which point you'll have to break out the usbasp programmer again, change the fuses back and flash the firmware.
Would never the less be interesting to hear what the devs have to say about that.
When it comes to the EEPROM I might not have all the facts, but I've programmed the eesave fuse to retain my EEPROM when flashing to keep the running kWh counter and AFAIK its not a problem. New settings are appended behind the existing ones when they add features it seems. But you could just write down the settings and restore using RAPI post flash and avoid any potential pitfalls.
In short; unless you have a reason, flash the firmware, flash the eeprom file to ensure sane defaults and leave the rest. You do not want to touch the lock bits, nor any other fuse if you don't understand the consequences is a good rule.
Hi Craig and Beikeland,
Thanks for your responses and sorry for being a bit brief on the reason why I need to update the firmware in the OpenEVSE controller; I wasn't expecting replies from anyone else but the devs with whom I've been in touch in the past about this issue.
The problem - as far as I understand it - is due to not-up-to-date firmware in the car (2011 Gen 1 Nissan Leaf) charger which, apparently, does not respond quickly enough to a change in pilot. I'm running OpenEVSE in divert mode; my off grid solar system publishes available power for car charging via MQTT. If the car takes longer than OVERCURRENT_TIMEOUT (5 sec in standard firmware) to respond to a change in pilot, OpenEVSE will disengage and stop charging. We often have fluctuating solar power, varying between a few 100W and 6KW depending on clouds so the pilot signal goes up and down with that.
I can either disable that check in the firmware altogether or increase the timeout. Increasing the timeout is easy; if that doesn't have the desired effect I'll disable it altogether. I'm also using the opportunity to prevent another problem, which, if I may believe people with more experience in the field, could occur with old Leafs and/or car chargers with old firmware, which is that charging with 16A (the max for the AC car charger) could result in damage of the car charger. I've set the MAX_CURRENT constants to 15A to prevent someone from accidentally selecting 16A.
The proper way to go about this of course is to upgrade the car charger's firmware. But, unfortunately for me, Nissan is not really interested in their New Zealand customers driving 2nd hand Leafs so upgrading the car charger's firmware is not an option for me.
Thanks to the good folks who created the OpenEVSE hard- and software open source, I'm not stuck but can change the firmware to create a workaround for this problem.
Regarding programming the board.... unfortunately the changes you're suggesting are still resulting in "recipe.preproc.macros pattern missing". Here are the contents of the boards.local.txt and corresponding contents of boards.txt (for the Uno that does compile):
UNO
uno.name=Arduino/Genuino Uno
uno.vid.0=0x2341
uno.pid.0=0x0043
uno.vid.1=0x2341
uno.pid.1=0x0001
uno.vid.2=0x2A03
uno.pid.2=0x0043
uno.vid.3=0x2341
uno.pid.3=0x0243
uno.upload.tool=avrdude
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.maximum_data_size=2048
uno.upload.speed=115200
uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0xFD
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex
uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.board=AVR_UNO
uno.build.core=arduino
uno.build.variant=standard
OpenEVSE with hardware programmer
openevse.name=[Programmer]OpenEVSE
openevse.upload.tool=avrdude
openevse.upload.maximum_size=32768
openevse.upload.maximum_data_size=2048
openevse.build.mcu=atmega328p
openevse.build.f_cpu=16000000L
openevse.build.board=AVR_DUEMILANOVE
openevse.build.core=arduino
openevse.build.variant=standard
openevse.menu.cpu.atmega328=ATmega328
I've tried many combinations... even to the point where the openevse entries are the same as the entries for the UNO... still failing. Note: I've tried your suggestion:
openevse.build.core=arduino:arduino
openevse.build.variant=arduino:standard
but that made no difference whatsoever.
Jan
NEW ZEALAND
Hi Craig,
Update.
I now realise that in addition to the boards.txt in the Arduino program directory (in my case /opt/arduino-1.8.10/hardware/arduino/avr/, the IDE also looks in a user specific directory (on Linux that's ~/Arduino/hardware/avr/1.6.15). So I have boards.txt, boards.local.txt in two different locations. Removing those in ~/Arduino/hardware/avr/1.6.15 and adding the openevse entries to /opt/arduino-1.8.10/hardware/arduino/avr/boards.txt doesn't help... now the [Programmer]OpenEVSE entry doesn't even show up. Rather confusing... anway, I'm now repeating experiments with boards.txt and/or boards.local.txt in ~/Arduino/hardware/avr/1.6.15.
This results in "The current selected board needs the core 'arduino:arduino' that is not installed. Changing it back to "arduino" results in the dreaded "recipe.preproc.macros pattern missing". Those jolly "recipes" are in a file called "platform.txt" and I cannot correlate the entries in that file with the entries in boards.txt or boards.local.txt.
After another 30 minutes fighting with this, I'm still hitting the same brick wall.
Glad I'm not alone in this :-)
Jan
Missed the part about not being able to compile in the early (or late) hours of the night.
Sounds like you're dealing with differing versions of the Arduino IDE, which can have implications outside being able to compile. ref #107
And the readme:
Current official build tools version is Arduino AVR Boards by Arduino v1.6.15. You can install any version of the GUI, but make sure to use that version of the build tools, as it was used for UL certification. WITH LATEST CHANGES, v1.6.15 results in a sketch that's too big (>32768). MUST DISABLE FEATURES TO BUILD A COMPATIBLE SKETCH.. disabling RAPI_WF does the trick. -> Currently testing v1.6.23, which builds a sketch that fits, even when all options enabled. FOR DEVELOPMENT ONLY UNTIL FURTHER TESTING IS DONE
Hi Craig,
Thanks for bearing with me. Unfortunately I still can't compile this thing out of the box. Can you share the link where you found your suggestion on the Arduino IDE Github? Maybe this works differently on Mac. And yes, I know I have to restart the IDE every time I make a change to those files. IMHO the IDE should simply re-read the files if the time stamp has changed since last startup, but hey :-) ... I also think this shouldn't be as hard / illogical as it seems to be.
I'll remove all user specific directories, re-install the Arduino IDE and then will not follow the instructions from the devs (drop these files in this directory) but instead will add the OpenEVSE entries to boards.txt
Are you sure the local path is ~/Arduino/hardware/openevse/avr/boards.txt, not ~/Arduino/hardware/avr//boards.txt (ie. ~/Arduino/hardware/avr/1.6.15/boards.txt) ?
kind regards,
Jan
Hi Bjorn,
I don't understand what you're suggesting. Are you able to compile the OpenEVSE code with the Arduino IDE? If so, can you please share in which place(s) you have boards.txt and/or boards.local.txt and or programmers.txt?
Re the version of the IDE... I've read in multiple places that the version of the IDE Is irrelevant; only the version of the build tools is relevant; I'm using that is recommended (1.6.15).
Jan
Hi Craig,
Started from scratch. Your suggested changes result in "The current selected board needs the core 'arduino:arduino' which is not installed". Reverting back results in the same brick recipe wall.
Jan
Indeed, tools not IDE. My bad, but if you could compile for Uno it would suggest it generates more compact code as it shouldn't fit in the Uno that reserves 2k for the bootloader?
I compile it with PlatformIO currently, but yeah, a month or two ago I was still using Arduino IDE.
But if you can compile it for Arduino Uno, just grab the .hex file without the bootloader and flash that. Its the same processor, difference is just the [Programmer]OpenEVSE allows you to use the whole flash before the IDE says you run out of flash, and possibly the fuses but they don't matter if you run avrdude and only flash the firmware. But I'd be wary of the above issue with versions and the reduced size.
Edit: Either I changed the Uno definition to uno.upload.maximum_size=32256 and forgot; or this is now the default, which could explain why you could compile for Uno even if the size should exceed the Uno with bootloader?.
Anyways, try this.
- Turn on Show verbose output in ✅ compilation on File -> Prefrences.
- Compile for board
Arduino Uno - Scroll up and find something like
Using board 'uno' from platform in folder: C:\arduino-1.8.9\hardware\arduino\avr
Using core 'arduino' from platform in folder: C:\arduino-1.8.9\hardware\arduino\avr
- Copy
boards.local.txtandprogrammers.txtfromOpenEVSE\arduino\1.6.15toC:\arduino-1.8.9\hardware\arduino\avrsubstituting your actual paths. - Restart IDE
- Compile for board
[Programmer]OpenEVSE - Profit?
Hi Craig, all,
FYI I went back to the Arduino IDE 1.8.9 and that compiled the firmware OK. I'll see if I can find a difference in a config/ini files between 1.8.9 and 1.8.10 that could explain this. Maybe the version of the IDE is relevant after all, contrary to what has been suggested elsewhere.
New firmware is loaded on the OpenEVSE controller and as far as I can see it's all working, will test this tomorrow when the car will need another charge.
Thanks for your help, it's much appreciated.
kind regards,
Jan
Just out if interest I did the opposite; tried 1.8.10, and the same procedure worked, no files changed.
Using board 'openevse' from platform in folder: C:\arduino-1.8.10\hardware\arduino\avr
Using core 'arduino' from platform in folder: C:\arduino-1.8.10\hardware\arduino\avr
So that would indicate somehow an OS related issue or gremlins?
In any case glad you got sort of sorted! 👍
Hi Bjorn, Craig,
It seems we have 3 possible locations (at least on Linux) for boards.txt:
~/Arduino/....
~/.arduino15/....
/opt/arduino-1.8.10/....
It is not at all clear to me whether the contents of the files are merged (and which one takes precedence if an entry occurs in more than one file) or whether one file takes precedence over another.
Some devs are working on updating the code and config files so different environments (in this case Platform IO and Arduino IDE) can produce the same result (binary). I think that would be a great idea :-)
Must say I've had enough of staring at those config files for a while... besides there are plenty of other things that need to be done as well.
Good luck with the testing Craig and once again thanks Bjorn and Craig for taking the time to help.
Jan
Even though Jan has his setup working now this still remains as an open issue to solve. I'll assign myself to work on it since I am very interested in solving it.
I can build with Arduino IDE 1.8.13 just fine, it uses 89% of memory (D7.0.2)
Maybe we should mention that the latest version is pretty good?