Teensy 4.0 First Beta Test

Status
Not open for further replies.
FYI - When I was playing with my copy of the library, I tried a few different things to try to do 16 bit color, but it was not happy.

The document sort of sounded like maybe it supported 16 bit color in the PDF (page 121 on mine) it talks about 4 line SPI and says:
Code: 
The available display data formats are:
	 8 colors, RGB 1, 1, 1 bits input (set Standard Command 3Ah, DBI [2:0] as 001)
	 65K-Colors, RGB 5, 6, 5 bits input data (set Standard Command 3Ah, DBI [2:0] as 101)
	 262K-Colors, RGB 6, 6, 6 bits input data (set Standard Command 3Ah, DBI [2:0] as 110)
But then it only shows information about 8 color mode or 262 color mode.

And other drivers mention that it does not support 16 color mode.

Wondering if this maybe should all go in it's own thread? As not T4 specific, other than maybe 1062 specific later in having enough memory for frame buffer.
 
Some T4 specific news WRT ILI9488 - I see working XPT2046 Touch and TFT together with a trial of Frank's code that isn't fast enough to complete - but good enough to see it can work - with MISO cut. <edit 2046 touch notes> Though I need to check - the _isr routine seemed to be dribbling on a bit rather than clean break which would kill any DMA attempt - perhaps feedback on MOSI if not tristated like MISO? Need to make a clean sample so somebody with a scope can watch T4 versus T_3.6 - though with common connect through Teensy - not sure how that would work on a single SPI bus.

Paul started a 2017 post about building a display - perhaps 9488 based - Since I've not seen of a good one maybe a custom properly tri-stated 8 / 16 bit color version would be possible instead of 18 bit. Will wake that thread with link here ...

Perhaps to the robustness of the T4 - I put a PJRC OSH Purple display board [not complete build ] on my breakout with an ILI display - the breakout doesn't feed the 5V pin - so assuming no other conflicts the display must have been pulling 3.3V power from the pullups and other SPI pins I'm assuming - resulting in a hot chip on T4 board - the LDO ? Connecting back another way it is now working so it protected itself.

And I had some small func() copying five 32 bit values - it ran in about half the clock cycles on T4 it took the T_3.6 - not surprising - but noteworthy - though it seems I noted it in another context before.

Paul - did you decide on the pins to be presented on the 1062 PCB? Hopefully whatever the bottom holds there will be a friendly way to make a (castellated) daughter board to bring those pins out.
 
Last edited:
The larger display - At some point soon, will try mine again with the touch... Been busy with other stuff and seeing that it needed 3 times memory for full buffer and/or needed to go through a color table... made it not as interesting. Although in many of my cases the speed for playing around the speed is not that necessary. Mainly there to display status information. Will be interesting to see what Frank's library does different.

I am also looking forward to see the next T4, to get an idea of what all of the bottom pins are. So far I have not created SPI1, as it sounded like it was going away and currently with breakout board, some of the pins are not easy to get to.

Now back to playing!
 
hi ... a question about the "ONOFF" pin/signal:

it looks as if T4 is somewhat temperamental with it comes to using (certain) external power supplies, much like T3.6 (but unlike T3.2). in the latter case, to make sure the thing boots up properly, a/the solution is/was to use a supervisor (e.g. MIC803) and connect that to the "reset" pin ( + pullup). i'm assuming ONOFF can serve a similar purpose, but i don't quite understand the mechanics of the SNVS_LP register in this regard. the datasheet seems to suggest that by default, 1052 does "dumb PMIC mode" (p.979), with "ON_TIME" = 500msec, and "the amount of debounce time" = 50msec (p.1220-21)? is that correct?
 
Back to displays -> Again maybe should be put in other thread: But thought I would mention,

One reason I had not tried out the touch yet on this display that I received quickly from Ebay (USA) was that it has a capacitive touch screen which uses a different chip to communicate, I think I read FT6236 and uses I2C to talk to it... So thought it might not help much... But maybe will try at some point soon.
 
@mxxx - what does 'temperamental' look like? Hung or running otherwise oddly?
Only powered T4 with USB and not seen issues - except oddities when using he breakout board and the POGO pins push and unseat the T4 - it powers and runs but oddly.

