Teensy 4.0 First Beta Test

Status
Not open for further replies.
...
Erin soldered all the beta boards, but I hand soldered these 5 breakout boards.
...

Supposing those are resisters on the exposed Serial Rx & Tx pins to make them touch safe?
Return of the 'Soldering Goddess'?

I put a 5 pin female header on T4 end I had to remove - Was it Michael_M that pointed out the very excellent ~12 30W iron solder sucker unit? Finally opened it and it did great work! Back to nice clean holes!

Paul to disable :: //#define PRINT_DEBUG_STUFF

File: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\debug\printf.h

Needs this in the ELSE or ifndef case :: #define printf_debug_init()

On my test Serial_7 doesn't take default (?) 'SERIAL_8N1' formatting to chain across all ports?

Paul - … something ODD about Serial7

...
I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou. I have a 5th board where Serial7 isn't connected - don't know why yet.
...

My lame attempt to push DEBUG port to 7 has failed - though I was getting some broken data on T_3.1 - just don't know what format it is in - it doesn't work and Frank noted some fails.

I am looking for DEBUG because I moved it off of 4 to test it like the others - and as my test runs some dozens or hundreds of times then it Goes to FAULT BLINK … Will post sketch and more if I get closer.
 
Paul - RE: Trouble on the Breakout :: Serial 7 Pin 28 or 29 has a loose connect - PogoPin? Push T4 down and this went to showing good with jumper placed on pi<>po::
Code:
// UART6 Serial1 [0/1]  UART4 Serial2 [6/7] UART2 Serial3 [15/14] UART3 Serial4 [16/17]
// UART8 Serial5 [21/20] UART1 Serial6 [25/24] UART7 Serial7 [28/29] UART5 Serial8 [30/31]
#define pi 28
#define po 29
void setup() {
  while ( !Serial && millis() < 800 ) ;
  pinMode(po, OUTPUT);
  pinMode(pi, INPUT);

Serial.print( " Pin In ==" );
Serial.println( pi );
Serial.print( " Pin Out ==" );
Serial.println( po );

}
void loop() {
  digitalWrite ( po, 1 );
  delay( 300 );
  if ( 1 == digitalRead( pi ) ) Serial.print( "\t + High Good" );
  else Serial.print( " Fail Pin In read Pin Out HIGH" );
  digitalWrite ( po, 0 );
  delay( 300 );
  if ( 0 == digitalRead( pi ) ) Serial.println( "\t - Low Good" );
  else Serial.print( "\n Fail Pin In read Pin Out LOW" );
}
 
Last edited:
Testing 8 Serial#'s Passes [ showing over 5 million full cycles now ] with variant of Frank_B sketch :: github.com ... FB_SerialChain {minor code update 1.5 hrs later.}

RE post #727 - Pogo Pins can unseat the T4 enough to disconnect Serial7 - others may have been iffy causing me grief - check board seating if it doesn't run

