Another ECU...

Hardware inside and outside of the ECU
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Another ECU...

Post by Horizenjob »

Here's a picture of my ECU card. I just received them in today from Advanced Circuits. Now to flesh out my BOM, order the parts and ship everything back to get assembled.

Andrey has noticed this project and been helpful with suggestion including an invite to post here. I'm just getting around to this now because basically I'm shy and it's been a great deal of effort to learn KiCad.

The basic concept here is to use a very modern chip for the CPU because the costs drop so rapidly it seems to make sense to me to start with the new stuff. I am interested in signal processing and also presenting the data these units can collect to the user in as useable a fashion as possible. So I hope that we can find things that help people understand their motors and develop them.

It would have been helpful for me to talk to you folks earlier, but I've had to go thru so much learning curve that I wanted to try to make enough progress to get me to where I could have a more intelligent conversation - still so much to learn.

This board carries the CPU chip, an FTDI USB-Serial converter and some analog filtering. It is intended to receive a plug on driver board which will use smart driver chips for the fuel injection and IGBT's. I did this to help spread risk and allow improvements without having to re-spin everything everytime. I haven't really done the math to figure out how much more it will cost to do it this way, I guess we'll see.
Attachments
ECU_CPU8b_0p2-top.jpg
ECU_CPU8b_0p2-top.jpg (248.2 KiB) Viewed 20831 times
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Another ECU...

Post by AndreyB »

Welcome & that's an impressive first post!
Horizenjob wrote:a very modern chip for the CPU
Which one exactly?

Since the board is already in your hands it's too late to discuss the schematics, looking forward first LCD blinking!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

Left quite a few details out, I had to run out the door.

I consider everything open to discussion because I would like to get this right. In real life I'm mostly a software person and it has always made sense to m to get early versions of your stuff together and running as soon as possible so you can learn about what you're doing and also make sure you are doing what needs to be done.

I don't mind sharing my schematics but I'm not sure how to do that yet. It seems that there is not the same level of copyright protection you would expect as you get with software. On the other hand there is not really much original in this work. THe big issue is probably they are just not as nice looking as I would want. I first did this design in another tool and then moved to KiCad. Somehow they became less organized in the process. For one thing, it seems you can't cut and paste parts of the schematic between pages on my MAC. I did redraw some things from scratch but got tired of that. I guess I should just go and edit the XML and not whine about it.

The chip is a Freescale 5634, it should be able to do knock sensing and ion stuff with it's built features. I would like to transistion to the next generation soon, but realistically this will keep my plate full for a little while.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Another ECU...

Post by kb1gtt »

Cool project. Feel free to share schematics and such. I can offer a review that might help make it better.

You may find this interesting, it's a PCB I did some years back that would make for a low-ish cost IO board for the $99 5634 dev board. http://sourceforge.net/p/daecu/code/HEAD/tree/Hardware/trunk/KICAD_Project_TRK-MPC5634_P3-P4-ETPU_IO_proto/

Do you have a compiler / dev environment? That's been the limiting factor for me in the past. In the past we found issues with the crank decoder's pre-made code. We couldn't get a reliable sync from the crank decoder especially for small engines or low inertia engines. The rapid rates of change between teeth was a real problem. This forced making your own decoder, but compilers were on the order of $4k+ so it kind of went by the way side. I recall FreeScale once claimed they would release a compiler but I never saw that happen.
Welcome to the friendlier side of internet crazy :)
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

Hi KB1GTT. Hmmm, can I jus call you KB1? You're probably just up the road from me, unless your north of the Bangor ferry.

Yea, I found myself wondering last week why I didn't just make an add-on for the $99 board. Long run, I think this will work better, but I hope it doesn't add too much pain.

Interesting the trouble you had with the Freescale TPU code. It's recently been updated and re-released so I hope that helps. Some of the folks I am hoping to get to beta this unit will have low inertia engines so I guess we'll find out. The reason I want to look at the next gen chips is to try to code the TPU stuff into the general purpose cores. I think the new chip has 3 CPUs on the die and they have cache and higher clock so it seems to me to be doable - but I haven't done it. I would feel better if the code was open and inspectable and playable with etc. Again, long run this makes sense.

So far I've found one little problem on the boards. The system support chip has a ground pad under it and in the KiCad footprint I put in a large pad for this with vias for thermal connection to the ground plane. I drew soldermask to tent the vias, but it didn't show up. I should have been able to see that with a gerber viewer but I had a lot of issues during submitting to the automatic DFM and I got worn out by the end and didn't notice this.