KurtE said:
Back to displays -> Again maybe should be put in other thread: But thought I would mention,

One reason I had not tried out the touch yet on this display that I received quickly from Ebay (USA) was that it has a capacitive touch screen which uses a different chip to communicate, I think I read FT6236 and uses I2C to talk to it... So thought it might not help much... But maybe will try at some point soon.
Click to expand...
Good to know as I was hoping yours would work to try what I was seeing … Other thread got some life with above link maybe the right display will show up.
Bummer you got the last one of those - I missed eBay redirecting me to the rPi one I got - both that rPi display and the ILI9488 Paul linked use the same XPT2046 for touch - and other than TriState hardware issues it works like the old ili9341.
 
Lots of posts to read through to get a top level summary of T4 development. Does pjrc plan on updating posts #4, #5, and #6?

Overall, is T4 more difficult to develop than the other teensy boards?
 
randomvibe said:
Lots of posts to read through to get a top level summary of T4 development. Does pjrc plan on updating posts #4, #5, and #6?

Overall, is T4 more difficult to develop than the other teensy boards?
Click to expand...

T4 development is on the Arduino User level is just like other Teensy work - and even going lower to standard device that is developing normally too. Added MCU features and tricks are a bit more extensive and intense/opaque/fraught with options and details and might be expected with more power.

Listed posts are generally being updated at least as Beta's move along. Beta release slowed as things are generally working on the 1052 and the next hardware 1062 will present some edits and allow final features when RAM doubles and some new hardware features firm up.
 
defragster said:
Paul - did you decide on the pins to be presented on the 1062 PCB?
Click to expand...

Yes, I recently finalized the pinout. So now it won't change anymore... unless I change it again! ;)

Pins 30 & 31 on the bottom side are the only big change. Serial8 is out, CANFD is in (NXP pins EMC_37 & EMC_36).

Pins 5 & 33 were swapped. This allows access to I2S2 receive on the outside pins (with pretty much all the same features we previously had on pin 5), but I2S2 MCLK is now on the bottom side. I did quite a bit of testing with SGTL5000. There is phase shift between MCLK on I2S1 & I2S2. SGTL5000 handles it fine.

Pins 6, 7, & 8 played musical chairs. This puts Serial2 on pins 7 & 8, which might help some folks use Teensy 4.0 on boards that have been designed for Teensy 3.x.

The 10 bottom pads shifted around, so they're now positioning in a sensible order. I also made them much larger, similar to the bottom pads on Teensy 3.x.

I reversed the order and slightly shifted the position of the 8 SD card pads on the bottom side. I also added 2 ground pads. It's still far from ideal for adding a SD socket on the bottom... since the board isn't long enough and the socket hangs off the front and possibly hits the USB cable unless you have one with a slim molded connector. But this new arrangement should make adding a native SD card quite a bit easier.

Pins 26 & 27 were not changed. So anyone who needs a second SPI port can get it, by accessing those 2 pads on the bottom side.

While not technically part of the pinout, the other hardware change coming is support for the deepest sleep mode, where the 3.3V regulator is turned completely off. The PMIC_ON_REQ signal now routes to the 3.3V regulator chip, rather than having this chip wired to permanently enabled. So far I've only been testing with the ON/OFF pin, but timed wakeup from the RTC is supposed to be possible.

Also not technically part of the pinout, but a thing I've been putting quite a lot of time into recently is the "parts balance" our contract manufacturer requested. If you've looked at the bottom side of your 1052-based beta, you'll see it's filled with wires and has only 13 capacitors (actually 1 is an inductor, so 12 are capacitors). Almost all the other parts are on the top side. This isn't ideal for volume manufacturing. For a 2 sided board, they prefer to see approximately the same number of parts on each side, so the time spend on the pick and place machine is approximately equal for both sides. So almost all those wires you see on the bottom are going to move into layers 3 & 4, to make room for many of the passive parts on the bottom side (and of course to reduce the final size to the 1.4 by 0.7 Teensy form factor). Like Teensy 3.6, layers 2 & 5 are ground and power planes, so on this board almost all the signal routing will be on layers 1, 3 & 4, with just a few wires on layer 6.
 