Sketch above works All Serial at 5,333,333 baud with T4 Beta Debug disabled ( post #726 commented in code )

@KurtE - hopefully you get/got your board? If you see any reason to change or extend this sketch - let me know { alt baud or format repeating ? End and Begin usage? Loop port Tx to port Rx rather than same port? etc. }.

I got a 10 pack of Adafruit 2 pin jumpers - used 8 of them to short Rx<>Tx on all 8 ports and ran the above sketch.

Print String at 71 chars works at speed and doesn't get lost w/default buffer size. Start print to S1 in setup(). Auto Repeats with:: [read in and forward] S1 > S2 > S3 > ... > S8 > S1
<note:> This recycles the same chars so any uncaught errors will show corrupted data going onward. The '0' in repeat string was replaced by set with 'abcdEf' to see nothing shifted and allow for counting groups of 10

All ports Serial#.begin(SPD, FMT); with same:
#define SPD 5333333
#define FMT SERIAL_8N1

Expected output:
7171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171
780800 @883676 0123456789a123456789b123456789c123456789d123456789E123456789f123456789

Row of 50 count of chars with/to NewLine i.e. 71 { that '71' value is soft coded to allow diff start string but tested against string length each pass by Serial8 }
Next row is 780800 iterations and @883676 millis() and then a print of the test string as received and forwarded
Led blink toggles each set of 50 to show active - fast but it pulses a bit more that faster flash Fault Stop.

@Mike - test A1/pin#15 is connected and does read the Audio board pot with beta breakout board.
 
Last edited:
Just did a partial SPI pull request, but there seems to still be a huge issue with SPI here.
1. Can't control SS (pin 10) manually.
2. When SPI has been started, PIN 10 is always LOW.
 
Ethernet MAC address
I'm guessin (since it matches up with Teensy 3 ether mac addresses) this is unique T4 mac address
Code:
Serial.printf("%04X%08X\n",HW_OCOTP_MAC1,HW_OCOTP_MAC0);
04E9E50186BB
my first beta T4 was 04E9E50186BA
The low order 3 bytes is USB serial number
hardware/teensy/avr/cores/teensy4/usb_desc.c
 
Yes, confirmed, HW_OCOTP_MAC1 & HW_OCOTP_MAC0 are the ethernet mac address. In this chip it's conveniently memory mapped.

FWIW, those registers are also writable. Writing to the registers is safe. You won't change the non-volatile fuses unless you do a special process with other registers. Anything you write to those register will be lost when the chip resets. At reset the hardware loads all those registers from the non-volatile fuses.
 
Just did a partial SPI pull request, but there seems to still be a huge issue with SPI here.
1. Can't control SS (pin 10) manually.
2. When SPI has been started, PIN 10 is always LOW.

I've been running Paul's T4 SPI lib and have had no trouble manually controlling CS with digitalWrite() ??? Successfully talked to SPI Serial flash on prop shield, and watched with scope.
 
@PaulStoffregen Bug. digitalWriteFast broken on T4.
Code:
// On T4 this will not blink LED unless you use const int.
// T3 is OK.
int tst=LED_BUILTIN;
void setup() {
        pinMode(tst, OUTPUT);
}

void loop() {
        digitalWriteFast(tst, HIGH);
        delay(250);
        digitalWriteFast(tst, LOW);
        delay(250);
}
I suspect digitalReadFast() is broken this way too?
 
Tim
Genuine PJRC supplied [picked up as spare parts and actually found them first place I looked] - with Filler disk for Mic : pjrc.com/store/microphone.html

And 25K Pot : pjrc.com/store/pot_thumb_25k.html {need to check pin 15 there }
Just order those and a couple other things as well as long as I was ordering. Not sure what to test next hmm....
 
Tim
Just order those and a couple other things as well as long as I was ordering. Not sure what to test next hmm....

Maybe Ethernet? I just tried to compile Ethernet udpntp example, i get compile errors, undefined reference to `vtable for IPAddress', but I have other domestic chores in the next few hours ...
 
Last edited:
@xxxajk

DigitalReadFast is still on the list to test. Tried your code it didn't work, with tst as a variable, but changing it to hardcode the pin number does work, i.e., have you tried putting a LED on another pin to test? Have to go find where i put mine

Code:
void setup() {
        pinMode(13, OUTPUT);
}

void loop() {
        digitalWriteFast(13, HIGH);
        delay(250);
        digitalWriteFast(13, LOW);
        delay(250);
}

EDIT: Put a resistor on pin 8 and sure enough, won't work unless you have const int specified.

EDIT2: DELETED Wrong info - has to be const.

EDIT3: It does work with just int pinNumber on a Teensy3
 
Last edited:
@xxxajk

DigitalReadFast is still on the list to test. Tried your code it didn't work, with tst as a variable, but changing it to hardcode the pin number does work, i.e., have you tried putting a LED on another pin to test? Have to go find where i put mine

Code:
void setup() {
        pinMode(13, OUTPUT);
}

void loop() {
        digitalWriteFast(13, HIGH);
        delay(250);
        digitalWriteFast(13, LOW);
        delay(250);
}

EDIT: Put a resistor on pin 8 and sure enough, won't work unless you have const int specified.

EDIT2: DELETED Wrong info - has to be const.

EDIT3: It does work with just int pinNumber on a Teensy3

digitalReadFast was fine.
I already submitted a pull request. And no, it doesn't have to be a constant.
The fast variants bypass checking the GPIO direction bits.
 
@PaulStoffregen Bug. digitalWriteFast broken on T4.
Code:
// On T4 this will not blink LED unless you use const int.
// T3 is OK.
int tst=LED_BUILTIN;
void setup() {
        pinMode(tst, OUTPUT);
}

void loop() {
        digitalWriteFast(tst, HIGH);
        delay(250);
        digitalWriteFast(tst, LOW);
        delay(250);
}
I suspect digitalReadFast() is broken this way too?

I have a fix for digitalWriteFast...
PR -
https://github.com/PaulStoffregen/cores/pull/326

Ooops looks like xxxajk - got one in as well a few minutes before...
Mine also had simple addition of Serial7 and Serial8 to keywords.txt...
 
@KurtE and @xxxajk: Yep - that fixed it. Had to try it, used pin2 :). Have to learn to scroll further down the page.
 
@manitou
Going to attach a SPI device and try out some of the SPI changes to see what happens later today. Have some things to take care of today.

Note: I still have two PRs not pulled in yet. One in core to do the beginnings of AVR emulation and one in SPI for some functionality, plus mainly setup to not be hard coded on the actual hardware (configured using hardware structure...)

At some point soon will try to do some DMA SPI stuff - in particular the SPI.transfer(buf, retbuf, cnt, event)
API...

Right now playing with the breakout board and testing some Hardware SPI stuff.

Running into strange issue with Serial4?
Code:
#define SERIALX Serial4
//UART6 Serial1 [0/1]  UART4 Serial2 [6/7] UART2 Serial3 [15/14] UART3 Serial4 [16/17]
//UART8 Serial5 [21/20] UART1 Serial6 [25/24] UART7 Serial7 [28/29] UART5 Serial8 [30/31]

#define BAUD 115200
#define FORMAT SERIAL_8N1
void setup() {
  while ( !Serial && millis() < 4000 ) ;

  pinMode(13, OUTPUT);
  pinMode(2, OUTPUT);
    for (uint8_t i = 0; i < 5; i++) {
    digitalWrite(13, HIGH);
    delay(250);
    digitalWrite(13, LOW);
    delay(250);
  }
  digitalWrite(2, HIGH);
  SERIALX.begin(BAUD, FORMAT);
#ifdef TRANSMIT_PIN
  SERIALX.transmitterEnable(TRANSMIT_PIN);
#endif
  digitalWrite(2, LOW);
}

uint16_t loop_counter = 0;
void loop() {
  delay(500);
  digitalWrite(2, HIGH);
  SERIALX.print("Loop ");
  SERIALX.println(++loop_counter, DEC);
  delay(100);
  if (SERIALX.available()) {
    digitalWrite(13, HIGH);
    while (SERIALX.available()) {
      int ch = SERIALX.read();
      Serial.write(ch & 0x7f);
    }
    digitalWrite(13, LOW);
  }
  digitalWrite(2, LOW);
}
Works find with all other Serials, but Serial4:
When I hook up the jumper for TX to RX, I start to get a bunch of USB Serial debug output:
Code:
Loop 42
status = 00010080
status = 00000000
status = 00010080
s00000000000000000000000000000
st00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000
status = 0001000000000000000000000000000000000000000000
000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
status = 000000000000000000000000000000000
s000
000000000000000000000000000000000000000000
s000
000000000
00
0000000000000000000000
000
00000000000000
0000
000
...
Which I believe is coming out from usb_serial.c line 222
Which maybe makes sense as Serial4 is setup for debug outputs, but not sure why this error and now?
 
Kurt - see my post - must stop debug spew? Did Web Pull Request #327 for post #726

// To use Serial4 Disable Debug :: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195229&viewfull=1#post195229

//...
Loop 307
Loop 308
// ...
Loop 4399
Loop 4400
Loop 4401
Loop 4402
// ...


My other sample overnight ran fine - no errors and 25,541,700 iterations:

7171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171
25541700 @23740665 0123456789a123456789b123456789c123456789d123456789E123456789f123456789
7171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171717171
25541750 @23740711 0123456789a123456789b123456789c123456789d123456789E123456789f123456789
 
Last edited:
@Frank and @defragster (and others),

I thought I would test some of the Serial buffering stuff to try to see maybe what is going on.... So I did a modified version of your program where you did three Serial1 outputs and not all of it showed up..

I did it sort of like one that @defragster did for T3.6 testing...

Here is the current sketch:
Code:
//connect  Serial1 TX -> Serial2 RX, Serial2 TX -> Serial3 RX, Serial3 TX -> Serial4 RX....


#define SPD 1000000
int loop_count = 0;
int receive_counts[8];
int callback_counts[8];

void setup() {
  pinMode(13, OUTPUT);
//  while (!Serial && millis() < 4000) ;
//  Serial.begin(115200);
  delay(800);
  Serial4.println("Test all Serials");
  Serial4.printf("Baud rate: %d\n", SPD);
  Serial1.begin(SPD);
  Serial2.begin(SPD);
  Serial3.begin(SPD);
  Serial4.begin(115200);
  Serial5.begin(SPD);
  Serial6.begin(SPD);
  Serial7.begin(SPD);
  Serial8.begin(SPD);
}

void loop() {

  for (int i=0; i < 8; i++) {
    receive_counts[i] = 0;
    callback_counts[i] = 0;
  }
  Serial4.printf("Loop: %d\n", ++loop_count);  
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  delay(1000);
  Serial4.println();
  for (int i=0; i < 8; i++) {
    Serial4.printf("%d: %d %d ", i, callback_counts[i], receive_counts[i]);
  }
  Serial4.println();
}

void serialEvent1() {
  digitalWrite(13, !digitalRead(13));
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial1.available()), Serial4.availableForWrite());
  Serial1.readBytes(buffer, cb);
  Serial4.write(buffer, cb);
  callback_counts[0]++;
  receive_counts[0] += cb;
}

void serialEvent2() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial2.available()), Serial2.availableForWrite());
  Serial2.readBytes(buffer, cb);
  Serial2.write(buffer, cb);
  callback_counts[1]++;
  receive_counts[1] += cb;
}
void serialEvent3() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial3.available()), Serial3.availableForWrite());
  Serial3.readBytes(buffer, cb);
  Serial3.write(buffer, cb);
  callback_counts[2]++;
  receive_counts[2] += cb;
}
#if 0
void serialEvent4() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial4.available()), Serial4.availableForWrite());
  Serial4.readBytes(buffer, cb);
  Serial4.write(buffer, cb);
  callback_counts[3]++;
  receive_counts[3] += cb;

}
#endif

void serialEvent5() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial5.available()), Serial5.availableForWrite());
  Serial5.readBytes(buffer, cb);
  Serial5.write(buffer, cb);
  callback_counts[4]++;
  receive_counts[4] += cb;
}
void serialEvent6() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial6.available()), Serial6.availableForWrite());
  Serial6.readBytes(buffer, cb);
  Serial6.write(buffer, cb);
  callback_counts[5]++;
  receive_counts[5] += cb;
}
void serialEvent7() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial7.available()), Serial7.availableForWrite());
  Serial7.readBytes(buffer, cb);
  Serial7.write(buffer, cb);
  callback_counts[6]++;
  receive_counts[6] += cb;
}
void serialEvent8() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial8.available()), Serial8.availableForWrite());
  Serial8.readBytes(buffer, cb);
  Serial8.write(buffer, cb);
  callback_counts[7]++;
  receive_counts[7] += cb;
}

Note: I am using Serial4 to do the outputs as doing Serial output appears to be flaky on mine right now...

Some outputs:
Code:
***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
  enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
USB reset took 5 loops
analogInit
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
after setup
Loop: 1
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345601563489673412904523
0: 5831 128 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 2
012345678901234567890123456789012345678901234567890123456789012345678901234589674590784523015634
0: 5901 96 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 3
012345678901234567890123456789012345678901234567890123456789012345678901234512674523014523018934
0: 5827 96 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 4
012345678901234567890123456789012345678901234567890123456789012345678901234589674523784523015634
0: 5886 96 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 5
01234567890123456789012345678901234567890123456789012345678901234567890124589674523784523018934
0: 6008 95 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 6
01234567890123456789012345678901234567890123456789012345678901234567890124512674523014523018934
0: 5920 95 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 7
012345678901234567890123456789012345678901234567890123456789012345678901234512674523784523018967
0: 5985 96 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273
A couple of interesting things here. First off all of the Serial objects received 273 bytes except for Serial1, which is probably the whole thing
figuring 273/3 = 91 bytes per line...

So probably a flow control issue ? As this one was going through USB to Serial Adapter (CP270x) from Adafruit used to test/fix issues in usbhost_t36...

Also interesting that the Serial1 event responder was called almost 6000 times each time through main code? Others were all called 91 times (3 bytes each)...

Still more to figure out...

EDIT: If You turn off debug printing... (debug\printf.h) comment out PRINT_DEBUG_STUFF.
Also needed to define
Code:
#define printf_debug_init()

And then update that Serial4 is configured to run at SPD speed. Now I see:
Code:
Loop: 2
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

0: 91 273 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 3
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

0: 91 273 1: 91 273 2: 91 273 3: 0 0 4: 91 273 5: 91 273 6: 91 273 7: 91 273 
Loop: 4
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 
Last edited:
Note: I still have two PRs not pulled in yet.

Sorry for the delay on this and pretty much everything the last few days.

Remember that thing I mentioned a couple days ago that was taking up all my time? Well, Robin & I had to fire one of our employees this week. I can't go into details, but I can tell you it was a pretty bad situation. This person had been working here ~3 years, and we had known them socially (more like a friend of several friends) for a couple years prior to working here.

I can't describe just how much this has shaken me & Robin up this week, first learning of a rather serious problem, then discovering it had been going on for quite some time, then quite a lot of soul searching and second guessing about what we should do. Maybe when you have a large management team and a well staffed HR department these things get easier? I just can't begin to describe how incredibly difficult this is for us. We both had that pit-in-your-stomach and skin crawling feeling while dealing with this. We'd spent pretty much every awake minute of the 24 hours prior to meeting with the employee, contemplating whether to fire this person, what sort of explanation and sentiment would sway us to keep them on versus show them the door. Ultimately we decided that the situation wasn't going to work out and firing them was the best option. Their response was very angry and they stormed out, yelling some obscure reference none of quite got while slamming the front door on the way out.

Within an hour, suddenly Robin & I started to have epiphany after epiphany of all sorts of warning signs and off-color behaviors we had ignored or discounted as just "personality quirks". Hindsight is pretty amazing. We also heard some pretty shocking stories from our other employee, including vaguely threatening behavior, which they were planning to soon bring up with us. Robin & I both have a very strong ethic of not letting our personal feelings influence what should be objective business decisions. Still, I'm kind of left with a lingering concern of how a festering personnel problem could escape our conscious notice for so long, are we sometimes too objective? On the balance I believe we handled this situation about as well as any small business could. I just can't quite describe how incredibly difficult the whole thing is.

Now our tiny 4-person company is now down to just 3 people, so things are still pretty far from back to normal. We've already put a quick help-wanted ad out and ~10 people have expressed interest, and a few replies look very encouraging. My hope is we will interview 1 or 2 this weekend or early next week be back up to 4 people next week.

Fortunately our inventory position is good right now, so being down 1 person for a week, and getting back up to speed with training a new person isn't going to impact the global supply of Teensy boards.

But it sure has distracted me from getting any real development work done these last few days, and for that I'm really sorry. Even now, I still feel a little shaken up by this whole thing. I will try to get to these pull requests later today. It might be a few more days until I'm back up to normal speed on software development. I really do appreciate the incredible contributions all of you are making and I the last thing I want to have to do is ask for your continued patience, but the honest truth is I'm still not quite back to ok after the drama of these last couple days.
 
Originally Posted by mjs513
@manitou
Going to attach a SPI device and try out some of the SPI changes to see what happens later today. Have some things to take care of today.
Note: I still have two PRs not pulled in yet. One in core to do the beginnings of AVR emulation and one in SPI for some functionality, plus mainly setup to not be hard coded on the actual hardware (configured using hardware structure...)

At some point soon will try to do some DMA SPI stuff - in particular the SPI.transfer(buf, retbuf, cnt, event)
API...

Right now playing with the breakout board and testing some Hardware SPI stuff.

Running into strange issue with Serial4?
@KurtE
Just tried you sketch in post #742 and it worked fine for me, just seeing the loop message on the T2 and my debug_printf is not commented out. Was also able to transmit messages from T3.2 to the T4. Modified the sketch in post #744 just to dump the data to Serial4 only and that worked as well.

As for SPI- I already pulled your SPI and AVR emulation mods into my local copy of the cores to play with. Figured I could give you some feed as well.
 
I can't describe just how much this has shaken me & Robin up this week, first learning of a rather serious problem, then discovering it had been going on for quite some time, then quite a lot of soul searching and second guessing about what we should do. Maybe when you have a large management team and a well staffed HR department these things get easier? I just can't begin to describe how incredibly difficult this is for us.
Paul. Speaking from experience no matter whether you have a HR group or not its never easy. When I was in management I had to counsel, suspend, reprimand etc, and you always get that feeling when you have to do that, especially with people you know and work with. Just hang in there, it will get better.

I think I speak for everyone - do what you have to do and worry about getting the PR's incorporated when you are ready.
 
@Paul, I don't think it gets easier to have to dismiss an employee unless the company is so big there is little interaction between management in general and the offending individual. Hope you find someone that's a better fit with you folks quickly.
 
Status
Not open for further replies.
Back
Top