How to flash

[jbakuwel]

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:

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

[beikeland]

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.

[craigk46]

Jan, I think I can help. I just worked on overcoming the same difficulties with Arduino. I will create the proper documentation and submit a pull request soon so that you and everyone don’t run into this same brick wall.

Regarding getting a clean compile within the Arduino IDE that currently results in "recipe.preproc.macros pattern missing”, you need to edit two lines of your boards.txt file, fixing these problems openevse.build.core=arduino:arduino openevse.build.variant=arduino:standard

That fix should help you with a clean compile similar to the UNO’s.

Since you have a board from the OpenEVSE store you can ignore fuses and eeprom since they are already set correctly. Also the OpenEVSE board does not have a bootloader.

To program the board you will need an ISP programmer. Most of us use this type https://store.openevse.com/products/openevse-programmer https://store.openevse.com/products/openevse-programmer or an ISP type equivalent.You should be able to get a clean compile within Arduino but it will complain with a warning of "Low memory available, stability problems may occur” and that is okay. With the programmer I mentioned you set the Arduino Programmer to USBasp. Then within Arduino you can program the board with Sketch:Upload Using Programmer <— that will run the avrdude commands for you.

Please explain the problem you want to solve in a lot more detail. You say "I still need to create a workaround for the car charger responding to slow to pilot change.”
Many experts are here to help. But your problem statement does not do a good job of telling us what you are experiencing and need to solve. Tell us what car you are charging since we may know some history of that.

What part of the globe are you in, what county or time zone?

Best Wishes, Craig K. Oregon USA

On Dec 27, 2019, at 4:45 PM, jbakuwel notifications@github.com wrote:

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 https://openevse.com/ 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 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 https://github.com/openenergymonitor/open_evse/blob/master/firmware/open_evse/LoadingFirmware.md article suggests:

avrdude -p atmega328p -c usbasp -P usb -e -U flash:w:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lincomatic/open_evse/issues/113?email_source=notifications&email_token=ACV4NHLULWULI4KFOQ3SILDQ22OUHA5CNFSM4KAEQA2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IC6AKLA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACV4NHLSIX6GHTJY4HFL2VLQ22OUHANCNFSM4KAEQA2A.

[jbakuwel]

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

[jbakuwel]

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

[craigk46]

Jan, You are going to think that I’m making this up, but trust me I found this on the Arduino IDE GitHub and it is what is working on my Mac. Name the file as boards.txt, not as boards.local.txt. Put it in your user directory under this path ~/Arduino/hardware/openevse/avr/boards.txt

Be sure those two lines in the file are modified as I instructed earlier. I think you know to close and re-open the Arduino IDE since it only reads the file once on starting the IDE.

With that you should be golden.

It sounds like you know what you are doing with the OpenEVSE code. The settings you want to change are in open_evse.h about line 170 in the file.

Best Wishes, Craig

On Dec 27, 2019, at 9:55 PM, jbakuwel notifications@github.com wrote:

~/Arduino/hardware/avr/1.6.15.

[beikeland]

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 https://github.com/lincomatic/open_evse/issues/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

[jbakuwel]

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

[jbakuwel]

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

[jbakuwel]

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

[beikeland]

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.

1. Turn on Show verbose output in ✅ compilation on File -> Prefrences.
2. Compile for board Arduino Uno
3. 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

4. Copy boards.local.txt and programmers.txt from OpenEVSE\arduino\1.6.15 to C:\arduino-1.8.9\hardware\arduino\avr substituting your actual paths.
5. Restart IDE
6. Compile for board [Programmer]OpenEVSE
7. Profit?

[jbakuwel]

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

[beikeland]

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! 👍

[craigk46]

Jan, I’m glad to read you have it working now. Mine Is IDE 1.8.10. I’m completing a lot of testing that is suggested by others. I still need to test the stuck contact test and run though all of the remote commands. So far it is working fine and proven to charge Leaf, Chevy Volt, and Ford Focus and Fusion.

I think the ultimate solution to this multi-platform + multi-version of IDE confusion is to handle the addition of the OpenEVSE board through a URL pointing to the .json file. That is the approach the pros take.

I need to study that part of the Arduino environment to finish the task. It will take me some weeks finding free time.

Best Wishes, Craig

On Dec 28, 2019, at 3:42 PM, Bjørn notifications@github.com wrote:

 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! 👍

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jbakuwel]

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

[craigk46]

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.

[dalathegreat]

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?