Last edited by a moderator:
If anyone with the 1052 beta wants to hack their board for PMIC_ON_REQ, you can find a pair of (tiny 402 size) resistors just to the right hand side of the 3.3V regulator. You'll see 1 is populated and the other is not placed. One resistor connects the regulator enable to VIN, and the other to PMIC_ON_REQ. Whatever you do, DO NOT POPULATE BOTH RESISTORS, since that would short 5V to the not-5V-tolerant PMIC_ON_REQ and almost certainly destroy your chip.

Sadly, just soldering a 0 ohm resistor (or really, any low value... I believe we used 22 ohm light blue colored resistors on most of the prototypes) isn't enough to make PMIC_ON_REQ work properly. It also needs a pullup resistor. But NOT a pullup to any of the normal supplies, since they all shut off in some cases where you need the pullup. It needs a pullup to the always-on backup power. On the 1052, you can find this on a test point located just above the fiducial mark located near pins 11 & 12. You can also find PMIC_ON_REQ on a test point located above and slightly to the right of pin 0, so it's easiest to solder the pullup resistor between those 2 test points. The pullup wants to be a pretty high impedance. I've been testing mostly with 1M (because that's what I had handy in my draw of higher value through-hole resistors), but considering using 2.2M. The resistor is unfortunately driven with a small voltage during the deepest sleep, so using a lower impedance wastes power in the that mode.
 
PaulStoffregen said:
Yes, I recently finalized the pinout. So now it won't change anymore... unless I change it again! ;)
...
Click to expand...

Sounds awesome. Assuming that can get drawings done and somewhere in process to test … will the next 1062 beta be down to 0.7" wide? Or another wider iteration with extra test points? Did USBHost pins move so they aren't in the way of SD adapter? Supposing you've gotten at least one 1062 assembled in some fashion and not had any surprises?
 
defragster said:
Supposing you've gotten at least one 1062 assembled in some fashion and not had any surprises?
Click to expand...

Nope, haven't even wrapped up the 6 layer first attempt. Hoping to send the files for PCB fab in about 1 week. Need to meet with our contract manufacturer first...

But I do have a very early prototype where I tested the bootloader with the 1062 chip. The 1052 & 1062 have different JTAD ID numbers and their boundary scan chains are different (used for the 15 sec recovery), but otherwise they're pretty much identical so I'm not expecting much in the way of problems. Well, that is if I don't mess up the 6 layer PCB in some way...

At least for now, we're still very much in the 1052 chip for actual software testing.

For anyone following who's on the list of people we've approved but hasn't got hardware yet, I do have 5 more beta boards, with the full set of stuff... the breakout with pogo pins, which gives you an audio shield & switch to route it to I2S1 or I2S2, and the USB host connector, and 8 serial ports.

Not sure if we'll do a similar breakout board for the 1062 boards. By that point, we'll be pretty close to release and I'll probably be focused again almost entirely on the software side, so a fancy breakout board for the 1062 boards seems unlikely.
 
PaulStoffregen said:
I reversed the order and slightly shifted the position of the 8 SD card pads on the bottom side. I also added 2 ground pads. It's still far from ideal for adding a SD socket on the bottom... since the board isn't long enough and the socket hangs off the front and possibly hits the USB cable unless you have one with a slim molded connector. But this new arrangement should make adding a native SD card quite a bit easier.
Click to expand...

Looking forward to this solution. At the moment I added a 1mm pitch flat wire connector, where the pins are bent to fit the 1.1 mm pitch of the uSD pads.
This is far less ideal than having the uSD going outside board.
 
defragster said:
@mxxx - what does 'temperamental' look like? Hung or running otherwise oddly?
Only powered T4 with USB and not seen issues - except oddities when using he breakout board and the POGO pins push and unseat the T4 - it powers and runs but oddly.
Click to expand...

