Another ECU...

Hardware inside and outside of the ECU
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 generally flood everything, then treat the signals as a coax. I've had good luck with the things I've had to run through EMC. I find SaturnPCB handy for making predictions of traces that I think need predictions. Especially USB and other high frequency signals.
Welcome to the friendlier side of internet crazy :)
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 »

Might be worth considering this USBDM cable http://usbdm.sourceforge.net/USBDM_V4.12/html/index.html I think it would cost less than $35. It appears this can be used with eclipse.

As of 2016/01/17, it can be purchased for $39 from here http://www.technologicalarts.ca/shop/store/details/573/129/microcontrollers/s08/usb-bdm-pod-for-s08,hc12,s12x,cf-v1.html

I wonder if the USBDM would work with the 5643 series of chips.
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 »

There is a useful guide to PCB design on the Ford-EMC pages.
The flexi-terminal caps aren't designed to cope with vibration but with thermal cycling, they are generally used on larger packages and on permanently powered circuits to prevent short circuits due to cracking and the subsequent fire risk. You can also get open-mode caps which are even more expensive. If your ECU is in-cab then thermal cycling shouldn't be too much of an issue, on engine ECUs are specified to 125C or more ambient.
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 »

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 »

Rhinoman thanks for the pointer to the Ford EMC spec. I read it yesterday. Also for reminding me that the flex terminal caps are for thermal cycles. I think I knew that but somewhere it got buried. I will probably use them even for the 0603 caps, but I'll make a final choice in the next day or two when I buy the reels. Last I looked it seemed the big price difference was for Q200 or not then the flex terminal was a little more. The total cost of caps on the board is not very much.

I did see mention of bypassing the RF to a separate ground for the external signal wires. I am still on the fence about this. On this board I have put the microprocessor on it's own little ground plane, this plane also has two zones connected by a neck that separate the analog and digital portions. This should help mitigate this issue. I'd like to review this part of the design some more because I would like to have good A/D ...
Horizenjob
Posts: 45
Joined: Mon Jun 22, 2015 8:31 pm
Location: Massachusetts, USA

Re: Another ECU...

Post by Horizenjob »

Hi KB1GTT thanks for the pointers. I saw the USBDM things before but rejected them for some reason. I think it just was not clear if they would work. There are also cables about the same price that have a pigtail at the end and can do JTAG, that seemed interesting.

Mostly I am a Unix/Linux guy so I'll go look at the compiler pointer. I have used the Eclipse stuff on a 5634 dev board I have. I prefer just the low level tools, the high level stuff always comes with a bunch of baggage and it often isn't easy to figure out what it is doing.

I need to start understanding how the process of booting from serial works. I think you mentioned to me that it might be required to download something to help with that, so that's the stuff I need to start figuring out. I'd like to be able to install a little boot/monitor type program like the old PPCBoot/DasBoot/UBoot stuff.
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 »

That sounds like good news. I only knew of how to use Codewarrior on Winboze to make a firmware. If you can compile with some PPC compiler in linux, I'm sure you can do the same on a win machine.
Welcome to the friendlier side of internet crazy :)
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 »

I barely understand the issue discussed but I hope this is survivable and the boards are still going to be soldered. Really looking forward the topic to cover the software side of this! Do you have a compatible dev board into which you can upload your 'HelloBoard' application, or are you waiting for these assembled boards (what is the name of these boards by the way?) to get back to you first?
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 »

I have a dev board from Freescale, I've been able to use their tools to program it. Last spring when I started on this I made some fixes for Mark E. to handle different size flash pages.

Got a pile of parts in from Digikey today. One irritating thing was I got some parts on cut tape instead of Digireels, turns out when you buy 15 parts on a cut tape, it doesn't mean one piece of cut tape. I hope the long piece of tape is long enough...

I hope to send it out for assembly by the end of next week.
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 seem to recall that the datasheet noted one memory size, but it was common to find a different memory size in the real world. It's common for this to happen as they use the same process for that memory bit on different chips. I would say what ever you use for the memory, make sure it's per the datasheet, as that's what you can rely on getting. I know several chips and projects where people used the more memory, then got a different batch of chips and found they didn't really have that memory. Just FYI, keep an eye on the datasheet memory limits.

I believe you are saying you have and can program it with Codewarrior. I'll keep my fingers crossed that a more friendly compile environment can be found.
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 »

The 5634 flash memory is organized in pages. It has a bunch of pages and they have different sizes. In o5e it was hard coded to use one size page at a couple of different addresses. I made a little structure that described the pages, their memory addresses, what sizes they were and some register bits. This allowed it to program it's table into different pages.

