Tesla Temp Mux Testing

[Jack Bauer]

We seem to have an issue with the heatsink and motor temperature sensor readings on both large and small drive units with the latest firmware. Require someone with a working drive unit and older firmware to confirm whether this is a hardware or software problem.

[cloudy]

Thanks for opening this,

I did try some older firmware with my the SDU and still didn't see BMS_IN/temp1_out toggling - Sorry I didn't note how far back I went

The closest work I can see was referenced here for the other mux pin (temp0): viewtopic.php?f=10&t=150

and the fix: https://github.com/jsphuebner/stm32-sin ... c20e472888

[johu]

Is the hardware in question being identified as "Tesla"? Otherwise no muxing.

EDIT: found it.

Code: Select all

   switch (hwRev)
   {
      case HW_REV1:
         analogInputs[AnaIn::il2].port = GPIOA;
         analogInputs[AnaIn::il2].pin = 6;
         break;
      case HW_REV2:
      case HW_REV3:
         break;
      case HW_TESLA:
         DigIo::temp1_out.Configure(GPIOC, GPIO8, PinMode::OUTPUT);
         //Essentially disable error output by mapping it to an unused pin
         DigIo::err_out.Configure(GPIOB, GPIO9, PinMode::INPUT_FLT);
         break;
      case HW_BLUEPILL:
         AnaIn::Init(analogInputsBluePill);
         DIG_IO_CONFIGURE(DIG_IO_BLUEPILL);
         break;
   }

   if (hwRev != HW_BLUEPILL)
   {
      AnaIn::Init(analogInputs);
      DIG_IO_CONFIGURE(DIG_IO_LIST);
   }

So bms_in is configure as output when Tesla but the subsequent call to DIG_IO_CONFIGURE makes it an input again.

[Jack Bauer]

Nice. Can you do a bug fix release?

[johu]

Can someone test?

[cloudy]

Awesome! Will test this tomorrow.
I guess this should be a separate task but it would also be great if we can have a Tesla sdu hardware mode (even if manually selected not sensed). The sdu uses different spec /inputs for its temp sensors. I have a mapping and lookup tables ready...

[wigman]

I just tested this verison-

1. The temp codes are gone and the graph reading looks normal!

2. One spot value changed from OK to ERROR- din_mprot. I tried my starter switch and even though I could see the signal incoming on a graph, the control board would not close the main relay. I went back to my previous version and verified that spot value was OK and my relay was still in working order. Something about the new code changed this.


Also, I posted in the other thread, but I was previously having currentlimit derate codes even when no HV was connected. Can I put in a task request to look at that issue as well. I can't tell if the new version has it or not because the relay won't close so it never goes into run mode.

[cloudy]

Johannes, can you post the source for the patch? I can also try this on a SDU, but the sensors wont be mapped correctly using the standard build. May also be able to figure out what the contactor issue is mentioned above

[yaroslav]

I checked the KTY 81 inverter sensor works correctly now

[johu]

Great.
I also found the issue with mprot.
Software attached. When positive I'll draft a release

[wigman]

I tried this, the error is gone but the main contactor still will not close when the start signal is sent.

I can still graph and show the start signal reaching the board.

[retrEVnoc]

I tried this, the error is gone but the main contactor still will not close when the start signal is sent.

I can still graph and show the start signal reaching the board.

I'm having the same problem. When given 'start' pulse the inverter goes in to run mode, the precharge relay opens as it should, but the main contactor doesn't close. I've switched contactors and confirmed a functioning contactor. Software bug, a setting I've got wrong, or hardware issue?

[wigman]

I think my issue has one more difference than yours. When I hit the start signal my precharge relay does not open and thus I don’t think my inverter starts.

[retrEVnoc]

I think my issue has one more difference than yours. When I hit the start signal my precharge relay does not open and thus I don’t think my inverter starts.

there is a spot value, opmode, that changes from On to Run I believe when the start pulse is received, should allow you to know for sure. I haven't tried the latest update johannes posted yet.

[johu]

I'll check later today in my Polo which uses the dcsw output. It's not quite the same as it isn't Tesla hardware but maybe I can spot something.