yeah, hung / not booting, 'temperamental' was vague phrasing, sorry ... it looks much like the issues reported here, PSU coming up too slow; i have some leftover MIC803s (140ms), so i figured i might give this a try, but i'm not entirely sure i'm getting the "button"-vocabulary in the datasheet. the on/off pin seems to be pulled high (~ 2.7V), so i'm assuming pulling this low for x amount of time ("debounce time"?), then high again should do the trick?
 
Bummer on the alt power hang - with no led LED Flash or anything out Serial4 ... - that does sound like noted power issue. Will it go to bootloader with button?

I get 2.91V on Power On/Off when running. I suppose I didn't short long enough before! When it did nothing for a couple seconds I assumed maybe it wasn't ready and I didn't want to break it.

Shorting O/O to GND for 5 seconds takes it off! Then I see 2.97 V

Shorting again for under 0.5 sec powers it back up!

I hit reset during Power O/O short. Windows showed >> Setting up "SE Blank RT family"? Had to repower to restart Teensy.

When in Bootloader O/O does not work? It seems that would be the ideal way to fix an accidental button press?
 
mxxx said:
the on/off pin seems to be pulled high (~ 2.7V), so i'm assuming pulling this low for x amount of time ("debounce time"?), then high again should do the trick?
Click to expand...

Before messing with the on/off pin, please try commenting out the CPU speed change in startup.c.

Code: 
        set_arm_clock(600000000);

I've seen this cause problems with startup when certain types of external power are used. This code is probably going to need to increase the speed in smaller steps, maybe add delays or other timing so we don't make such rapid changes, especially so soon after powerup.

The speed change may or may not be related to the issues you're seeing, but please disable it so you can rule out this
 
So, this is the new mapping?

Code: 
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
 0     AD_B0_03   1.3   UART6_RX       3:CS0   PWM1_X1  2_RX             IO-17
 1     AD_B0_02   1.2   UART6_TX       3:MISO  PWM1_X0  2_TX             IO-16
 2     EMC_04     4.4                          PWM4_A2        2:TX_DATA  IO-06   1:4
 3     EMC_05     4.5                          PWM4_B2        2:TX_SYNC  IO-07   1:5
 4     EMC_06     4.6                          PWM2_A0        2:TX_BCLK  IO-08   1:6