I was able to use Codewarrier to do that work on the dev board. My board doesn't have the USBDM stuff. I also don't know how or what Codewarrier does to interface to the dev board.

The two options are to do something with the JTAG pins or to use the serial interface boot option. I'm hoping to use the serial boot option. I put a FTDI USB to serial interface chip ( FT230X ) on the board. This 2 GPIO pins in addition to the serial lines. One of these is connected to the chip reset and the other to a chip configuration pin to enable serial boot instead of booting from memory. I need to write a C program for the laptop to open a serial port and write a "0" to the ECU board. The 5634 is supposed to look for this and calculate the baud rate. Then you feed it the code to execute. I need to read the manual and figure out some more details like how or if you can specify a load address.

Probably the thing to do would be to use that feature to download some simple boot/monitor type piece of code that you can use to manage the chip which you would use to download the actual ECU code. Once you have that initial boot/monitor thing downloaded it should be easier to work with the chip and do further downloads. You could have multiple copies of the ECU code in the chip and mark which one you want to run. You should be able to have some diagnostics and do other things as well.

Andrey, I have never been able to think of a name for the board or the box. If anyone has ideas feel free to say something.... :)
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 »

Perhaps I should comment that the devconsole has serial capabilities, is multi-platform, etc. Perhaps that already has much of the serial stuff already developed and cold be used to load a firmware / boot loader.

https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/java_console/

About the name, that's likely important and it's something you can do while you wait for the assembler. How about FBCU for Fire Breathing Control Unit. It appears to be clear of trademark issues. What ever you start to get friendly with you should do a search at the USPTO's TESS to help avoid potential future trademark issues.

http://tess2.uspto.gov/bin/gate.exe?f=search&state=4801:t3ahp0.1.1
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 »

So the dev_console is the laptop side of the ECU interface? I'll take a look but it will be a couple of days.

While downloading the code the only special handling is to confirm that each byte is echo'ed by the ECU before pushing the next byte down the line. That way you can check for errors and maybe it's flow control also...

I had thought of "Bang Box" for a name but it's a little to silly. MS has a good name. I've been known to get stuck even on variable names. Couldn't come up with a name for my daughter until a couple of days after bringing her home, LOL... :D
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 »

Hmmm, now you have me wondering, if the parents don't provide a name, do the give you a number or something, or could I actually be a nobody?

TS and devconsole are very similar, but TS is good for tuning, and dev console is good for development stuff. The dev console has less error checking, and more abilities to do mean nasty things. While TS is more refined and it's harder for the tuner to make the program jump off into the weeds.

Dev console is for development purposes, and sends serial commands back and forth to the ECU. There were features that were desired and not available via TS, so this was developed such that we have access to the lower bits and can do development things. You know like uploading a firmware. Who know's perhaps your firmware uploading process is the same as what the dev console does and perhaps this one will work for the 5634.
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 »

Hmmm, now you have me wondering, if the parents don't provide a name, do the give you a number or something, or could I actually be a nobody?
Geez, forgot I left this thread behind so long ago. I don't think they let you have a nobody. Turns out they start calling you up on the phone after a day or two and tell you paper work is piling up. ROTFL

Got behind on this for various reasons, everything from family visits and school vacations. Also spending time thinking about this board and checking it along with not being able to avoid thinking about the next board version.

If you guys are interested we can go through the board by sections. Now that I have gone full way through the project I've had time to reflect and see some places for improvement.

So far in the board review I have found 3 ceramic cap footprints that are wrong. Also somehow I managed to get my pin headers off a common grid. I was able to put a proto board over the CPU board on pins but it seemed a little hard to line up. These things I'm fixing in the board file and schematic as I go. So I need to do a bunch of versioning sort of stuff now to keep this stuff straight when I generate my part placement files. Compounded by having updated my copy of KiCad while groveling during the board fab file submission process. On careful inspection I can see some silkscreen changes so the update moved where my libraries are being read from. Now I have to make sure I get everything straight.

Here's what I did on the power input for this board. One choice you have to make is wether to use a blocking diode or some other method to provide reverse battery protection. I chose to use a dual p-mosfet to provide the reverse protection and used a filter on the gate to provide a soft startup. I think the soft startup is a good idea with the hybrid polymer power cap on the board.

Thinking about this more though using a blocking diode makes sense if your power cap is big enough to support the board voltage thru the dips in voltage caused the starter on compression strokes - then you win.

At one time I had one of the p-mosfets used to isolate the board from voltage spikes ( load dumps ). Now I use a large TVS diode. It used to be an even larger one, but I wasn't sure about dealing with shaping the leads and soldering it in. Now that I've seen them used on boards I have looked at will maybe/probably do that on the next board (TMSD-17 -> SLD24-18). There should also be an external, maybe 3A, fuse.

