Teensy4 - Hardware Serial Conflicts?

Status
Not open for further replies.

PhoPAC

New member
** Teensy 4 installed in a custom board interfacing DDC118 from TI..

I can upload the simple program below and both USB Serial and HW Serial4 (pins 17 & 18) work fine..

Code:
//TEENSY 4.0 - HW Serial Test
#define HWSERIAL Serial4

#if defined(__IMXRT1062__)
extern "C" uint32_t set_arm_clock(uint32_t frequency);
#endif

void setup() {
  // put your setup code here, to run once:
	set_arm_clock(528000000);

	Serial.begin(115200);
	
	HWSERIAL.setTX(17);
	HWSERIAL.setRX(16);
	HWSERIAL.begin(115200,SERIAL_8N1);
	
}

void loop() {
	Serial.println("Hello - SerialUSB");
	HWSERIAL.println("Hello - HWSERIAL");

}

However; when I load my full program that interfaces a DDC118 utilizing several PWM clock pins and HW interrupts pins for data capture.. the USB Serial works and HWSerial will *NOT* work. I have verified that I'm not using or setting PINs 16 & 17 elsewhere in the code. My data results function should output same serial text over the USB and HW Serial4. My debug source is direct logic from Saleae.

?My Question-- There must be other calls to program elements that can interfere with Teensy 4.0 HW Serial4 -- might they set registers and disable the HW Serial? Thoughts on areas to check?

Thank you.

Regards,
PhoPAC
 
Sorry, don't see enough stuff here to have a clue.

That is in many cases like this, it is often things like your software crashed and system was in a bad state... Things like derefencing a NULL pointer.

Some other possibilities include you turned off interrupts. Or sometimes you setup your own interrupts and don't resolve why the interrupt handler was called (i.e. clear an approriate bit, or read from some register or ...) and the code is hung going in and out of that ISR...

But again no details here.

As I mentioned in another thread recently, sometimes if you are using things like Serial.print(...) or in your case like Serial4.print(...) and your code crashes in this way, not all of the stuff that is cached is output and you may not be where you think you are... So when in suspecting crashing, I often add things like: Serial4.flush(); after my debug prints, to force them out before the code continues.

As for Hardware Serail4, if you touch the registers for IMXRT_LPUART3 you can run into issues, or if you overwrite their interrupt vector or, change something of the clock tree associated with how hardware Serial ports are clocked. See figure 13-3 in PDF...
 
Sorry, don't see enough stuff here to have a clue.

That is in many cases like this, it is often things like your software crashed and system was in a bad state... Things like derefencing a NULL pointer.

Some other possibilities include you turned off interrupts. Or sometimes you setup your own interrupts and don't resolve why the interrupt handler was called (i.e. clear an approriate bit, or read from some register or ...) and the code is hung going in and out of that ISR...

But again no details here.

As I mentioned in another thread recently, sometimes if you are using things like Serial.print(...) or in your case like Serial4.print(...) and your code crashes in this way, not all of the stuff that is cached is output and you may not be where you think you are... So when in suspecting crashing, I often add things like: Serial4.flush(); after my debug prints, to force them out before the code continues.

As for Hardware Serail4, if you touch the registers for IMXRT_LPUART3 you can run into issues, or if you overwrite their interrupt vector or, change something of the clock tree associated with how hardware Serial ports are clocked. See figure 13-3 in PDF...


Hello KurtE,

After adding a testbit to my interrupts and watching the logic an interrupt was firing and not allowing the Serial4.print. The Serial.print was above the attachInterrupt and the Serial4.print was below.

Problem solved. Thank you.

Regards,
PhoPAC
 
Just looked this up for another post last night - going back 4 years ...

This - in that post - was noted to be written in this order:
Code:
[B]	HWSERIAL.begin(115200,SERIAL_8N1);
[/B]	HWSERIAL.setTX(17);
	HWSERIAL.setRX(16);

Maybe both orders were coded to work ?

<edit>: just parsing new posts and see @KurtE addressed this here :: Accessing-quot-Serial-port-2-quot-using-the-Teensy-3-2-bottom-pads

Obviously it is working now so not an issue
 
Status
Not open for further replies.
Back
Top