Teensy 4.0 First Beta Test

Status
Not open for further replies.
Paul I have a Hub that seems to be putting power to the T4 through USBHost port? It is with the T4B2m on PJRC breakout, with UARTS active and connected on Serial #2 and #4.

I just got a new USB Drive Box with a Powered Hub built in. This HUB seems to be sending power back up - is that possible through the USB 'chip' on the breakout?

What I see: Power the UARTS and the T4B2m.
> Cut power to the USB ( I have a switch on 5V - leaves GND and USB +/- data lines attached )
> The T4 does not go offline - because the UART power is keeping the USB on MCU powered ( USB HUB DEVICE not connected yet )
> Plug in my Orico Powered Hub drive box - and The T4 BOOTS with "***********IMXRT Startup**********" messages out Serial4 to the T_3.1.

- I assume this means the Orico Hub unit is breaking a rule feeding power to the host? This does not happen when I plug in Amazon powered Hub - or a powered external Drive box.

<edit> MCU's USB not going 'offline' due to power from UART pins seems an issue when device powered by USB loses USB power?
 
Last edited:
Question: With the release coming up, is there a good summary of the form factor and pinout/s of the version 4 Teensy linkable somewhere?
Maybe it's also available on some post in this thread, but ... 119 pages ...
 
Laser cutting is pretty easy, at least for acrylic.

Really Robin deserves much of the credit. She does so much behind the scenes that nobody ever sees, which really maximizes the time I can spend on development work.
 
Quick question, is there an update to the positions of the SD Pins under the board? I believe I remember you mentioning that they changed from 1.1mm to 1mm spacing?

The last positions I remember seeing looked like:
Code:
SD DAT1, x=340, y=527.17
SD DAT0, x=340, y=483.86
SD GND, x=340, y=440.55
SD CLK, x=340, y=394.24
SD 3.3V, x=340, y=353.94
SD CMD, x=340, y=310.63
SD DAT3, x=340, y=267.32
SD DAT2, x=340, y=224.02
 
Yes, the SD pads moved and changed to 1 mm spacing.

Rather than pogo pins, the intended connection method is to solder a HFW8R-1STE1LF (or similar FFC connector) onto the T4 and your breakout board, and plug a flat flex cable into both.

With that in mind, here are the new locations of the pads.

SD DAT1, x=361.22, y=487.80
SD DAT0, x=361.22, y=448.43
SD GND, x=361.22, y=409.06
SD CLK, x=361.22, y=369.69
SD 3.3V, x=361.22, y=330.32
SD CMD, x=361.22, y=290.95
SD DAT3, x=361.22, y=251.58
SD DAT2, x=361.22, y=212.21
 
@PaulStoffregen and @.....
I have been playing around with CANFD and decided to try and implement FIFO for FD which is in the manual..... I am tried this in the whole program but it hung so decided just to try and read a single register. I used the following sketch for a test:
Code:
/* LED Blink, Teensyduino Tutorial #1
   http://www.pjrc.com/teensy/tutorial.html
 
   This example code is in the public domain.
*/

// Teensy 2.0 has the LED on pin 11
// Teensy++ 2.0 has the LED on pin 6
// Teensy 3.x / Teensy LC have the LED on pin 13
const int ledPin = 13;

// the setup() method runs once, when the sketch starts

void setup() {
  // initialize the digital pin as an output.
  pinMode(ledPin, OUTPUT);
  Serial.begin(115200);
  delay(5000);
  Serial.println(FLEXCAN3_ERFCR,BIN); [COLOR="#FF0000"]  //#define FLEXCAN3_ERFCR	(IMXRT_FLEXCAN3_EXT.offset10C)[/COLOR]
}

// the loop() methor runs over and over again,
// as long as the board has power

void loop() {
  digitalWrite(ledPin, HIGH);   // set the LED on
  delay(1000);                  // wait for a second
  digitalWrite(ledPin, LOW);    // set the LED off
  delay(1000);                  // wait for a second
}
only thing is that it crashes with a hard fault:
Code:
Fault irq 3
 stacked_r0 ::  20000CAC
 stacked_r1 ::  00000124
 stacked_r2 ::  401D8B00 [COLOR="#FF0000"] //#define IMXRT_FLEXCAN3_EXT	(*(IMXRT_REGISTER32_t *)0x401D8B00)[/COLOR]
 stacked_r3 ::  00000000
 stacked_r12 ::  BD439166
 stacked_lr ::  09600000
 stacked_pc ::  00000096
 stacked_psr ::  61000000
 _CFSR ::  00008200
      (PRECISERR) Data bus error(address in BFAR)
      (BFARVALID) Bus Fault Address Valid
 _HFSR ::  40000000
      (FORCED) Forced Hard Fault
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  401D8C0C
 _MMAR ::  401D8C0C
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 75 / 3 / 1
ARM PLL=80002064
I am beginning to wonder whether its actually implemented or just a pipe dream of NXP.
 
