Test my OpenEVSE FW Ver 1.6.2 with RTC and Delay Timers

[mitch672]

The other solution is to vastly simplify the code, make it a device on the I2C bus that takes commands and reports status to another secondary processor that is in control, basically allow it to do what it's good at, be a simple EVSE, have another system control it via commands, and to handle higher level things like the menu system, timers, handling the date etc. might be time to rethink it.

 

[davewill]

Not a bad approach. That leaves a simple, trim, OpenEVSE design that can be kept pretty bulletproof. People could then use a variety of platforms for the high level interface, such as a small PC, or Raspberry Pi. Might be simpler to use the async port for command and control rather than I2C since the system already takes config input from that source.

 

[goldserve]

I just forgot to let everybody know, you must disable the boot vector option as it is no longer possible to use the Arduino bootloader with this firmware at the same time. To do this, execute this command:

avrdude -c usbtiny -p m328p -U hfuse:w:0xdb

 

[z0ner]

I just forgot to let everybody know, you must disable the boot vector option as it is no longer possible to use the Arduino bootloader with this firmware at the same time. To do this, execute this command:

avrdude -c usbtiny -p m328p -U hfuse:w:0xdb

What would be the ramifications if this weren't done?

 

[goldserve]

The code does not load and the microcontroller doesn't come out of reset. Occasionally it does and I can't explain it. Something to do with power supply ramp time or brownout conditions.

 

[z0ner]

That's exactly what happened to me and garygid today after upgrading to 1.6.0. GlennD was there also, and because several of us were in various stages of completion we thought chris1howell got a bad supply of AdvPS's.

I can't program because of a separate issue (long story), but it's good to know this is fixable. Thanks for providing the solution.

 

[goldserve]

I found that if you used the DIY v4 files, the reset line from the programmer port has to be connected to the chip. There was a schematic error. I presume you are using the surface mount boards...

 

[garygid]

Since this loads, boots, and works correctly occasionally,
it would seem that it is not a space, bootloader, or fuse problem.

Instead, it might be that the firmware needs to wait longer before
deciding that the display is not there?

-----
It also appears that one cannot tell which version, and what varient
of that version, that one has loaded/running. With various people
making additions, and changes, this lack of control can become
a disaster, and give the OpenEVSE project a bad name.

Where does one get the "approved" versions, and how does one
distinguish the experimental versions? Thanks

 

[chris1howell]

Official releases are here:
https://github.com/lincomatic/open_evse" onclick="window.open(this.href);return false;

Last week lincomatic released a fix (different than goldserves method) to resolve the issue of EVSE not booting if display is not connected.

He is currently reviewing testing goldserves RTC code to be included in the official source.

 

[garygid]

That fix says it is "do not hang if the display is not detected".

Getting the display reliably detected is the issue here.

Apparently changing the startup delay from 50 ms to 500 ms
makes the display detection reliable. (from GlennD)

Both fixes are good, but the second (reliable detection) is vital.

Can that be added?
What will this new, fixed, version be numbered?

If a library is changed, where is that source located?

Thanks, Gary

 

[chris1howell]

That fix says it is "do not hang if the display is not detected".

Getting the display reliably detected is the issue here.

Thanks, Gary

Gary, are you reporting an issue with 1.0.9, which is the first version to add auto detect of the i2c address? I was not aware there was an issue with detection. All pervious versions did not auto detect at all and would lock on boot if the adafruit button was compiled in and the display with button. Was not connected.

Please confirm you are testing with 1.0.9.

 

[chris1howell]

If a library is changed, where is that source located?

Thanks, Gary

Depends on the library and the author. If you are revering to liquidTWI2 it is maintained on GITHUB by lincomatic.

 

[goldserve]

I think you guys are right about the fuse not being the issue.

I applied firmware changes 1.0.9 and LiquidTWI2 library changes but if I don't have the LCD connected, it still hangs. I have isolated the issue down to the function m_Lcd.print(m_strBuf); which is called when the program tries to print the splash screen to LCD and this still calls LiquidTWI2::burstBits16(uint16_t value) which contains the looping while(Wire.endTransmission()).

Gary, where are you applying the 500ms wait for reliable detection?

 

[garygid]

Well, I guess that I am confused about versions.
How does 1.6.0 relate to the 1.0.9 version?

This source says 1.6.0 as its version.
It seems the source includes the LiquidTWI2 the library, which has a delay(50)
in its Begin function. I changed that to delay(250) to test, in LiquidTWI2.cpp

I will try to load it soon, and report.

This seems to be different from what GlennD found.

Am I not finding the right library code, or starting with the wrong source code?

 

[goldserve]

Gary, 1.6.0 was a branch off the main OpenEVSE project 1.0.8. All enhancements in the mainline needs to be ported to 1.6.0 to test the real time clock functionality. If RTC is not required, please start with the 1.0.9 source.

 

[garygid]

The 250 ms delay, instead of the 50 ms, seems to work
most of the time, so I tried 500 ms, which is noticeable,
but only slightly, and works better, though still not every
time (not the first time), but much better than 1.6.0 was.

 

[chris1howell]

I think the weirdness on boot is a symptom of running out of RAM. Anytime I have stability or boot problem the first thing I do is recompile and disable a feature or two like CLI or ADVPWR to free up memory. I would bet that will fix the problem.

I would also reccomend new users to OpenEVSE start with official code until they have sufficiently tested their EVSE and are comfortable with the firmware..

I would reccomend putting to1.0.5 - 1.0.8 On your board before doing any hardware mods. I tested each board with. 1.0.5 before the first workshop and there was no issues with boot or operation. If you disable ADAFRUIT_BTN it will boot fine with or without the display attached.

I will work on testing 1.0.9 now and will post a hex file for the workshop configuration...

 

[goldserve]

I don't know what it is but I can enable all the features and it will run reliably 100% of the time on this test board with a bench supply giving it 12v.

 

[borland]

I don't see how you could run out of resources without getting compile errors.

I've only reviewed the source code briefly, but there's a warning about letting the watchdog timeout...

#ifdef WATCHDOG
  // WARNING: ALL DELAYS *MUST* BE SHORTER THAN THIS TIMER OR WE WILL GET INTO
  // AN INFINITE RESET LOOP
  wdt_enable(WDTO_1S);   // enable watchdog timer
#endif // WATCHDOG

 

[chris1howell]

I don't know what it is but I can enable all the features and it will run reliably 100% of the time on this test board with a bench supply giving it 12v.

Okay did some testing. I built an OpenEVSE Plus, added thr RGB LCD and Cronodot 3231 RTC (which works great BTW).

First I loaded unmodified 1.6.1 code.
Booted 1 time out of 10.

Then I loaded 1.0.8. To keep hardware consistent I kept RTC connected.
Booted 10 out of 10

Then I loaded 1.6.1 and disabled SERIALCLI and about 8 serial debug lines.
Booted 10 out of 10