[wigman]

I checked that yesterday actually, and the mode still reads off even though the start signal is received according to the graph.

[johu]

I checked the current version in Polo and it closes the DC switch as expected. So must be something Tesla specific. I need a screenshot of the spot values before and after asserting "start"

[johu]

Any news here? I saw in a previous version of your parameters that idlespeed was > 0. That will inhibit starting unless you press the brake pedal so din_brake becomes high.

[Lee Malo]

I am having the same problem as Cloudy as well . The Temp sensor readings are fluctuating from 0 - 100c with in a few seconds . I have tried 2 different SDU with the same results. There has to be a software or hardware problem .

fault codes :

18- derate tmphsmax
136- derate tmphsmax
154- derate tmphsmax
**
V4 board
4.76 software, I believe

[Kevin Sharpe]

There has to be a software or hardware problem .

Can I suggest you provide some more detail about your setup? Start with hardware and software versions

[cloudy]

If you are happy to build the firmware yourself, patched version for the SDU here:
https://github.com/jameswarner62/stm32-sine

There was a beta available on the forum somewhere in which Johannes had fixed the mux select on Tesla hardware, which should give you non oscillating values but you'll still need to use the above to get accurate temperature readings as the SDU is treated as a LDU by the current firmware. Hoping that Johannes will be able to add a SDU mode in future, but I'm sure he has a huge list of other things to look at too

[johu]

Good contribution, will see if I can generalize it.

[johu]

I spotted one issue with your code: tmphsmax is never reset to 0 so it will always rise. Or is there something I'm not seeing? Also the comments are off ("Handle Mux Input XX") they are always the inputs set in the previous state (confusing, I know)

Anyway I have merged your code into the master branch. I detect the drive train type through mux input 1.3: it is grounded on the SDU and connected to TMP_MOT2 on LDU. The lowest considered value is 0.22V @ 100°C. So at 0.05V I consider it an SDU.

Also dougyip contributed the curves for the coolant temp sensors that are also included in this version.

Firmware attached, please test.

[johu]

For temp sensor issue look here: viewtopic.php?f=10&t=77&p=10489#p10489

[cloudy]

Thankyou for taking a look -= this is awesome!

It's been a while since I made the changes, so forgive any mistakes:

I think the temp curves from dougyip were an improved set for the LDU, were you also able to add the 10K sensors used on FLUID and CASE on the SDU? (They are not Jcurve but NTC approx 10K @ 25c & these type are only used on the SDU, not the same as the LDU as far as I can see)
I documented them here as 10K_NTC - not perfectly accurate, but way better than any of other the sensor maps in firmware at the time
https://github.com/jameswarner62/stm32- ... atched.ods

I don't follow on the mux comments being from the previous case. The code seems to set the mux digital state, and then measure the two analog values. I assumed the logic notation was inverted (ie temp0.clear and temp1.clear would be 11) So case 3 where temp 1 and temp0 were both set it didn't make sense to have a comment of 10. The previous (case 0) has both inputs set clear, so the 10 doesn't make sense for that one either... You know this far better than I, so would love to understand it!

Case 3:
DigIo::temp0_out.Set();
DigIo::temp1_out.Set();
input = 0;
//Handle mux inputs 10
tmphs = TempMeas::Lookup(tmphsi, TempMeas::TEMP_TESLA_52K);
//TEMP_FLUID on SDU - TEMP1_CASE on LDU - DIFFERENT DIV RESISTOR
tmpm = isLdu ? TempMeas::Lookup(tmpmi, TempMeas::TEMP_TESLA_100K) : TempMeas::Lookup(tmpmi, TempMeas::TEMP_TESLA_10K);
break;
}

Re tmphsmax - I still had your entry of
static int tmphsMax = 0, tmpmMax = 0;
in the GetTemps function, which should reset the max value as usual? I think the "in case" zeros were just for mux selects with no input...
EDIT: I also see you zero both max in case1 - but not any of the other cases, little confused on this one now...

Very cunning on the LDU/SDU detect!