Thread: Re-engineered M2-atx firmware with fixes and added functionality

As I said earlier, I am not looking to just sell the code, except maybe to mini-box so that they can sell psu's with the code. I am somewhat considering offering pre-flashed PICs that can just be dropped in for the old one if people are interested in that, but as I have a full time job and a life I am not sure whether I can responsibly commit to that service.

Since some people are wondering what is different about the functionality, the main difference between my code and the original is in the way that it keeps time. My code uses interrupt based timing, which allows me to be more flexible with the operation while the interrupts are not occurring, which is the vast majority of the time. The mini box code just sits there in (not very well constructed) counting loops most of the time, so in order to implement the delays for all the timing modes, the program jumps all over the place. I will explain better later...

One other main difference in functionality is that I implemented diagnostic error feedback by flashing codes through the LED to show what the psu is doing at different times. For example, if your computer just powers off for no apparent reason, you can look at the LED and see why. Again, I will explain more later.

Thank you all for your feedback and thoughts. Keep them coming.

I too would definitely be interested in your code. Some time back, I started the same project: to rewrite the M2-ATX code (probably in C) to clean it up and add more functionality.

I never did much work on this other than grabbing the source code (ASM) off the web and making some minor tweaks to ensure it matched exactly the binary that shipped in my M2 (read binary out of M2, disassemble with IDA Pro, modify source to match).

The features I was looking to add were:

1. Change PIC controller to 16F87 (footprint compatible) to get UART for control/status information (with suitable RS232 level translation IC).
2. Use EEPROM in PIC controller to store timing settings.
3. Add input for door unlock (from remote) to power up CPU before I get to the car.
4. Allow PC to delay shutdown (up to a limit) using serial link to allow it to sync with my media server when I get home.
5. Provide separate control over +12V output (which I use to power my LCD).

Cheers.

That sounds very interesting, where about in KY are you, I am just north of Louisville and if you need any help id be happy to if i can.

Originally Posted by mpr90

I too would definitely be interested in your code. Some time back, I started the same project: to rewrite the M2-ATX code (probably in C) to clean it up and add more functionality.

I never did much work on this other than grabbing the source code (ASM) off the web and making some minor tweaks to ensure it matched exactly the binary that shipped in my M2 (read binary out of M2, disassemble with IDA Pro, modify source to match).

The features I was looking to add were:

1. Change PIC controller to 16F87 (footprint compatible) to get UART for control/status information (with suitable RS232 level translation IC).
2. Use EEPROM in PIC controller to store timing settings.
3. Add input for door unlock (from remote) to power up CPU before I get to the car.
4. Allow PC to delay shutdown (up to a limit) using serial link to allow it to sync with my media server when I get home.
5. Provide separate control over +12V output (which I use to power my LCD).

Cheers.

Wow, that is quite a bit more functionality than I was striving for.... but it sounds like it would be very cool if it would work.... I am not familiar enough with the 16F87 to know if it would allow all the functionality you describe while maintaining the current functionality of the PSU because all of the IO pins are used in certain ways and can't be shifted around. You might be able to lose some of the jumper configuration and wire up to those pins (Rb0-Rb3 on the 818/819)... I will be glad to help in any way that I can if you do decide to go for it.

Originally Posted by meryan00

That sounds very interesting, where about in KY are you, I am just north of Louisville and if you need any help id be happy to if i can.

I am in Lexington. Thank you for the offer, I will let you know if I think of anything. Maybe your carputer can be the second guinea pig! (I debugged the code on mine)

wow, the plot thickens..

I like the idea about changing the pic and adding functionality, this then becomes an upgrade of the M2, kind of like the eyeR for the fusion brain.

Ok, I am home and have a chance to read through the code and remind myself what I did... I am going to post the features of my code and try and point out differences from the original (if I remember what the original did). I am sure I will think of more as I go and as people respond, so I will try to edit this post with all pertinent functional info.

First, I am going to state that the current extent of my testing is only on my carputer and only on the bench using a desktop PSU to simulate the battery.... I have made the code deal with every error situation that I can think of that may occur due to the way the PSU operates and it works on my computer. Obviously new code cannot fix problems with other components misbehaving or misuse such as trying to supply power outside the specs of the circuit components, motherboards that do not comply to the ATX specification, or wiring mistakes.

Functionality:
The power supply is designed to behave just like a power supply... The only difference from a standard power supply is the startup and shutdown capabilities based on assumptions that the psu might be used in a car. The motherboard does not know or care that it is being used in a car, and so the power supply ultimately must conform to the ATX specification because that is presumably what the mobo expects... See

http://www.formfactors.org/developer...X12V_1_3dg.pdf

