Firmware update to 1.2r0 for A.1 / B GS inverters

I can't knock the older boards...my house inverter STILL has a GS A.1 board in it, running 1.1r5.  Has 22,024 hours and 3,614kwh on it.

Can't knock the C board either. Have 11,000+ hours and 4.5Mwh on it. Lots of that spent in the deep freeze, too.

Found a bug in the 1.2r0 for A.1/B GS firmware update...I put it on my house inverter, and pretty quickly found that the power save function no longer works!  Turned out to be something I'd copied from the Rev. C code that was not applicable to the Rev. A.1/B code.  On the A.1/B boards, the WiFi board has to be responsible for power save, as the control board doesn't have power monitoring on both output L1 and L2.  Whereas on the C boards, the control board has total power monitoring--and handles power save by itself.

Very easy fix.  If this is affecting anyone, please let me know...I'll send out an update.  Honestly, I'm not sure anyone's taken this update 😉

<a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/13-aquaticslive/?do=hovercard" data-mentionid="13" href="/profile/13-aquaticslive/" rel="">@AquaticsLiveI looked at the "WiFi LCD upgrade" code, and it turns out that I already got it "up to speed" with the shared code...so if I can get a day without something else really pressing going on, I might be able to get the (significant) WiFi upgrades over to the PJ "upgrade" branch too...

On 4/15/2023 at 3:57 PM, Sid Genetry Solar said:

 

<a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/13-aquaticslive/?do=hovercard" data-mentionid="13" href="/profile/13-aquaticslive/" rel="">@AquaticsLiveI looked at the "WiFi LCD upgrade" code, and it turns out that I already got it "up to speed" with the shared code...so if I can get a day without something else really pressing going on, I might be able to get the (significant) WiFi upgrades over to the PJ "upgrade" branch too...

That is great news.  I am home Friday 4/21 to Monday 4/24.  I will be back too after that later in the week.  The inverter is sitting idle when I am home.  So whenever you have something you want to test let me now.  I will stay logged in to the forum and watching.  Been a out of forum for over a month been so busy things are slowing down finally getting back to some maintenance around my home area. 

On 4/20/2023 at 7:23 PM, AquaticsLive said:

That is great news.  I am home Friday 4/21 to Monday 4/24.  I will be back too after that later in the week.  The inverter is sitting idle when I am home.  So whenever you have something you want to test let me now.  I will stay logged in to the forum and watching.  Been a out of forum for over a month been so busy things are slowing down finally getting back to some maintenance around my home area. 

Well, I tried to see if I could get the "PJ" firmware to work (GS WiFi board in a PJ inverter).  Looks like I've an updating-style problem to sort out before the firmware is good to go...plus an odd bug or two.  If I can't get it sorted in an hour or so tomorrow evening, then I unfortunately may not be able to get to it until next Saturday.

only issues I've seen so far have to do with the local and remote servers incorrectly registering battery voltage.  Which was a super simple issue to resolve (code regression due to a feature request on the Rev. C boards).  Oh, and generator control buttons not being hidden on the local (and remote) servers--PJ inverters don't have any hardware that could even be used for genstart.

Thanks for the update.  I am sure the its busy as heck over there too trying to manage multiple jobs.  Take care man!

I was able to allot an hour or so to trying to diagnose the issue yesterday...and let's just say that I'm pretty well stymied.  I am so certain that I had updates working on the PJ WiFi addons...but for some strange reason, the CPU's self-program routine appears to be completely nonfunctional.  In the weirdest type of way, too.  (I've tried 3 separate CPU boards, all with exactly the same result.)  It is doing the expected erase/program delays--but is not actually changing the program FLASH.  For example, I should be able to pull the "CPU cable" midway through programming to "soft brick" the CPU (i.e. won't start when powered on due to incomplete application program)--but even that doesn't work!  It powers up like nothing happened.

This is really gonna bug me...but unfortunately my week's schedule isn't going to let up until Saturday.

So the erase calls aren't happening or they aren't working. 😄
Or they're not acting on the correct location.

Fun times.

Hmm I had something similar where I starting writing to flash prior to it finishing the the clear operation the fix for me was to put a bit of a delay before writing and ensuring my clear size was exceeding the previous version.  My previous versions didn't have this problem because I was always making it slightly larger.  Not sure what PJ's chip is though, but I thinking it might be similar to pic. 

It's a PIC18F87K22.  GS inverters utilize a smaller chip in the same family--which is why the programming issue is doubly mystifying: GS boards reflash perfectly fine with the exact same WiFi board.  And as both chips are in the same family, the bootloaders are basically identical (apart from chip specifics).

The issue isn't that the programming is getting corrupted or otherwise--that would be a much easier issue to sort out.  The issue is that both the erase and program operations seem to be doing absolutely nothing!  The hardware timeout delay is clearly visible on the 'scope...so the functions are getting called.  But the memory isn't getting cleared, and it isn't getting set: it's remaining unchanged.  (How block verification isn't failing, I have absolutely no idea.)

There's no A<->B concept on those things, i take it?
Aka, writing to A, but booting B. Kinda doubt it for the use case, but sometimes engineers like to over-engineer.

Correct.  These PICs are too small and too simple for that (which is why a failed program cycle should "brick" the CPU).  From a processor standpoint, there are no relative jump/call instructions...so all code is absolute, not relocatable.  (In other words, it's technically impossible to have dual boot partitions.)

ESP32 does have just what you mentioned, though.  But it's also a powerful 32-bit processor.

13 hours ago, AquaticsLive said:

Hmm I had something similar where I starting writing to flash prior to it finishing the the clear operation

This is not possible on the Microchip PICs: when an erase or row write operation is started, the CPU is halted until the erase/write operation is complete.  This is how I can see that the erase/write operation is in fact being run: there's a delay between the bootloader receipt of the data & the bootloader's indication of success.  Said delay matches right up with the datasheet spec.

And it isn't "erasing/writing the wrong memory location": the initial erase is hardcoded to the beginning address of the application space.  Which is why this is doubly mystifying.

18 hours ago, Sid Genetry Solar said:

This is not possible on the Microchip PICs

I am sure we aren't talking about the same process either I use a MPlab hockey puck.

So maybe write a new blank Hex to it.  Really I have no clue how your system works so don't want to be a keyboard commando and give you stuff that isn't possible.