[COLOR=#ff8c00] 5     EMC_08     4.8                          PWM2_A1        2:RX_DATA  IO-17   1:8
 6     B0_10      2.10                         PWM2_A2,QT4_1  1:TX3_RX1          2:10
 7     B1_01      2.17  UART4_RX               PWM1_B3        1:TX_DATA  IO-15   2:17,3:17
 8     B1_00      2.16  UART4_TX               PWM1_A3        1:RX_DATA  IO-14   2:16,3:16 [/COLOR]
 9     B0_11      2.11                         PWM2_B2,QT4_2  1:TX2_RX2          2:11
10     B0_00      2.0                  4:CS0   QT1_0          MQS_RIGHT          2:0     
11     B0_02      2.2                  4:MOSI  QT1_2    1_TX                     2:2
12     B0_01      2.1                  4:MISO  QT1_1          MQS_LEFT           2:1     
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
13     B0_03      2.3                  4:SCK   QT2_0    1_RX                     2:3
14/A0  AD_B1_02   1.18  UART2_TX               QT3_2          SPDIF_OUT          3:2     A1:7,A2:7
15/A1  AD_B1_03   1.19  UART2_RX               QT3_3          SPDIF_IN           3:3     A1:8,A2:8
16/A2  AD_B1_07   1.23  UART3_RX  3_SCL                       SPDIF_EXTCLK       3:7     A1:12,A2:12
17/A3  AD_B1_06   1.22  UART3_TX  3_SDA                       SPDIF_LOCK         3:6     A1:11,A2:11
18/A4  AD_B1_01   1.17   2_cts    1_SDA        QT3_1                             3:1     A1:6,A2:6
19/A5  AD_B1_00   1.16            1_SCL        QT3_0                             3:0     A1:5,A2:5
20/A6  AD_B1_10   1.26  UART8_TX                              1:RX_SYNC          3:10    A1:15,A2:15
21/A7  AD_B1_11   1.27  UART8_RX                              1:RX_BCLK          3:11    A1:0,A2:0
22/A8  AD_B1_08   1.24                         PWM4_A0  1_TX                     3:8     A1:13,A2:13
23/A9  AD_B1_09   1.25                         PWM4_A1  1_RX  1:MCLK             3:9     A1:14,A2:14

Bottom:
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
24/A10 AD_B0_12   1.12  UART1_TX  4_SCL        PWM1_X2                                   A1:1  
25/A11 AD_B0_13   1.13  UART1_RX  4_SDA        PWM1_X3,GPT1_CLK                          A1:2
26/A12 AD_B1_14   1.30                 3:MOSI                 1:TX_BCLK          3:14    A2:3  
27/A13 AD_B1_15   1.31                 3:SCK                  1:TX_SYNC          3:15    A2:4  
28     EMC_32     3.18  UART7_RX               PWM3_B1
29     EMC_31     4.31  UART7_TX       1:cs1   PWM3_A1
[COLOR=#ff8c00]30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22[/COLOR]
32     B0_12      2.12                                        1:TX1_RX3  IO-10   2:12
[COLOR=#ff8c00]33     EMC_07     4.7                          PWM2_B0        2:MCLK     IO-09   1:7[/COLOR]
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Edit: Added changed pins 30 & 31


UARTn Serialx mapping pins [RX/TX]
Code: 
        UART6 Serial1 [0/1]   UART4 Serial2 [7/8]
        UART2 Serial3 [15/14] UART3 Serial4 [16/17]
        UART8 Serial5 [21/20] UART1 Serial6 [25/24] 
        UART7 Serial7 [28/29]
Edit: Serial2 on [7/8]
 
Last edited:
Frank B said:
So, this is the new mapping?
Click to expand...

That's 4 of the 6 changed pins.

Pins 30 & 31 changed, dropping Serial8 and adding CANFD


Code: 
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22
 
Hi Paul, hi everyone!

I have been silent for some time since I received my T4 beta board. I apologize for this...

In a first time I did observe from far away the great job achieved by the team so far. Congratulation for this!
The w-e I decided to remove the T4 from its socket and do some wiring on the breadboard and I ported the Zx81 emulator to the T4.
I had few problems: some I could resolve , some I need your help:
- I had to move away the SD API from SDFat (long name) to the SD library (8.3 filename) as I could not figure out how to fix SDFat library => ok
- I had to move the I2c keyboard from i2c_t3 to Wire library => no problem, I have no real preference...
- I disable VGA support for the moment, not sure if someone managed to port it. I does not look strait forward to me.
- I disabled Sound => It is not clear which of the 26 pins is the DAC0 of the T3.6?
- I update my IL9341 library with the DMA routine from Frank and Kurt samples
It is working but I have some issue with the display because the frame buffer does not seem to be allocated in DMAMEM.
I tried static DMAMEM buffer and using malloc, no difference.

https://github.com/Jean-MarcHarvengt/teensyMCUME
- teensy81: the emulator port. Put your zx81 image in /z81 on the SD card of the ILI
(I use that one and not the one provided with the T4 beta HW)
- teensylogo: a small sample listing the files of the SD card. Press fire to see MCUME logo in DMA mode

Pinout 3.6 (upper part is 4.0!) is also there if somebody wants to try.

May be someone can clarify what I do wrong with the DMA memory?

Thanks!
 
PaulStoffregen said:
That's 4 of the 6 changed pins.

Pins 30 & 31 changed, dropping Serial8 and adding CANFD


Code: 
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22
Click to expand...

Too bad, getting rid of EMC_23 and EMC_24 removes the only GPT timer capture pins.:(
 
@Jean-Marc: two notes
- I disable VGA support for the moment, not sure if someone managed to port it. I does not look strait forward to me.
- I disabled Sound => It is not clear which of the 26 pins is the DAC0 of the T3.6?
Click to expand...

> no word from the original VGA maker - would be nice [ @qix67 : Teensy-3-6-VGA-driver ]
> Such a DAC doesn't exist on the T4 MCU :(
 
Last edited:
Status
Not open for further replies.
Back
Top