Another choice I made that I wonder about is I used a Schottky diode and also TVS diode on the analog inputs, but maybe the caps and resistors in the filter would have been enough. Those are BAS70XY and a Bussman SURGX respectively.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Another ECU...

Post by kb1gtt »

KB1GTT is my FCC issued ham radio call sign. I need to insist it be KB1GTT.

You are from Mass I see. I'm probably not to far away from you. Perhaps some day we'll see each other in person.

I suspect you are correct that you are better off with your own board. We had many issues with poor documentation for those peripheral chips. One is a kind of watch dog. It was a small pain in the dairy air to get that working, but it ended up working. The real pain was getting CAN through the CAN chip. The state machine diagram was mangled and not easy to interpreter. However we had gotten TS working with it. We basically made a USB-->CAN transceiver which would register as a COM device on the PC. Then we made the CAN chip on the 5634 board decode the CAN into a serial stream. The basic setup was that we had CAN in the middle, but both ends saw it as a serial stream.

Do you have a plan for initial programming? I believe you'll either need that $99 board, or some form of BSDM programming cable. Programming the chip for the first time might be a bit of a bugger. The $99 board has that on-board BSDM programming chip, which allows initial programming of the 5634. I understand that BSDM cables can be a bit tricky, unless you buy a commercially available cable. I should probably encourage you to have a board populated with just the 5634 and min components, then once you know you can program it, have another board populated with more components.

Might also be worth noting that rusEFI uses chibios as it's OS. The hardware abstraction layer offered by chibios makes for a more portable architecture. This OS happens to support SPC56x / MPC56xx chips. The SPC5634 the ST mate to the FS chip. Apparently OEM's require multiple sources, so this exact same chip is available from ST as well as FS. If you ported rusEFI you would likely find many tools are already developed and usable, AKA less reinvention of the wheel. The key areas you would potentially have issues with are the two different crank decoder algorithms and there may be functions that haven't been developed for chibios yet. The way that rusEFI uses timers and processing ticks is different than how the pre-made ETPU decoders work. This difference would require some significant glue code to make it work, but I believe it's do-able.

We have interest in the 5634 if for no other reason, because it offers an AEC Q100 qualified processor. We found significant issues with getting it working, and at the time we prioritized other efforts. I would be happy to help you get rusEFI working on your board if you have interest. I would wager a guess that russian would also offer support, but both of us will likely be limited as we don't have hardware to work with directly.
Welcome to the friendlier side of internet crazy :)
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

I had no idea there were other sources for the CPU chip. Is ST also second sourcing the support chips?

I started the design with supporting CAN for the main interface but then it seemed the cost of converters from USB to CAN for the laptops seemed too high. I liked the CAN because I wanted to be able to support a second instance of the board for some applications. The CAN was going to supply filtered power and communications for the extender card. I did leave the signals available on test points for playing with.

I do have a couple of Freescale devel boards. I had a lot of trouble bringing them up, the tools seemed to be a little confused running in a virtual Windows machine on my MAC. For one thing the COM port kept moving around.

I'm hoping to get the board to boot thru the serial port. The FTDI USB-Serial converter chip has a couple of GPIO pins and I connected them to the chip reset and boot mode pins. Failing that I have the JTAG pins and I'll have to buy a debugger for that.
I should probably encourage you to have a board populated with just the 5634 and min components, then once you know you can program it, have another board populated with more components.
There isn't a lot of other stuff on this board, basically a pair of VR sensor chips and the analog filters. I had them fab 10 PCB's, it just cost a bit more than 5 PCB's. I'm inclined to have several assembled and then hope I can rework them to at least basic functioning. I'm going to try check some of the basics on the board with an Ohm meter before I put parts on them. I trust they do what the schematics say, but it will force me to double check some stuff.
we don't have hardware to work with directly.
I'm willing to share hardware to people that can contribute reviews, advice and/or code. These first boards are supposed to be devel style units, I've punted on a few issues but they intended to be useable. My plan is to start with the O5xxx code because I've looked at it before, but I think it's fine for you to put your code on the board. I would guess a lot can be shared.

There are a couple of people in addition to me that are willing to put these on motors.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Another ECU...

Post by kb1gtt »

I'm not sure about the other supporting chips. I would guess they are not multiple sourced, but perhaps they are.

You might find this interesting. It was originally drafted by essess. Me and one of the other o5e guys made this with an off the shelf set of boards and like 3 jumper wires. The proto was only like $20 and if we spun the board it would have cost like $5. If you search around the forum here I seem to recall some low cost CAN to USB adapters were posted some where.

