OpenEVSE notes

Ongoing discussion of anything not related to Nissans or diesels.

Moderators: goglio704, Nissan_Ranger, kassim503

Post Reply
User avatar
asavage
Site Admin
Posts: 5349
Joined: 15 years ago
Location: Duvall, Wash.
Contact:

OpenEVSE notes

#1

Post by asavage » 11 months ago

An EVSE (Electric Vehicle Supply Equipment) is a charging station, not a charger. It supplies AC current, typically from 120v to 240v (but can run up to at least 277v in single/split phase, and 400vac in three-phase (Europe, etc.) systems.).

Residential EVSEs are almost always for Level 1 (L1, 120v) and Level 2 (L2, typically 240v) charging.

For L1 & L2, the actual charger is onboard the vehicle.

There are a LOT of mfgrs of EVSEs. I bought an OpenEVSE charging station for my first EV in Aug2017, for $600 for the Advanced version, assembled -- I did not have the time to assemble myself, though I would have loved to.
EVSE_01b.jpg
Where I park the RAV4 EV. The tree on the corner has since been removed, as it was fouling the garage's foundation.
EVSE_01b.jpg (3.48 MiB) Viewed 369 times
EVSE_02b.jpg
EVSE_02b.jpg (3.43 MiB) Viewed 369 times
EVSE_03b.jpg
EVSE_03b.jpg (2.74 MiB) Viewed 369 times
EVSE_04b.jpg
EVSE_04b.jpg (1.95 MiB) Viewed 369 times
It has the WiFi option board, but until this week, I'd never explored it.

I want to use features of this OpenEVSE to tailor the charge start time every night. My goal is to have the battery charged just before I'm ready to depart. The car's onboard scheduler is too conservative, often completing a charge three hours before I leave, and if I try to fool it by changing the departure time, the pre-climate feature has to be disabled.

The OpenEVSE can circumvent the vehicle's scheduled charge feature. I can put the car in "charge now" mode, and schedule the EVSE when to turn on, to more precisely control charge start time than the car's scheduler allows.

Like most appliances these days, the OpenEVSE has a CPU: Atmel MEGA328P. It has firmware. It shipped with 3.11.1; current is 5.0.1.

The WiFi option board has it's own CPU, ESP8266-12F, and its own firmware that also is out-of-date: current is 2.8.2 . It's an AdaFruit unit.

The WiFi CPU's firmware is (usually) upgradeable via a web interface: typical. I ran through the procedure, but finally could not get it to tell me the version of the uploaded firmware, and it wouldn't work correctly after that.

The EVSE's main module's firmware cannot be upgraded via a web interface; wires are needed.

I got to the point where I had to remove both CPUs from the OpenEVSE's enclosure, connect them to a PC, and re-flash them. Argh, the learning curve. Below summarizes the successful path I took; not necessarily an optimized path, but I'm leaving out most of the cruft of wrong turns I took along the way. This is a recipe, probably not the best recipe.

This is an all-Linux recipe (Ubuntu 18.04, in my case).

The WiFi module firmware
The WiFi's ESP8266 has to be flashed using the serial interface. On modern PCs, this requires a USB<->serial (not RS232, which is 5-25v) 3.3v signal level converter, and the better ones use an FTDI IC to facilitate the conversion. I ordered two of those, one an AdaFruit via Amazon, and another no-name via eBay (FT232RL FTDI USB 3.3V 5.5V to TTL Serial Adapter Module for Arduino Mini Ports). The AdaFruit unit looks great, but I've never been able to make it work. The no-name worked OK.

I had to install esptool, a Python program (instructions from github). My Ubuntu 18.04 has Python 2.7 installed, but not pypi. I think I installed esptool using:

Code: Select all

python -m pip install esptool
Now, to locate the correct USB port.

Code: Select all

asavage@Ubuntu1:~/Downloads$ dmesg | grep tty
[ . . . ]
[790893.659693] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
asavage@Ubuntu1:~/Downloads$ 
My FTDI-chipped USB<->Serial converter resided at /dev/ttyUSB0

There are a couple of different ways to allow access to the USB<->serial converter, but for a one-time thing, chmod worked.

In order for the ESP8266 to use its serial interface to input flash data, you have to put the chip in flash mode, by grounding the GPIO0 line on powerup. The Adafruit WiFi module conveniently has a tactile switch to do this.

