wiseguy
Guru
Joined: 21/06/2018 Location: AustraliaPosts: 1156 |
Posted: 03:54am 07 Jun 2024 |
|
|
|
Well there is more to the story of the LCD's failure to function. There are two different types of failure modes I have now found. In redoing the tests I did last night and early this morning I discovered the second failure state of the LCD display.
With the slowly reducing voltage at around the critical threshold the LCD can just display the "black digit blocks" but from this point there are two scenarios. The first is that a power down and restart of the system causes the LCD to resume normal operation.
The second more insidious failure is that a power recycle does not restore normal operation of the LCD requiring the code to be re-uploaded to it.
At this point, to avoid a lot of reading feel free to skip to the Executive Summary.
My forte is not in uC's (microcontrollers), their internals or for written code. I have been reluctant from the word go about the wisdom in using a uC for inverter operation. The problem is twofold, firstly the success or failure of the project is a direct reflection of the quality of the written code and the code writers knowledge about the uC strengths, weaknesses foibles and keeping up with the errata updates. I can solve hardware problems but I also have to rely on software & uC experts when the issues are under the hood of the uC. Secondly there are also hardware issues that can cause unexpected results in the uC and they can come from a variety of causes.
I see the main issues as not being that using a uC is a bad thing, if they work as intended life is good, but I am releasing my control over a successful project outcome to other parties and I become reliant on them now if there are issues. I acknowledge that a hardware issue caused by me could drag their efforts down too. But when there are issues, finding the root cause and fully understanding the problem is paramount to solving it. So with the fault, what is cause what is effect and how do we reach into the internals of the uC to see what happened in the black box which no longer does its job.
In the past I have used in circuit emulators and all sorts of similar tools to resolve issues, but at this stage of my life I am reluctant to try to solve the Nano problems because simply I am a bit out of my depth. I no longer have the tools the support or the will to solve these types of issues on my own. I can do a bit more testing using the pins available from the micro such as an external hardware reset that operates from 1.5V upwards and holds the Nano in reset until the 4.6 V or whatever the supervisors threshold for normal operation is. Maybe it can be solved with this but if not, we do not have a solution yet. (which solution for what problem??)
I also read conflicting articles about EE code becoming faulty (corrupt) and its causes and there are many ways to do it from buffer overruns, stack overflows, power supplies that can wake a processor and cause unknown internal operation, as it never achieves the normal rail voltage so the BOR (brown out reset) is never triggered and throw into this imperfect code or understanding of the micro's internals and I am sure you can see the problem. I have been using and designing in microcontrollers since about 1987, but I often have worked in collaboration with other engineers along the path. I always have used specialist software engineers to write code, my abilities start to fall short after developing test code stubs to exercise ports and bits and encoders decoders etc. Yes we used to do that, now micros mop up a lot of that stuff internally.
The last comment to make is that for the Wiseguy/Poida/controller/Inverter/LCD, only 50% in the field work. That is KeepIS and Dex, KeepIS has had no failures or issues to my understanding and yet Dex has. Ok to be fair Poida and I also have powered up the controllers and LCDs hundreds of times without a single failure or glitch where a Nano needed code to be reloaded.
The dilemma I now face is am I fixing/chasing a problem that only one person has and maybe no one else will ever see it? Dex has made comments about the amount of electrical noise in his cabinet with all the MPPTs and inverter running. Is this interference also part of the problem ? Poida has worked hard to create robust reliable code, KeepIs has done the same extending on Poidas code to include features and performance that meets with his needs and expectations and LCD screen.
My understanding is that KeepIS has uploaded a hex copy of the Inverter and LCD codes to the Nanos with no bootloader and then no amount of fiddling with power supplies has caused a code crash that needed new code to be uploaded, this is encouraging.
Executive Summary So I have arrived at a conclusion and that is there will be no modifications to the inverter or LCD display hardware. I will recommend (ask) to Poida that his code is released as hex files to the forum (no bootloader) to be uploaded to the Nanos. This has two effects no one can reverse engineer the code and steal the IP within it and the bootloader cannot have the power to overwrite code space. KeepIS might also do the same with his code for anyone that wants to try something different. These are my thoughts and both or either might flatly refuse.
I would also suggest that at Poidas discretion he may be (reluctantly?) prepared to release his listing if someone asks for it but that would be totally at their risk if they change anything. I did blow my FETs by going down this path once.
I will however continue to see if a voltage supervisor can easily be retrofitted to the Nano module - and only when it proves to stop the code amnesia. I will also try a linear 5V regulator instead of the switching unit to see how it performs - at this stage it could be the only component change I might recommend. I realise that these improvements to the onboard power supply might become redundant if the hex files minus bootloader fixes the susceptibility to the inverters decaying power supply.
Closing comment yes I can induce errors to the display by purposely fiddling with the power source and trying to make things play up - and they do, but I have not experienced Dex's problems with the display during my normal operation.
Sorry for the last few longish posts. Edited 2024-06-07 14:02 by wiseguy |