Oh, the symbol is wrong for the p-mosfet ( it shows n-channel ), I need to draw another but the pin out is the same.
Attachments
ECU_CPU-pwr.jpg
ECU_CPU-pwr.jpg (104.13 KiB) Viewed 19234 times
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 »

Nice to hear the progress.

Yes play by play would be cool, but I would suggest lower priority than getting a board programmed.

About headers, I once saw a spark fun suggestion where they placed the header vias slightly staggered. this caused the header to sit in the board straight instead of kind of wobbly. You need the via size to get a good solder connection, but you can stagger the holes such that your connector is more rigidly held straight.

I might suggest a fuse in-front of D1, as burnt traces can be a bugger. A replaceable fuse might be a handy save the PCB feature. You know some guy's going to wire this direct to the battery with out a fuse, saving the PCB could be handy safety.
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. Yup, the board assembly and programming is the priority now.

Interesting idea on the staggered pins.

I didn't mention above but I decided that the partner board with the drivers would be layed out with the sockets on the correct grid. I'll solder in th pins myself and will do it with a proto board stuck on them to align them for the driver board. I hope that works.
e idea with the soft startup circuit above is to put a large cap in parallel with the gate and then ignore the gate capacitance and ramp the voltage on the bigger cap to produce a soft turn on. I'd like to limit the in rush current to 10 or 20 amps.

I was going to use or provide an inline fuse. I don't remember if what I looked at is IP45 which would be nice. I did try to find a polyfuse type thing but didn't see something that looked right. I should try again, It would be nice to have something like that. I think one issue is how how the board might get or how much heat it would exposed to mounted some places.
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 found the sparkfun page about the suggested staggered header vias stuff https://www.sparkfun.com/tutorials/114

Keep in mind Polyfuses (PTC) don't actually blow. When a 5A PTC trips, it still conducts something like 2.5A to 3A. As well they trip on temperature so if you place them to close to something hot, they can trip even if no current is flowing. Generally PTC's get used on things like this for limiting inrush current. However trying to limit something like 5A continuous, with 20A inrush is going to be tough. What is your planned continuous current? I'm assuming 5A as most inline fuses are 5A, perhaps your planning for 1A? I'm just guessing and speaking in generic terms. Generally PTC's are used for limiting a larger inrush. They also have significant ohms, which in itself tends to limit the inrush.

When you select your inline fuse, keep an eye on your I2T ratings. The 20A inrush on a 5A fuse can fatigue the fuse and cause it to blow after some number of cycles. Your I2T rating will tell you how many cycles you can do before you have this issue. See this selection guide for some equations and such for checking for I2T issues.
http://www.littelfuse.com/technical-resources/~/media/files/littelfuse/technical%20resources/documents/reference%20documents/fuseholder_rerating.pdf
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 pointer to the guide, I'll look at it. They have a PTC on some of the Freescale demo boards. I think it was the datasheet's temperature curves that made me pause. The only place I am using one now is a little one between the external analog ground and the internal ground. This is in case a sensor wire gets shorted to +12V.

I expect the current for this board to be under 1A, it's just the CPU with analog interfaces like VR and the SPI and control signals for drivers. I'd like the drivers to have their own grounds. That brings up some questions too though.

I had trouble finding the right part for this dual mosfet, I thought I could get them with safety features like over current and temp. limits. I'll have to review some datasheets I saved earlier. I picked a simple one that will work for this assembly trip.

The p-mosfet idea for a reverse connection blocking feature sounds good but the implication is that then the board caps are used as a battery extender feature for the starter motor. That forces you to run the ECU at lower voltage. The blocking diode reduces the voltage available but should allow riding thru dips caused by the starter motor so you come out ahead I think.
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 »

If you have a guess about your PCB current, you could simulate with QUCS or some kind of similar simulator to see if you would ride out the dip.
Welcome to the friendlier side of internet crazy :)
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 »

kb1gtt wrote:Looks like there is a GNU PowerPC compiler that works with the 5634 processor some notes found here http://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_(MPC_56xx)#GNU
NOTE: Currently, GNU compiler supports Single-Core configuration and FLE mode only.
Also http://erika.tuxfamily.org/wiki/index.php?title=PPC_GNU_Toolchain_Integration
NOTE: All freeware GNU compiler toolchains generate PPC code in FLE mode ONLY!!!
Also https://gcc.gnu.org/ml/gcc/2013-03/msg00170.html

Does anyone understand how bit of a deal is this VLE (variable-length encoding) vs FLE (fixed length encoding) thing?
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
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 »

ChibiOS SPC56x port uses VLE so no GCC :( See http://forum.chibios.org/phpbb/viewtopic.php?f=19&t=1570
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 »

I spent more time thinking about the soft startup circuit. A 1 Ohm power resistor on the power connection would do everything I want except maybe cause a 1V drop during engine cranking. You could use a mosfet to bypass the power resistor after the system powers up, but then you could use a mosfet to do the entire soft start... f your power cap is large enough to ride thru the initial voltage drop due to cranking ( 50 mSec.? ), you could skip the mosfet.

On the compiler subject, I guess there will be some education coming my way. I dont see VLE being a big deal, I would expect you could compile something either way, if it fits in memory you should be OK. VLE would save memory space and also speed up the processor because effectively you have more memory bandwidth so far as reading instructions go.

I've been looking at the VR inputs some more, because I want to understand the issues about the input filter. I put a timing wheel in my drill press and started looking at low RPM signals with a VR sensor. I'll buy a stock Ford sensor for a 302 next week. Here's a pair of traces, one with a 10k resistor for a load and the other with a 100 Ohm resistor for the load. These pictures are around 550 RPM.

I am surprised the voltage didn't drop further with a 100x increase in load, it dropped from about 2V to about 200mV. Next will be to add a couple of diodes etc. and see what it looks like.
Attachments
VR_10k_550RPM.jpg
VR_10k_550RPM.jpg (394.19 KiB) Viewed 19668 times
VR_100_550RPM.jpg
VR_100_550RPM.jpg (421.16 KiB) Viewed 19668 times
Last edited by Horizenjob on Sat Mar 26, 2016 10:59 pm, edited 1 time in total.
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 confused, I can't seem to get the pictures to work. TIFF's are a propitiatory format, which makes them less portable. I would suggest a PNG for cartoon graphics and a JPG for picture graphics. If you don't have PNG for some reason, you can use GIF's instead, but keep in mind GIF's had security issues once upon a time, so some times those have issues being viewed as well.
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 »

Fixed the picture for you, I meant to upload a jpg but usually I especially intend to do that after the forum refuses to load the tiff. THis forum did allow it though so my normal thought process was interrupted! :)
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 would expect that as long as you aren't saturating the core, the sensor picks up a fairly constant watts. Then your voltage would be P=(V^2)/R --> (P*R)^0.5=V.

So (2V^2)/10k = 0.4mW, then (0.2V^2)/100 = 0.4mW. So it seems the voltage level is as I would expect. If you want to predict the voltage, you could use (0.4mW*R)^0.5 = V. As well you could see how many mW's you get at high RPM.

If you see that mW change, it would indicate you have saturated the core and are loosing energy. I see a slight skewing of the signal based on these different load resistors. One is a bit more pointy, the other is more sine wave.
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 Jarrod, thanks. Meant to answer earlier. I think I either did the math in my head or also used a different trace, anyway you did it right.

Finally got to run the VR sensor with a diode clamp. I'm much happier. We'll see if the Maxim chips are happy too.

This is with a pair of scrap diodes I had lying around. I'm thinking on the board I might use a BAV99 ( from memory here ). It's a pair of diodes in series so the voltage peaks would be twice as high as these pictures. You can buy it with 2 of these pairs in an SO8 package, so it looks easy to use.

These are cheap parts and have about 100x as much current capacity as the internal diodes on the MAXIM chip. Doing this clamp on the outside of the chip means you don't have to dump a bunch of current into a little chip trying to measure your signal for you. I notice that the spec sheet says the jitter and delay is much worse when the input is saturated. dCan't imagine a 100 nSec difference would matter much to an engine, but I should do he math I guess.
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 »

tiff issue.

The jitter can be an issue, we had issues with the 5634 being sensitive to jitter. Even tough we had maxed out the windows and such, it wouldn't sync reliably this lower level jitter can be more of an issue than your intuitions might have you think. However that was really an issue with the decoder software.
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 »

Sorry I upload the wrong file, I converted it then clicked on the wrong one. Funny the forum software let me delete the file but not reload it.

Here is what the trace looks like. More or less what you would expect. I'll try a faster RPM on the drill press tomorrow. I was a little surprised how low the voltage was, but there is not much current at this speed. These diodes are cheap and have very fast recovery so I hope they will work well.
Attachments
VR_diode_B.jpg
VR_diode_B.jpg (397.96 KiB) Viewed 19591 times
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: Another ECU...

Post by Rhinoman »

You need to limit the negative swing of the VR to within -0.3V of ground or you will be outside of the working range of the Maxim chip, then you risk pushing the rails up and down which can shift the reference voltage and cause jitter - unless you are using the internal 2.5V offset.
Post Reply