https://sourceforge.net/p/daecu/code/HEAD/tree/Hardware/trunk/KICAD_Project_CTU/

I seem to recall that the serial boot loader was only accessible after initial firmware was installed. I seem to recall there was an issue with the JTAG as well until the initial firmware was installed. I don't recall what the issues were, it may have simple been that it wasn't well documented. I think there is an open sourced / low cost BSDM program in FredEMS land (FreeEMS). They have the same issue with the S12X. I don't know if that would work for the 5634 but it might. We had the $99 dev board and I seem to recall if you change some jumpers you can use that to program external chips instead of the chip on the dev board. I think you can get purchased BSDM cables for like $75, but we figured a couple extra bucks and you get a dev environment was good.

I've been doing this DIY ECU thing for way to long, and I have no idea why I do it, but meh, I still do it for the heck of it. I originally was hanging out in MS land, then eventually the family got together and bought me a MS2 for a gift. I then got banned from MS forums which are critical for getting there systems up and running. My problem was that I was installing it on a small engine and had to engineer my sensors instead of purchase them. I found they had violated the max energy a typical thermister could handle. I suggested a 2.7k pull up resistor instead of the 2.2k they had been using. This was an issue as they would have to rework the existing boards and people in the field would likely complain. They continued to ship the inventory they had, and the next batch started using the 2.7k I had suggested. However they banned me as they considered me a problem for their inventory. At this point I became one of the early members of FredEMS. However Fred is hard to work with and hard to stomach if you judge him based on principals. I was a primary developer for FredEMS for a couple years, then went the way of most developers over there. There was some drama and a 3 of us split off and started the o5e / open5xxxecu stuff, but I couldn't stand mk_e (Mark) he was much like Fred, and again like the other primary developers I decided to go away. I have found rusEFI to be a good environment for development and I consider it to be the best general platform for a DIY ECU. The people here are generally goal driven, and bite off manageable pieces with reasonable goal expectations and reasonably clear direction on where they are going. This has made for a good team environment. Keep in mind mk_e is a mechanical and he hates me. However I'm still friendly with most of the real developers over there. There were many issues with mk_e not understanding basic electrical and software issues, but it's not a couple years later he's probably getting better with his knowledge base, but still I'm sure he lags the curve relative to electrical and software stuff he doesn't really understand. I think your best chances of success are with rusEFI, but will offer help with what ever you pursue.

Any how just a back ground of me. I can help with o5e, good chance I understand it better then mk_e, as john and I were the ones who got most of it actually working on the dev board. John had some additional code found here https://code.google.com/p/mpc5xxx-engine-control/ Looks like he took down the forum. That forum had a post where I had captured some issues relative to the jitter and how that was causing problems with the crank decoder.

Any how, enough drama and background from me. I can offer help, doing it in this forum is the best place for me. I see there are some changes sense I left, I'm not quite sure what those changes were.

Can I ask, what do you do for the day job, what is your basic background, etc. Basically just looking to get a gut feel / gut understanding of your goals, knowledge, etc. By understanding you a bit more I can know where I can better help you and how I can help you.
Welcome to the friendlier side of internet crazy :)
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

I'll be watching this with interest, I have designed OEM ECUs using both the Andorra and Mamba, however my software experience is very limited.
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

Can I ask, what do you do for the day job, what is your basic background, etc.
I'm a systems software guy, often I work close to the hardware. I have often worked closely with hardware engineers and have experience doing board bring up etc. My first job in the late 70's I worked for a company that made signal processors which is what they called machines that could do a lot of math in those days. The other day I was remembering one of our customers was a company that wanted to use the machines to analyze engines off their assembly line. The idea was to connect them to a big electric motor, spin them around and use sensors to be able to tell if the motor was properly assembled. So people have been using computers on engines for a long time...
I think you can get purchased BSDM cables for like $75,
I don't think they make those anymore, they sell a higher speed one for more money.

I'm a little bummed there were reasonable cost solutions for the CAN. Maybe that's worth revisiting after this proto board is working.
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

I'll be watching this with interest, I have designed OEM ECUs using both the Andorra and Mamba, however my software experience is very limited.
Thanks, Rhinoman. So an Andorra is a 5642 and a Mamba is an Intel embedded board?
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

Andorra is the 5642/44 and the Mamba is the 5674, I don't think I've ever seen an Intel device in a Powertrain ECU.
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

