Teensy 4.0 / High Voltage Heater

Looking at the schematics of the SK Pang board, I noticed that the CS pin of the MCP2004 LIN Transceiver is connected to Teensy pad 32. Pad 32 is on the bottom of the Teensy 4.0 PCB [left-bottom corner].

1707593484476.png


Can you actually see a physical wire or pogo-pin from that Teensy pad to the SK Pang board?

Paul
 
It appears so. I pulled the teensy off the board to snap these photos. I assume it was pushed together enough, but I reattached with a little more pressure to push but it will not go in all the way. Some pin is showing.
 

Attachments

  • PXL_20240210_195046686.jpg
    PXL_20240210_195046686.jpg
    100 KB · Views: 40
  • PXL_20240210_194904353.jpg
    PXL_20240210_194904353.jpg
    103.9 KB · Views: 38
I have continuity with the multi-meter from pin 32 to breakout board at both 3.3V pins and on the MCP2004 Chip, I am getting continuity on one of the pins. Either LIN_TXD or LIN_FAULT. Cannot tell which, but here is a photo. Pin that is pinging is the one on the bottom row second from the right.
 

Attachments

  • PXL_20240210_202119387~2.jpg
    PXL_20240210_202119387~2.jpg
    137.8 KB · Views: 35
OK, thanks for the pictures - I just wanted to make sure CS is making it to the LIN transceiver. Now I understand why the Teensy 4.0 is included in the product.

Now back to your code. Studying the example https://github.com/MarkusLange/Teensy_3.x_4.x_and_LC_LIN_Master/blob/master/examples/NCV7430_Get_Full_Status/NCV7430_Get_Full_Status.ino
I would like to suggest the following minimal code:
C++: 
#include "lin_bus.h"

LIN lin(&Serial3, 19200);

int lin_cs = 32;
uint8_t data[8];

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(lin_cs, OUTPUT);
  digitalWrite(lin_cs, HIGH);
}

void loop() {
  lin.order(24, 0, 0);
  Serial.println(lin.response(24, data, 8), HEX);
  digitalToggle(LED_BUILTIN);
  delay(100);
}

The only purpose is to read & display the measurement registers as basic as possible. If that works we can add writing the power register and plotting the data.

Paul

PS: the link to the LIN interface on the WIKI page seems not active
 
jsimonkeller said:
I have continuity with the multi-meter from pin 32 to breakout board at both 3.3V pins and on the MCP2004 Chip, I am getting continuity on one of the pins. Either LIN_TXD or LIN_FAULT. Cannot tell which, but here is a photo. Pin that is pinging is the one on the bottom row second from the right.
Click to expand...
That would pin FAULT.
Important is that pin 2 of the MCP2004 is HIGH when the code is active.

Paul

1707596888271.png
 
To verify whether data is actually outputted using my code, I hooked up the logic analyzer to pin TX3. It is:

DSView-240210-215406.png


Paul
 
Paul. When I compiled your code above, the board connects and disconnects and connects again every 10 seconds. Should it be doing that?
 
From the specification
jsimonkeller said:
Paul. When I compiled your code above, the board connects and disconnects and connects again every 10 seconds. Should it be doing that?
Click to expand...
No, my code is not doing that.
But I may have found an important clue. In the Webasto LIN document you attached in message #32, I see this:

1707598924472.png


HVH shall be a LIN slave node following the LIN specification pacakge 2.1.
That means that we have to tell the library to calculate the Enhanced Checksum by adding the "lin2x" parameter.
Updated code:
C++: 
#include "lin_bus.h"

LIN lin(&Serial3, 19200);

int lin_cs = 32;
uint8_t data[8];

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(lin_cs, OUTPUT);
  digitalWrite(lin_cs, HIGH);
}

void loop() {
  lin.order(24, 0, 0, lin2x);
  Serial.println(lin.response(24, data, 8, lin2x), HEX);
  digitalToggle(LED_BUILTIN);
  delay(100);
}

And the accompanying LA screenshot:

DSView-240210-220726.png


Paul
 
jsimonkeller said:
Without this analyzer, will I be able to see data output on the serial monitor or plotter?
Click to expand...
Yes, you should. The LA is only reading the data on the TX3 line. If a had an actual LIN device, I probably would have seen the response data as well.

Paul
 
jsimonkeller said:
Pin 1 (RX) is reading 3.3V while code is running. Nothing from Pin 2.
Click to expand...
Pin1 (RXD) reading HIGH is normal. Only during a LIN message (~5ms) it can go LOW. See LA screenshot.
But pin 2 of the MCP2004 should definitely be HIGH. pinMode(lin_cs, OUTPUT); digitalWrite(lin_cs, HIGH); drive Teensy pin 32 HIGH.

By the way, this 10s dis/reconnecting: does that happen with the Webasto device connected to the LIN bus? If so, what happens if you disconnect the Webasto device?

Paul
 
Paul, I know we were pulling things back, but when I included your lin2x into the longer code, the board stays connected with and without WEBASTO connected AND pin 2 is now showing 3.3V, so a good sign, no? I need to go test it in the garage now with the heater on.

Code: 
#include "lin_bus.h"

// Create an IntervalTimer object
IntervalTimer myTimer;