Last edited:
@mjs513 - My guess is that you need to enable the CCM_clock/bit associated with this in order to access the registers?

Example to touch the LPUART6 registers used for Serial1...

We use the CCM_CCGR3 and CCM_CCGR3_LPUART6(CCM_CCGR_ON),

Not sure yet which one maps here to those registers.

EDIT: maybe CCM_CCGR7? and
#define CCM_CCGR7_CAN3_SERIAL(n) ((uint32_t)(((n) & 0x03) << 8))
 
@KurtE
Think if you just read the registers you don't have to enable the clocks. But if I run the primary CANFD sketch where I enable the clocks like so:
Code:
  //clock settings for flexcan
  CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(2) |CCM_CSCMR2_CAN_CLK_PODF(3);
  //CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(0) | CCM_CSCMR2_CAN_CLK_PODF(0);
  Serial.print("CCM_CSCMR2: ");Serial.println(CCM_CSCMR2, HEX);
  
  CCM_CCGR0 |= (0xF << 18);
  CCM_CCGR7 |= CCM_CCGR7_CAN3(CCM_CCGR_ON); 
  CCM_CCGR7 |= CCM_CCGR7_CAN3_SERIAL(CCM_CCGR_ON);
Which I know works from prior CAN tests. I will still get the fault at the same address:
Code:
 stacked_r2 ::  000003E8
 stacked_r3 ::  0000028D
 stacked_r12 ::  04CA6673
 stacked_lr ::  09600000
 stacked_pc ::  00000C70
 stacked_psr ::  610F0000
 _CFSR ::  00008200
      (PRECISERR) Data bus error(address in BFAR)
      (BFARVALID) Bus Fault Address Valid
 _HFSR ::  40000000
      (FORCED) Forced Hard Fault
 _DFSR ::  00000000
 _AFSR ::  00000000
[COLOR="#FF0000"] _BFAR ::  401D8C0C[/COLOR]   // address for FLEXCAN3_ERFCR
 _MMAR ::  401D8C0C
The address does match whats in the manual.
Code:
FlexCAN3 (CANFD) base address: 401D_8000h
ERFCR Offset = C0Ch

To be hones - never really run across this issue before with reading address. The way I found it what I was trying to modify the register per the manual to configure the FIFO and it would just hang at that point. To be honest - think its hanging for all the Enhanced FIFO registers.
 
As an update to post #2961 I just tried to print that same register out from the 1062EVB using the CANFD example and it hard faulted as well at the accessing of the register. Printed at the same time I was printing out other registers. The only difference was that the fault was more cryptic in the SDK. :) than on the Teensy.
 
Hi Mike, not sure about the fault... But ran across some of these like definitions before:

As you mentioned: the address for the register is 401D8C0C
And as you mentioned the base address is: 401D_8000h

The define you mentioned: //#define FLEXCAN3_ERFCR (IMXRT_FLEXCAN3_EXT.offset10C)
The first appearance of issue is that the offset is 0xc0c... But the offset fields don't go that high...

So they have the define for the actual start of the structure defined as: #define IMXRT_FLEXCAN3 (*(IMXRT_REGISTER32_t *)0x401D8000)

But to get high enough they defined another offset by 0xB00: #define IMXRT_FLEXCAN3_EXT (*(IMXRT_REGISTER32_t *)0x401D8B00)

So the offset of 10c added here gets up to the right address...

But then there is your fault....
 
@KurtE
Yeah - had to sort the addresses out as well to understand them.

Only added the RM address to show that the addresses were correct between the core and manual. This was a sanity check on my part as well but then I get the fault on the Teensy and when I tried the same thing on the 1062EVKB I get a fault as well trying to access that register for reading.