Assuming you have the flash data file in Downloads . . .
In a terminal window, preload these two lines into the terminal buffer:
  • sudo chmod 666 /dev/ttyUSB0 (<-May have to type password, if the last sudo has gone stale)
  • esptool.py --port /dev/ttyUSB0 -b 115200 write_flash 0x00000 firmware.bin (<-this will not complete, but that's OK).
On the WiFi module:
  • Press the flash button and hold it down
  • Plug in the USB<->Serial converter
  • Continue pressing the flash button
  • In the terminal window, scroll back and run both the above commands, in that order
  • Results: see below

Code: Select all

asavage@Ubuntu1:~/Downloads$ sudo chmod 666 /dev/ttyUSB0
[sudo] password for asavage: 
asavage@Ubuntu1:~/Downloads$ esptool.py --port /dev/ttyUSB0 -b 115200 write_flash 0x00000 firmware.bin
esptool.py v2.7
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 5c:cf:7f:19:92:42
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 705152 bytes to 399582...
Wrote 705152 bytes (399582 compressed) at 0x00000000 in 35.3 seconds (effective 159.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
asavage@Ubuntu1:~/Downloads$
115200 baud seemed to be required; I was unable to use 9600.


The OpenEVSE main module firmware

The OpenEVSE's main module uses the Atmel MEGA328P, which is an AVR microcontroller, and uses In System Programming (ISP) (or In-circuit Serial Programming: ICSP) to update its code, using the board's Serial Peripheral Interface (SPI). I purchased an AVR programming tool from the OpenEVSE online store, but though they accepted my order on Wednesday, I received no tracking info until I emailed them Friday asking for it, and then they returned a USPS tracking number that shows they haven't actually shipped it yet (Sunday night). Sigh. After calling around a bit to try to find an alternate AVR programming tool locally, I fell back to Amazon: ordered Fri. night, dropped at my locker Sunday morning. I purchased a Waveshare Atmel AVR ISP programmer for $42. It worked perfectly, and after checking the pinouts of it and the OpenEVSE's main module's SPI header pinout, they matched, so I didn't even have to get out the jumpers.

The Waveshare's docs warn that it won't power the unit to be programmed, so I used power from one of FTDIs to run the main module.

I had to install avrdude.

Code: Select all

sudo apt install avrdude 
I also installed libusb-dev, but in the end I'm not sure that I needed it.

Code: Select all

sudo apt install libusb-dev
OpenEVSE has a guide to performing the firmware upgrade to the main module, but it's Windows-centric. The firmware releases are here. The pre-compiled firmware has a .bat file which contains clues on how to proceed, though.

These lines are the meat of it. I only had to substitute "avrisp2" where the orginals contained "USBasp". The Waveshare AVR ISP programmer is a clone of an Atmel AVR ISP mkII, which uses the parameters in avrdude.conf associated with avrisp2.
  1. avrdude -c avrisp2 -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0x04:m
  2. avrdude -c avrisp2 -B0.5 -p m328p -V -U flash:w:open_evse.hex
  3. avrdude -c avrisp2 -p m328p -V -U eeprom:w:eeprom_24.bin -V
A note about the first line: There is a complaint about efuse:

Code: Select all

avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x04:
avrdude: load data efuse data from input file 0x04:
avrdude: input file 0x04 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfc != 0x04
avrdude: verification error; content mismatch
Based on this discussion I ignored this error:
oPossum wrote:Bits 3 to 7 of efuse will always read 0 - they are not used.

So 0xFC (1111 1100) is the same as 0x04 (0000 0100)
Bits 0-2 are to enable/disable Brown Out Detection (BOD), and if enabled, to set the voltage below which the AT328P will not run. The OpenEVSE code sets it to only run when the supply voltage is above 4.3v .

Atmel_at328p_BOD_chart.png
Atmel ATMEGA328P Brownout Detection voltage chart.
Atmel_at328p_BOD_chart.png (23.37 KiB) Viewed 365 times
The default for this chip is/was 0xFF (B1111 1111) (opinions vary), or different programming tools/versions read-back an unset bit (which on this device: unset = 1) as either 0 or 1, so depending on the tool and version and age of the chip, one might get 0x04 or 0xFC.

See this post for more.

It's even possible that the WinAVR version of avrdude, and the Linux version read-back unset bits differently. I'm not chasing it down further, I'm happy with it working.

=================================================

A couple of reference pics from Oct2019:
OpenEVSE_Advanced_Oct2019_01b.jpg
OpenEVSE Advanced v4 hardware
OpenEVSE_Advanced_Oct2019_01b.jpg (1.62 MiB) Viewed 49 times
OpenEVSE_Advanced_Oct2019_02b.jpg
OpenEVSE Advanced v4 hardware
OpenEVSE_Advanced_Oct2019_02b.jpg (2.04 MiB) Viewed 49 times
Regards,
Al S.

1982 Maxima diesel wagon, 2nd & 4th owner, 165k miles, rusty & burgundy/grey. Purchased 1996, SOLD 16Feb10
1983 Maxima diesel wagon, 199k miles, rusty, light yellow/light brown. SOLD 14Jul07
1981 720 SD22 (scrapped 04Sep07)
1983 Sentra CD17, 255k, bought 06Jul08, gave it away 22Jun10.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests