5l40e

[Bernard Fife]

gurov,

It is shutting the GPIO down too soon that could cause the problem (though I would try to always let both run their course while burning).

I wouldn't assume it is a hardware problem just yet. In fact, if this was mine, I would load old MShift code (or even MS-II code) and see if it has the same problem or not. If that code runs fine, then hardware is a much less likely suspect.

The two inner layer are 5V power and ground, and it's possible to short them together (even intermittently) by cutting the board. That could cause burning problems, I suppose. I don't know if these planes run right up to the edge though, I will check and let you know.

Lance.

[gurov]

gurov,

It is shutting the GPIO down too soon that could cause the problem (though I would try to always let both run their course while burning).

I wouldn't assume it is a hardware problem just yet. In fact, if this was mine, I would load old MShift code (or even MS-II code) and see if it has the same problem or not. If that code runs fine, then hardware is a much less likely suspect.

The two inner layer are 5V power and ground, and it's possible to short them together (even intermittently) by cutting the board. That could cause burning problems, I suppose. I don't know if these planes run right up to the edge though, I will check and let you know.

Lance.

if the two planes were jumpered somehow, wouldn't that cause the 5v regulator to overheat/burn up OR burn up whatever bridge was made by the grounding wheel. are there guidelines for voltage needed to successfully complete the burn ? also, wouldn't this show up while flashing the firmware ?

i will also attempt to load latest ms2extra firmware and try that on this board.

[Bernard Fife]

gurov,

Not necessarily. The planes can be just barley touching by a tiny thread of material on the cut line, conduct a bit and heat up, separate, then cool and re-touch, etc. But I don't think this is the issue. If this was mine, I would check with a scope the regulator's 5V pin while burning to see if it maintains a steady supply, just to rule it out.

More likely is that something is going on in the code. There is a setting in the code to slow the flash burn sequence, and it might not be quite right with all the additions to the code lately. So I will have a look at that.

Another thing (that used to be in the code; some V1.xxx beta versions) is disabling all interrupts for the duration of a flash burn. This is more of an issue with MShift than MS-II because the VSS interrupt rate is quite high (~1.6kHz with a 4L60E at 60mph). I took it out because it wasn't needed, and didn't help, at that time. But maybe I need to re-introduce it to allow faster, more consistent flash burns.

So give me a little while (tomorrow, perhaps) to put these into the code; I will post new code here.

Lance.

[Bernard Fife]

gurov,

I had a few minutes here, so I put the changes mentioned above into the code (just a half dozen lines of code). They seem to help here in very brief testing, try it and let me know how it works for you:

Monitor_2006d.abs.s19

This uses the same INI as above (2006c).

I will be out for several hours, so it might be a while before I can do more extensive testing.

Lance.

[gurov]

gurov,

I had a few minutes here, so I put the changes mentioned above into the code (just a half dozen lines of code). They seem to help here in very brief testing, try it and let me know how it works for you:

Monitor_2006d.abs.s19

This uses the same INI as above (2006c).

I will be out for several hours, so it might be a while before I can do more extensive testing.

Lance.

i'm going to be out for a few days, i'll get back to it next week or so. the car is still sitting on jackstands waiting to get front axle boots fixed, so this is just bench testing to rule out all the bugs like this.

thank you for the speedy response again, i will make sure to test this once i get back to it.

[Bernard Fife]

gurov,

Sounds good, thanks for all the testing you have done already. I will continue to test here, of course.

The ground and power planes run to within 0.020" of the edge of the board (on the CPU side). There is one 'buried' trace on that edge, it starts at 0.020" from the edge of the board, and is 0.027" wide. It is connected to the via on the edge of D4 at one end, and Ampseal pin#1 at the other end. It should have no continuity to ground at all (at least on a board with none of the user circuits assembled).

<edit>I put 2.006f code up on the V2 code page: http://www.msgpio.com/manuals/mshift/V2code.html , it has a small (and mostly 'theoretical') improvements to the flash burn routines as well as a TCC fix.</edit>

Lance.

[gurov]

gurov,

Sounds good, thanks for all the testing you have done already. I will continue to test here, of course.

The ground and power planes run to within 0.020" of the edge of the board (on the CPU side). There is one 'buried' trace on that edge, it starts at 0.020" from the edge of the board, and is 0.027" wide. It is connected to the via on the edge of D4 at one end, and Ampseal pin#1 at the other end. It should have no continuity to ground at all (at least on a board with none of the user circuits assembled).

<edit>I put 2.006f code up on the V2 code page: http://www.msgpio.com/manuals/mshift/V2code.html , it has a small (and mostly 'theoretical') improvements to the flash burn routines as well as a TCC fix.</edit>

Lance.

is there a photo of the planes or at least that edge if that schematic is not available. I want to ensure I didn't mess up the pcb

[Bernard Fife]

gurov,

Here it is:

board_edge.JPG

The yellow line is the edge of the board. Orange represent the ground plane underneath, magenta is the power plane on top. <edit>The ground plane is everywhere the power plane is, plus the orange areas.</edit> These are the same above and below the picture as the are at the top and bottom of the picture (they don't change).

Lance.

[gurov]

gurov,

Here it is:

board_edge.JPG

The yellow line is the edge of the board. Orange represent the ground plane, magenta is the power plane. These are the same above and below the picture as the are at the top and bottom of the picture (they don't change).

Lance.

I didn't even cut close to where the grounf plane starts, so that shouldn't be an issue. I will still check it out some more and maybe go over the edge with a metal brush, but I really don't think this is the case.

I will check new code out and try the hardware with ms2extra to see if the processor is damaged.

[gurov]

okay, so the corruption is still happening.

for some odd reason it tends to happen if i turn on ISS (set it to "input shaft speed") on the next power down the flash gets overwritten.

tested the board with ms2extra 3.0.3w, works like a champ.

going to poke at this some more.