int ledState = LOW;                // ledState used to set the LED
unsigned long interval = 200000;   // interval at which to blinkLED to run every 0.2 seconds
uint16_t Power = 175; // set to required power
uint8_t Temperature = 45; //set to required temperature
uint16_t tmpheater = 0;
uint16_t udcheater = 0;
uint16_t powerheater = 0;

LIN lin;

int lin_cs = 32; // cs and serial port set for skpang LIN / FDCAN board

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(lin_cs, OUTPUT);
  digitalWrite(lin_cs, HIGH);
 
  //Serial.begin(19200);
  //Serial.print("HVH50 Heater demo");
 
  myTimer.begin(blinkLED, interval);

  LIN l(&Serial3, 9600);
  //LIN l(&Serial3, 19200); /// Change to this for 19200 /////
  lin = l;
 
}

void loop() {
  // heater
  SendLin();
  delay(100); // wait 100ms
  //Serial.print(" Heater test\n");
}

void blinkLED() {
  ledState = !ledState;
 
  digitalWrite(LED_BUILTIN, ledState);
}

  static void SendLin()
{
   static bool read = true;
   uint8_t data[8];
  if (lin.response(22, data, 8, lin2x) >=0) // -1 indicates crc error, 9600
  //if (lin.response(24, data, 8, lin2x) >=0) /// Change to this for 19200 /////
     {
     tmpheater = data[1] - 40;
     udcheater = data[4] | (data[5] & 3) << 8;
     powerheater =((data[5] >> 2) | (data[6] << 8)) * 20;
     Serial.print("Temp:");
     Serial.print(tmpheater);
     Serial.print(",");
     Serial.print("Udc:");
     Serial.print(udcheater);
     Serial.print(",");
     Serial.print("Power:");
     Serial.println(powerheater);
     }
   if (read)
   {
      lin.order(22, 0, 0, lin2x); // 9600
      //lin.order(24, 0, 0, lin2x); /// Change to this for 19200 /////
   }
   else
   {
        uint8_t lindata[] = {uint8_t(Power/40), uint8_t(Temperature+40), 0, 8};
          lin.order(21, lindata, 4); // this for 9600
      //lin.order(35, lindata, 4); /// Change to this for 19200 /////
      //Serial.print("\n Sending power and temperature");
   }

   read = !read;
}
 
jsimonkeller said:
Paul, I know we were pulling things back, but when I included your lin2x into the longer code, the board stays connected with and without WEBASTO connected AND pin 2 is now showing 3.3V, so a good sign, no? I need to go test it in the garage now with the heater on.
Click to expand...
Yeah, that's a good sign. Perhaps there should be some time between lin.order() and lin.response()?
I also saw that you reverted back to 9600bps?

Paul
 
still no hot water, but PINS 1,2 and 4 get 3.3v and board is staying connected. If I can find a way to work with your shorter code without the disconnection issue, that would be great. Thank you, by they way, for all of this great assistance and sleuthing.
 
PaulS said:
Yeah, that's a good sign. Perhaps there should be some time between lin.order() and lin.response()?
I also saw that you reverted back to 9600bps?
Click to expand...
I am floating between 9600 and 19200 because the OI guys found their webasto was at 9600 . . . so I try both every time . . . not sure if there is a way to sniff the baud rate with a simple program.
 
I'm wondering why we actually need the lin.order(24, 0, 0, lin2x);? ID24 is a read-register, so why do we need to write "0,0"?
Perhaps comment out lin.order(24, 0, 0, lin2x);? in your code?

Paul
 
Paul, once I added in the blink LED to your shorter code, it stopped disconnecting and I am getting the blinking amber light.

With the heater disconnected, I am getting this on the Serial Monitor: FFFFFFFF

1707603931223.png


Revised Code:

Code: 
#include "lin_bus.h"
// Create an IntervalTimer object 
IntervalTimer myTimer;
int ledState = LOW;                // ledState used to set the LED
unsigned long interval = 200000;   // interval at which to blinkLED to run every 0.2 seconds
LIN lin;
int lin_cs = 32; // cs and serial port set for skpang LIN / FDCAN board
uint8_t data[8];
void blinkLED() {
  ledState = !ledState;
  
  digitalWrite(LED_BUILTIN, ledState);
}
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(lin_cs, OUTPUT);
  digitalWrite(lin_cs, HIGH);
  
  myTimer.begin(blinkLED, interval);
  //LIN l(&Serial3, 9600);
  LIN l(&Serial3, 19200); /// Change to this for 19200 /////
  lin = l;
  
}
void loop() {
  lin.order(22, 0, 0, lin2x);
  Serial.println(lin.response(22, data, 8, lin2x), HEX);
  digitalToggle(LED_BUILTIN);
  delay(100);
}
 
jsimonkeller said:
Paul, once I added in the blink LED to your shorter code, it stopped disconnecting and I am getting the blinking amber light.
Click to expand...
Weird, adding a timer that stops disconnecting...
jsimonkeller said:
With the heater disconnected, I am getting this on the Serial Monitor: FFFFFFFF
Click to expand...
0xFFFFFFFF means that it is reading HIGH's only. HIGH is the default state of the DATA line. And 0xFFFFFFFF is only 4 bytes - you would expect lin.response(22, data, 8, lin2x to read 8 bytes.

It's close to midnight here, and my brains are quitting. Will be back tomorrow.

Paul
 
You must log in or register to reply here.
Back
Top