OK. I didn't know the code names for the chips and that is what came up with a simple Google search. The embedded board seemed like a slightly odd choice, but then who knows sometimes... Thanks.

Perhaps I should have chosen one of the larger chips. I'm kind of old fashioned and prefer simplicity to complexity. I think the target for these devices will be competition cars and hot rod type things so I hope the current chip is enough. I like some of their new multicore chips in the 57xx line. It seems to me one core could be dedicated to running code that would replace the TPU and remove the need for a special compiler. So that's the intended direction at the moment.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Another ECU...

Post by AndreyB »

Horizenjob wrote:one core could be dedicated to running code that would replace the TPU and remove the need for a special compiler. So that's the intended direction at the moment.
multi-core development would be pretty sweet, I am really excited about your whole effort!

What is the new source code location for https://code.google.com/p/open5xxxecu/ assuming that where the code would be developed within the open5xxx project?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
KLAS
Posts: 23
Joined: Tue Jul 14, 2015 8:58 am

Re: Another ECU...

Post by KLAS »

Rhinoman wrote:Andorra is the 5642/44 and the Mamba is the 5674, I don't think I've ever seen an Intel device in a Powertrain ECU.
early Rover MEMS ECUs, made by Motorola, were using Intel CPUs, if that counts
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

multi-core development would be pretty sweet, I am really excited about your whole effort!
Thanks for the enthusiasm. I am trying to be forward looking at and the same time realistic and make choices that will get me to the end of the project. It's the same type of thing you are doing with developing modules that will assemble into a system, I applaud that approach.

I submitted some code to the O5xxx project to improve the handling of storing stuff in the flash. But I don't remember where it is now. I let folks know where the code is when I get back to working on it. Sooner if you need to look at it now. This old head can only hold so many things at the same time now. I can literally feel myself swapping working sets when I shift between different projects or just aspects of them.

To continue my introduction my other real life project is a tube frame sports car. I am a mod on the LocostUSA.com site where we do car projects that are at least loosely based on the Lotus Super 7. There are several being built now. I put some links in my signature, but the up to date stuff is happening on the LocustUSA site now. The project is called "Car9". I am not completely sure how that got me to design an ECU, but I am between work contracts and wanted to get a bunch of education under my belt and this seems to be doing it.

My engine target is a Ford 302 that I bought from a friend and my intention is to remove the distributor, add a crank sensor and build a simple modern injection motor from it. It will be coil on or near plug and has a single plane injection manifold right now. Depending on what makes sense my other choice is an old Honda civic daily driver. I also have 2 people lined up to put proto boards on their track cars... Those motors are another 302 and a BMW 4 cyl bike engine ( 14K rpm, yikes... ).
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

You don't need a big processor for this king of project, modern ECUs have enormous amounts of diagnostics and complex control strategies. Most of the ECUs that are being replaced here are quite simple devices and manage to handle diagnostics, control and back-up strategies with plenty of processing power to spare. I'm replacing an ECU that has an 8-bit processor that runs at something like 1MIPs, it passed all the emissions requirements of the time.
The standard Freescale automotive TPU functions are quite comprehensive and the online configurator produces an S19 file so there shouldn't be any real need to write or compile TPU functions.
The Locost is quite a cool project, one of the guys that I worked with built one with his son who has raced it here in the UK.

I would recommend that you add an RF ground to the ECU, currently you have a ground that runs all the way round the ECU, that could easily be modified and you would be much less prone to noise issues. Essentially you just need to add a cap to all the inputs and outputs (where practical) which are grounded to a separate ground which is capacitively coupled to the main ground, your RF ground is then connected to chassis by the shortest link possible, on metal cased ECUs its common practice to use the case. the intention is to create a 'barrier' between the inside world and the outside world by creating a low impedance to ground to remove fast transients and high frequencies which helps to prevent unwanted noise coming into or going out of the ECU. Unfortunately most aftermarket ECUs lack this rather basic requirement - MS is rather notorious for noise problems; experience tells me that you could never type approve an ECU without it.
The image below is of a Mazda ECU:

Image
Last edited by Rhinoman on Thu Jan 07, 2016 8:06 pm, edited 1 time in total.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

KLAS wrote:
Rhinoman wrote:Andorra is the 5642/44 and the Mamba is the 5674, I don't think I've ever seen an Intel device in a Powertrain ECU.
early Rover MEMS ECUs, made by Motorola, were using Intel CPUs, if that counts
that counts :-) I just looked that up, the MGF used an Automotive qualified 87C processor. They don't seem to have any powertrain processors anymore which is probably why I've never spoken to them.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Another ECU...