This is one aspect of potentially improved reliability from my code. I know that the timing for the power to the motherboard complies with the requirements described in section 3.3 from a logical standpoint. I can't currently prove that the original code does or doesn't so perhaps mini-box can chime in if they claim that it does. Whether the M2 can regulate voltages to within the spec is a matter of the circuits used and not the PIC logic, so it is out of the control of the code.

From a startup and shutdown standpoint, the code is designed to respond to ignition signals and perform the logical startup and shutdown procedures. On top of that, it must not hang in power on and drain the battery or hard cut power in a normal shutdown of the computer. The trickiest aspect of the behavior in startup and shutdown is actually how you deal with power button presses during certain states of the computer and ignition. In my opinion, even if the ignition is on, a power button press should do something to the computer (dependent on OS settings) and the psu should not conflict with that functionality.

The code does allow selecting either "dumb" psu behavior or various startup/shutdown controlled modes according to jumper setting. The dumb psu mode acts just like it should. It applies power when the motherboard asks for it (which normally happens on a mechanical button press) and removes power when the motherboard says stop. It monitors the regulated voltage to make sure the psu is working properly (which the mini-box code hints at but does not implement in the available source) but does not monitor the battery voltage.

In startup/shutdown assisted modes, the code implements autolatch, amp delay, power off delay, and hard off delay just like the original code, but with more precise timing and better monitoring of the psu voltage and battery voltage. I also implemented the sleep function on the PIC to further reduce power consumption when the psu should be in its lowest power state (which the mini-box code doesnt do).

The other big functional aspect that is added is state feedback including error codes. It is much easier to diagnose power problems (including those not related to the psu) if you know what the power supply is thinking. I use the LED to flash codes that tell what the psu is doing at all times, so you can literally watch it go through the boot process, know when it is autolatching, know when it turns the amp on, know when it is monitoring the battery, know when it is in standby, know when it is in low power state.

Check it out: [media]http://www.youtube.com/watch?v=obgHWGjQisg[/media]

Furthermore, if your computer has any unexpected behavior (shut downs, reboots, etc.), the psu will flash an error code before resuming normal operation.

Configuration:
The jumpers are still used to set the desired timing scheme similarly to the original intent. I added code to permit all combinations of jumpers (I have no idea why mini-box wouldn't add more options by default because it is free and makes people happy) and the values are set in code but fully customizable within reason. The possible timing values are

autolatch: 1 to 255 seconds (I chose to implement 45, 60, and 90 seconds as choices)
amp delay: 1 to 255 seconds (I chose to implement 10, 20, and 45)
off delay: 1 second to 255 minutes, depending on jumper D (I think the most common are 5, 15, and 30... see explanation)
hard off: 1 to 255 minutes (I chose to implement 1, 60, and 120)

The addition of configurable autolatch and amp delay is added functionality to help give more options if your computer doesnt boot as fast or slow as most people. The off delay is counted either in seconds or in minutes depending on the state of jumper D. For example, you could choose a configuration where the computer shuts down 1 second after the ignition goes off or you could choose one where it stays on for 15 minutes after the ignition goes off if you like to make frequent stops and don't want to shut down the computer each time.

Behavior:
The behavior is, for the most part, exactly as mini-box intended it to be. If there are no jumpers, it behaves like a normal ATX psu. If there are jumpers present, it basically goes through the following cycle:

monitor ignition
when ignition turns on, send a button press to the motherboard
when motherboard requests power, start power
after certain amount of time, turn on amp
after autolatch, start monitoring ignition again for shutdown
...
monitor shutdown catalysts (ignition, mobo power, psu function, battery voltage)
(repeat)
...
if ignition goes low, simulate button press
if psu not functioning properly or battery voltage low... shutdown gracefully and signal error
if mobo says stop power, shutdown to 5v standby
monitor battery voltage
after certain amount of time, turn off 5v standby
monitor ignition

Summary of Improvements:
Lower power consumption in low power state
PSU voltage monitoring
More responsive battery and mobo monitoring
More flexible timing options
State and error feedback

That was a mouthfull...kudos if you read it all...

Tomorrow I will try and do a kind of video demonstration and post it on Youtube, I guess... You will be able to see that the 5 second startup is much shorter (I chose a better way to account for engine cranking, I think) and see what I mean by the LED feedback. I want to get a video of the old code for comparison but it may take me a little bit longer to program a PIC with the old code for "Windows being retarded" reasons.. MPLAB works under wine but I don't know about the program that I use to program my PICs, so we'll see!

wait.. so are you saying the original code for the m2 does not monitor battery voltage? This would be an asbolute outrage to me