Jump to content
Genetry Solar Forums

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


Recommended Posts

It has come to my attention that the latest update for GS inverters running A.1 / B boards (1.1r5) has a bug with the "unlock" function, rendering it inaccessible.

I've spent a bit of time getting the firmware up to speed to the latest 1.2r1 to fix this (among other issues)...though I'm releasing it as 1.2r0 so I can fix any unexpected bugs without running into versioning issues.  There may well be some bugs; I haven't really delved into it deeply, but at a quick test everything appeared to be working.

This gives all of the latest WiFi functionality and features to the A.1 / B Genetry inverters.

 

and yes, @AquaticsLive I need to work on getting this to the PJ WiFi upgrade inverters as well...!

Link to comment
Share on other sites

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 😉

 

@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...

Link to comment
Share on other sites

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

 

@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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

13 hours ago, Sid Genetry Solar said:

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!

Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

2 minutes ago, AquaticsLive said:

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.)

Link to comment
Share on other sites

23 minutes ago, NotMario said:

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

21 hours ago, AquaticsLive said:

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

Ah yes...I was referring to self-programming of the processor.  Because when the self-program or self-erase cycle is triggered, the CPU is stopped--making it impossible for the CPU to self-program while an erase cycle is in progress.  (I believe this is somewhat unusual; most other processors have to poll a flag to determine when the erase/programming cycle is complete.)

The processors program just fine with the MPLAB PICKit3.  It's just the self-programming that is completely nonfunctional...and confusing me to no end.

Link to comment
Share on other sites

1 hour ago, Sid Genetry Solar said:

The processors program just fine with the MPLAB PICKit3.  It's just the self-programming that is completely nonfunctional...and confusing me to no end.

Thanks for explaining, yeah that would drive me nuts too.  Learning from you always I will have to read and learn more about that.  I bet I could chain program these old machine boards if I could figure out how it works. 

Link to comment
Share on other sites

22 hours ago, Sid Genetry Solar said:

Ah yes...I was referring to self-programming of the processor.  Because when the self-program or self-erase cycle is triggered, the CPU is stopped--making it impossible for the CPU to self-program while an erase cycle is in progress.  (I believe this is somewhat unusual; most other processors have to poll a flag to determine when the erase/programming cycle is complete.)

The processors program just fine with the MPLAB PICKit3.  It's just the self-programming that is completely nonfunctional...and confusing me to no end.

Ii can't wait to get my inverter because I wan to install my samlex evo 3012 in my Jayco 3200SL with 6 set of lifemnpo4 

Link to comment
Share on other sites

On 4/29/2023 at 12:08 PM, Sid Genetry Solar said:

You referring to JTAG?

I am in the reading and learning phase, to be honest I have never considered any of those features.  The boards have an extra flash chip on them that is not be utilized, so there are some options to look at for a fail-safe options.  Not a priority right now but nice to learn more, but can't use too much time tinkering on the company dollar.

Link to comment
Share on other sites

40 minutes ago, AquaticsLive said:

I am in the reading and learning phase, to be honest I have never considered any of those features.  The boards have an extra flash chip on them that is not be utilized, so there are some options to look at for a fail-safe options.  Not a priority right now but nice to learn more, but can't use too much time tinkering on the company dollar.

Well, if I understand it correctly, JTAG allows programming of any number of devices on a board from a single port.  (All the devices have to support JTAG, of course.)

I've never gotten into processors powerful enough to use JTAG--well, except for the ESP32, although I've never had to JTAG it due to the bootloader allowing programming via UART.

"Chain program" was what got my attention to that end.

 

What kind of boards specifically are you referring to?

I ask because someone sent me a laundromat POS board some years ago--and last year I actually was able to program it utilizing RT-Thread...and at least get the display working.  (Touchscreen was on USB...that was a bit too hard to get working!)  I had to TFTP the binary in via Ethernet after getting it into bootloader mode...

Link to comment
Share on other sites

JTAG is a standard for a kind of "puppet master" of chips on a particular board. What is does in a particular product depend on what features are exposed by the TAP.

It's probably better known for it's usage in debugging - what i used it for - reading/writing physical memory, modifying cpu registers, stepping the cpu instruction-by-instruction.

Extremely useful for debugging bootloaders, kernels, and drivers.

  • Thanks 1
Link to comment
Share on other sites

On 5/7/2023 at 6:26 PM, Sid Genetry Solar said:

What kind of boards specifically are you referring to?

They are proprietary boards but the basics are they take in a RS485 message and split it out to drive solenoids to control automation solenoids and air valves.  Very modular so each section has as board they are linked with a RS485 interface using Cat5 with RJ45 connectors.  Each board has an RS485 address with dip switches.  The programing port is an RJ11 well that matches up with the puck programmer, so easy, but need to lay on the floor under the machine and program them.  The regular RJ45 interface cables can be connected to the programming port via a jumper, but this was never implemented, so been looking into that.  This is really old stuff and I have lost knowledge on it over the years after the newer stuff has been pushed out.  Always fun to think through some ideas though.  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...