Post by AndreyB »

Rhinoman wrote:enormous amounts of diagnostics and complex control strategies.
Well, we do need complex diagnostics and control as well in order to have anything cool. That's where we need software developers and we need process and testing and... Well, it's depressing how much has to be done to have a useful project.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

Horizenjob wrote:Another choice I made that I wonder about is I used a Schottky diode and also TVS diode on the analog inputs, but maybe the caps and resistors in the filter would have been enough. Those are BAS70XY and a Bussman SURGX respectively.
You don't need a TVS, you only need a series resistor followed by a dual diode to clamp the input to the positive rail and then another resistor to limit current into the processors clamping diodes; add caps to filter as appropriate. If you can then size the pull up and the initial series resistor to give protection against short to ground/short to battery.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

russian wrote:
Rhinoman wrote:enormous amounts of diagnostics and complex control strategies.
Well, we do need complex diagnostics and control as well in order to have anything cool. That's where we need software developers and we need process and testing and... Well, it's depressing how much has to be done to have a useful project.
To what level? Current requirements require detection of short to battery and short to ground on all pins except the main power pins. You would also need sanity checking of output durations and current levels as well as a hardware watchdog and hardware limp mode.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

I should also point out that the RF caps provide ESD protection as well. Typically you would be looking at something like 330pF, 8kV or 15kV discharged through a series resistor (1.5k?). A 33nF cap will give a voltage attenuation of 100 less losses in the resistor, your pull up and series resistor and clamping diodes need to be sized to handle the remaining voltage; in practice I have qualified a number of circuits with a 2n2 or 4n7 cap. The Vitara ECU also uses 2n2 although its quite an old ECU and may have been qualified to a lower voltage level, the minimum is 2kV but OEMs usually specify higher.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

russian wrote:
Rhinoman wrote: Well, it's depressing how much has to be done to have a useful project.
In my experience a new OEM ECU usually takes a small team 2 years, 1 year to produce and qualify the ECU and 1 year for the vehicle manufacturer to do their stuff. A full qualification validation followed by a full product validation (ECU only) requires around 400 ECUs. Anyone who can get an ECU running on a vehicle is already a winner :-)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Another ECU...

Post by kb1gtt »

My experience with the pre-made ETPU crank decoder was less than optimal. Issues we had included, limited options in wheel patterns and sync issues with low inertia engines. It had to be a single skipped tooth wheel, could not be a 36-2-2 or other pattern. Also it had issues with sync on low inertial / low cylinder count engines. We found that the hall's normal jitter combined with a reasonably rapid change in RPM between the teeth caused a loss of sync. This is very common on small engines where you get one ignition per 720 degrees of rotation. This was a couple years ago, I hear they have a new ETPU code to work from, so perhaps it has gotten better. I generally don't like relying on them for this, as there are going to be bugs, or there is going to be a need to know what it's doing such that you can make your code work with it properly. With out that information you're heading for rough times. With out the ETPU's the 5634 is just a generic reasonably slow MCU.

It looks like the jitter measurements have been lost too bit rot. From memory I recall the hall jitter was aprox 5uS perhaps it was 7uS. The jitter was more at low RPM. I believe much of the jitter was caused by the hall's internal auto hunting and auto calibrating. It makes adjustments based on the peak to peak levels of the magnetic energy. To ensure proper triggering, it de-senses itself as the RPM's increase, which decreases the amplitude going into the digital circuitry. This automatic stuff is required to make them work in a wide range of applications. We then simulated the jitter by adding jitter to the crank generator and validated the jitter issues.
Welcome to the friendlier side of internet crazy :)
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

Thanks for the good advice here Rhinoman. It's interesting that grounding is a simple concept and yet one of the most difficult and important ones too. I have watched hardware guys struggle with this for decades and the stuff they worry about on the high speed boards is amazing to me....

I have been conscious of wondering what to do with my grounds. I put in that border ring and it does not connect to the internal ground planes except at the point of ground entry to the board. The board is isolated from the case at the moment, the ground planes do not reach the board edge and I think I have provided enough clearance from the ring around the board to prevent case contact.

I did see in some reference designs that the first layer of caps on the signal inputs where to a chassis as opposed to a board ground. The confusion I have been having is knowing wether I am providing a path to prevent noise from coming in or actually providing a path for noise to come in. The engine's injectors and especially coils have high currents. The drivers for at least the coils need to be grounded to the cylinder head. I don't want the ECU to ever become the ground path for the starter motor. So I was opting to ground ECU boards to the motor. If I include a ground for the caps to the chassis, it seems that would put the noise of the coil and injector currents across the ground to the battery into the signals.