Doing a little digging on the NXP forum found a couple CANFD presentations from a year or two ago that stated CANFD FIFO is not supported only legacy FIFO (that's CAN 2.0B) but the manual describes everything you need to implement enhanced FIFO. So now beginning to wonder. Something strange.
 
I just tried the beta 47, and the demo reel 100 for fastled doesnt compile it complains about invalid pin for 11 and 13 even though those are supposed to be spi pins for the 4b2 and 1, just thought I'd let you guys know, it does compile for 3.1/3.2 and 3.6
 
@firehopper - Does not compile for me either. From what I can tell there is no code currently in this library to support the T4 boards...
 
@firehopper >> Looks like in :: T:\Ard186t4b2\hardware\teensy\avr\libraries\FastLED\led_sysdefs.h

There is special case code for K66 and nothing for 1062:
Code:
#elif defined(__MK66FX1M0__) || defined(__MK64FX512__)
// Include k66/T3.6 headers
#include "platforms/arm/k66/led_sysdefs_arm_k66.h"

And that trickles down to the commonly used :: #define FASTLED_TEENSY3
 
Paul - I am now getting use out of the USB HUB/Drive enclosure - with HUB code in the Disk write samples - works the same on T_3.6 but using a T4 and finding the HUB will backpower the T4 from the HOST USB adapter as noted in prior post #2952 on this thread - link prior is in the 'USBHost_t36-USB-Mass-Storage-Driver-Experiments' {p#226 is when it went working} - I didn't see what that Orico USB hub/drive box does on a T_3.6. But on the T4 it results in external power applied when pulling the T4 USB device cable leaves it running - but as noted this thread post #2889 when a T4 is externally powered and USB Device connection to host PC is removed - the T4 USB Serial will not connect again until it does a restart ( Power Off/On button or external power removed ).

<EDIT>: I just tested the Orico Hub/Drive enclosure on T_3.6 USBHost - when I unplug the USB Serial power cable the T_3.6 shuts down and restarts when I plug the Serial USB cable back in. The code and drive/Hub works same on T4 as on T_3.6 - as expected since the author @wwatson has been working on it with only his T_3.6 to date. Maybe this is just a wiring issue on the T4 breakout letting the power flow in from the device on the host port - per post #2952 - the hardware on T_3.6 doesn't act the same.

KurtE says he's had devices like this before on robots where it would back feed the rPi and other parts so hopefully not hurting anything using this device?

Hoping the #2889 issue is just a USB stack adjustment and not USB controller in the MCU going to an odd state. I assume this is not Kosher - but not uncommon and the resultant behavior follows along with purposefully connecting External 5V when VUSB<>VIN is cut as I did and noted I a post linked here #2889.

Also noted post #2877 - but maybe part of the same issue was that while the PCB edit to Brown Out from UART pins was corrected on T4B2m - the power on these UART pins does keep the RTC segment and USB 'controller' alive on data lines when only the 5V line is cut in the cable - or when the Power Off button is pressed - the PC still sees the T4 USB as 'connected' as the UART pin power is feed the PCB green LED and the vBat section of the MCU as noted there.

If those posts don't have usable needed detail to understand them as 'software' issues let me know .


@firehopper - posts #4 and #6 have notes on WIP and issues. In #4 under FASTLED I found this link that might help: Teensy-4-0-First-Beta-Test
 
Last edited:
I see, not that it matters, I dont have a beta board anyway so :) I was just playing around. I'm not skilled enough to figure out how to fix it, still pretty much a coding noob :)
 
Another quick update... I've been quiet these last few days, focusing all my dev time on the test fixture.

Last Thursday we sent the latest beta hardware to ETMoody3, KurtE, wwatson, and xxxajk. These are essentially the same as the last round, except the 8 tiny pogo pins are replaced by flat flex cable. I also added a coin cell holder (CR2032) for VBAT power, but we're not sending batteries since the postal service tends to freak out if they see "lithium".

If anyone on the list wants to jump in to the beta test, or anyone with only the early 1052 or a 1062 having the brown-out restart bug wants the latest (and final) beta hardware, please email me & Robin. We'll have more ready next week. Looks like we can make about 20 more beta kits (with the breakout board) before release. Everyone on the list who didn't join the beta will get a final release T4, but it won't come with the fancy breakout board. I will publish the breakout board files & info if anyone wants to build their own.

We're going to finalize the T4 design and order the first production batch of PCBs next Tuesday. The final design will be the same as these latest betas, except the white wire you see on the bottom side will be inside the PCB on layer 4.

My hope is to wrap up the test fixture by the middle of next week. Then I'll be able to focus on the software side. Initially that's going to be fixes for bootloader bugs, especially the 15 sec restore process. Then in a couple weeks I'll transition to mostly porting libs and USB device support.
 
@PaulStoffregen - Sounds great, will be fun to play. Also will be interesting to see how that flat flex cable works!
 
Also will be interesting to see how that flat flex cable works!

Me too.

To test each breakout board, I ran the "listfiles" example using a single Sandisk Ultra SD card. I only quickly glanced at the serial monitor to see it listed the card's directory. Haven't done any other testing with the FFC cable.
 
@PaulStoffregen Wow Paul. Never a dull moment over there. I saw that other post about folks beginning to wonder about kickstarter - getting closer and closer.
 
Status
Not open for further replies.
Back
Top