Another things I have done is the CPU has it's own tiny ground and power planes about the size of the CPU package. This ground plane connects to the main ground planes at just one point so I am hoping the ground and power currents from the CPU don't get onto the main ground plane.
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

I will order caps for my board soon. Does anyone have opinions whether for track cars with motors mounted directly to the frame it would be advisable to use "board flex sensitive" capacitors. I think they have terminals with an epoxy layer in them to make them resist vibration better. They cost more obviously, but if they prevent a board failure they would be cheap... I know when I sit in the car in my avatar and it's idling I have double vision.
TopDown
Posts: 4
Joined: Fri Jan 08, 2016 4:46 am
Location: Washington State, USA

Re: Another ECU...

Post by TopDown »

Hello all,

I just joined this evening and I see a wealth of knowledge here. Horizenjob, I applaud your efforts here, more on that later. I love English convertibles. I have 3 and will love converting them; KB1GTT, I like your input. You have so very much to contribute. I am N6XZD transplanted from California --> Washington last year. Rhinoman, you are obviously an EE with very much to contribute. I will enjoy running my designs by you all. Russian... What a great project. I like your modular approach. I have not done much looking at the hardware or software yet. I see there is much to catch up on. My late wife was a Russian engineer so I have a soft spot for anything Russian or containing the name.

Gentlemen, I believe I have found a home with you all if you will have me. I too am an EE, but with many of years in the shop building engines for customers. I need to get running, but I can't wait to get back to reading all of your posts...

Blessings to you all in the New Year.
KLAS
Posts: 23
Joined: Tue Jul 14, 2015 8:58 am

Re: Another ECU...

Post by KLAS »

Rhinoman wrote:
KLAS wrote:
Rhinoman wrote:Andorra is the 5642/44 and the Mamba is the 5674, I don't think I've ever seen an Intel device in a Powertrain ECU.
early Rover MEMS ECUs, made by Motorola, were using Intel CPUs, if that counts
that counts :-) I just looked that up, the MGF used an Automotive qualified 87C processor. They don't seem to have any powertrain processors anymore which is probably why I've never spoken to them.
the last generation, MEMS3, uses a Motorola CPU and they were introduced around 2001. i would guess that indicates roughly when Intel lost interest with powertrain processors
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Another ECU...

Post by kb1gtt »

About GND planes this is a good article that helps explain and helps people get a gut feel for various GND plane issues. http://www.maximintegrated.com/en/app-notes/index.mvp/id/5450

Some key notes, RF tendencies start at about 1kHz, you need to look at your current loops, solid flood GND planes and flooded planes is generally a good and safe idea. However most of that's more important on a re-spin.

What is your plan for a case and connector? Do you have 3D models of the enclosure? I might be able to convince one of our mech's at work to provide a resonant frequency analysis. We have some nice FEA tools.
Welcome to the friendlier side of internet crazy :)
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

I think I've read the Maxim note, but will go and double check it. Here's a description of what I did with copper zones/planes on this board.

It is a 4 layer board. One internal layer is completely a ground plane. The other internal layer is divided into a couple of areas and also contains 2 short traces. This layer has a ground area under everywhere there is a signal on the bottom of the board. So the bottom signals reference to it. It also contains a zone which carries the aux. 5V power.

The processor received special handling. It has it's own planes for ground, 5V and 1.2V. These planes are the same ( about ) size as the processor package. The reason for the small ground plane here is to keep the local processor currents off the main planes which will help prevent them acting as patch antennas. This should sharply reduce EMI. I did not execute this as well as I would like. Done really properly the processor planes should be well decoupled and then their connection to the main ground plane and the power supplies should also be well decoupled. This provides 2 layers of filtering.

I have also tried to be very careful with return currents by providing balanced sets of ground vias next to every place signals cross from one side of the board to the other.

This board is in reality quite a slow thing with no fast signals, at least I think so. The processor signals are slew rate controlled, the analog is slow and I am guessing the VR chips are also. My concern here then is that a board and the parts of it that are good at generating electrical noise are also susceptible to noise. It is two sides of the same coin.

When I started the design i had some paranoia about the high currents and voltage spikes involved. As it turns out they are all on the top of the driver board so I' not sure it was required. It doesn't really affect the cost of the board, but the cost has been risk and time in my efforts.
Post Reply