Teensy 4.0 First Beta Test

Status
Not open for further replies.
@MichaelMeissner: I asked Daniel Gilbert (TallDog on Tindie) about his plans for a T4 breakout board similar to his DIP-64 and Standard t3.6 breakouts on Tindie. Here's his response yesterday:

"I’ll definitely have a Teensy 4.0 breakout if it needs one, which I think it will. Unfortunately Paul’s already distributed all the betas, and I can’t seem to find any pictures of the pin layout yet. There’s a preliminary pinout card, but it doesn’t show the pin/pad locations."

I'm a big fan of his DIP-64 T3.6 board.

I just want to say that I'm hugely disappointed when I look at the pinout/form-factor of the T4. My apps need the processing power of the T4, but also need lots of digital pins for front panel communication etc. I'm thinking ahead, and it's going to be a major PITA if I have to redesign everything to use I2C to talk to a sub-processor that handles the encoders etc. That was the reason for asking Daniel about his plans...

@Paul: Maybe you could work with Daniel to facilitate the production of a convenient breakout board?

I'm not sure if you are on the beta list, or just waiting for the T4 to be announced in public. There are two different sets of underneath pads on the T4. There are 10 pins that look to be spaced at 0.1" intervals. Then there are the 6 pins (plus 3.3v and ground) that have a much finer pitch. But yeah, it will probably make sense to start planning off board processors for things like lights and human interaction. It may make things more modular.

There are plenty of different communication channels spread over the 40 pins.

Besides I2C, there are 7 serial lines, that may be easier to do communication to Teensy LC's or similar boards. I'm not sure whether there is CTS/RTS however.
  • Serial1: RX1 = 0, TX1 = 1;
  • Serial2: RX2 = 7, TX2 = 8 (same position as RX3/TX3 on Teensy 3.x);
  • Serial3: RX3 = 14, TX3 = 15;
  • Serial4: RX4 = 16, TX4 = 17;
  • Serial5: RX5 = 21, TX5 = 20 (alternate underneath pads, RX5 = 38, TX5 = 39);
  • Serial6: RX6 = 25, TX6 = 24 (underneath pads);
  • Serial7: RX7 = 28, TX7 = 29 (underneath pads).

Three SPI buses:
  • CS0 = 10, MOSI0 = 11, MISO0 = 12, SCK0 = 13;
  • MOSI1 = 26, SCK1 = 27 (no CS or MISO listed, so presumably for output only);
  • CS2 = 36, MOSI2 = 35, MISO2 = 34, SCK2 = 37.

Three I2C buses:
  • SCL0 = 19, SDA0 = 18;
  • SCL1 = 16, SDA1 = 17;
  • SCL2 = 24, SDA2 = 25 (underneath pads).

Three CAN buses:
  • CRX1 = 23, CTX1 = 22 (alternate CRX1 = 13, alternate CTX1 = 11);
  • CRX2 = 0, CTX2 = 1;
  • CRX3 = 30, CTX3 = 31 (underneath pads).

One USB host in addition to the normal USB input that uses pins 34-39
 
Last edited:
@MichaelMeissner: I asked Daniel Gilbert (TallDog on Tindie) about his plans for a T4 breakout board similar to his DIP-64 and Standard t3.6 breakouts on Tindie. Here's his response yesterday:

"I’ll definitely have a Teensy 4.0 breakout if it needs one, which I think it will. Unfortunately Paul’s already distributed all the betas, and I can’t seem to find any pictures of the pin layout yet. There’s a preliminary pinout card, but it doesn’t show the pin/pad locations."

All of the information is contained within this thread... If you search for it.

That is for example the SDCard pins changed positions in the recent beta. Not sure how he would like to do this. Mini-Pogo pins like Paul did with earlier ones, or with the connector that he used in the recent ones. In which case the exact position does not matter. But as for details:

The posting: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=206543&viewfull=1#post206543
Shows those new locations:
Code:
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

The main posting earlier that Paul did of the positions is at: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=200666&viewfull=1#post200666
Code:
Pin 24: x=1182, y=550
Pin 25, x=1018, y=550
Pin 26: x=1182, y=450
Pin 27, x=1018, y=450
Pin 28: x=1182, y=350
Pin 29, x=1018, y=350
Pin 30: x=1182, y=250
Pin 31, x=1018, y=250
Pin 32: x=1182, y=150
Pin 33, x=1018, y=150
USB2 D+, x=72, y=305
USB2 D-, x=72, y=395
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

Note: I edited the two D+ to one being D-

I then noted in a different message that these positions for pins 24-33 are what you would probably use for POGO pins. But if instead you wish to use through hole SMT pins like used on T3.2 or the like. which it is setup for (except it uses a 2x5 instead of a 2x7), and it is turned 90 degrees. Then the X positions change.

That is instead of x = 1018 you would use 1050 (Pins are between pins 9 and 16)
instead of X = 1182 you would use 1150 (Pins are between pins 10 and 15)

Again all of this is in the thread.. Not sure why anyone would have a hard time finding it? There are only a little over 3650 messages ;)

Kurt
 
@ MichaelMeissner and others

As for your earlier question if anyone is making a breakout board. I know there are a few of us that are. I am not sure yet if anyone will have some easy to assemble ones, but that will be on tindie or the like, although sounds like maybe...

I have a first version one that I am playing with. The first version I screwed up on the SDCard ribbon connector on the board and reversed the pin order... The good news is that the boards I ordered with that hopefully fixed should arrive today... Mine is sort of a hodge podge of things sortof GP and sort of not. That is:
I have all of the pins hopefully brought out: I have another row of pins that are just outside the socket for all of the standard pins Gnd-12 and VIN-13. I then have an SMT type connector that solders onto bottom of T4 and goes to the locations mentioned in previous post. And I have those going to a set of 2x5 connections to the right of T4 (with T4 USB on left of board). I have SD connector with ribbon connector on board (What a pain these can be for us who are soldering challenged :D ), with these I have it going out to an SD card connector, plus near the connector I have them broke out into 1x6 .1" pins so can use as standard IO pins... I have Pogo pins, which go to USB host location, and setup with the voltage chip to connect to USB host connector... Plus I brought out 2 pins for USB+ and USB- here to make it easier for me to capture traces on LA...

But then non-general purpose:
I have it setup to use a Pololu DC/DC converter plus power connector.
Same size as ILI9341 display pins setup to use one, plus ability to drive DISP pin by PWM...
one Neopixel
Setup to solder on castellated RFM95
Setup to do Dynamixel servos (half duplex with level shifting to 5v)

I have only assemble part of the first batch to allow me to easily get to the IO pins, and have not fully tested that part yet. I can get to the main ones...

Will probably at some point make a simpler version of above to play with for Robots. Not sure yet what I will use or drop. Right now would be fun to have an Arduino Mega foot print as to try out some of these displays, like one I have for ILI9486 with mega pin layout...
 
@Frank B:
I have a test WAV file that is sampled at 12kHz. I've modified the example WavFilePlayer to add setI2SFreq and then play the wav files like this:
Code:
  setI2SFreq(12000);
  playFile("000001.WAV");  // filenames are always uppercase 8.3 format
  delay(500);
  setI2SFreq(44100);
  playFile("SDTEST1.WAV");  // filenames are always uppercase 8.3 format
  delay(500);
Works perfectly. However, I then added some other WAV files for it to play which are sampled at various rates including 8kHz, 11025Hz, 12kHz and 44.1kHz and that doesn't work as well. I'm currently digging into play_sd_wav.cpp to try to sort it out.

Pete

The wave player supports 44.100, 22050 and 11025 Hz only
(See bool AudioPlaySdWav::parse_format(void) in play_sd_wav.cpp)
 
I just want to say that I'm hugely disappointed when I look at the pinout/form-factor of the T4. My apps need the processing power of the T4, but also need lots of digital pins for front panel communication etc.
Paul mentioned a future version with more pins - not sure if (and when) it comes.
 
I realize this is premature until the T4 is actually announced, but does anybody have plans to make a carrier to access the bottom pins? Something like this board from FrankB?
Maybe I'll make something like this. But I'm not sure how to handle the SD slot.
I thought about a board to "convert" the T4 to the T3.6 form factor (with SD on the same position), but that would require at least a 4-layer board which would be too expensive. The pins between 12 and 13 do not allow to route that many signal between them on 2 layers. And the parts under the MCU take some space, too and limit the remaining space.. I think, a 2-layer board which allows SD and the other pads needs to be wider.
 
Last edited:
Tried GNU Arm Embedded Toolchain, Version 8-2019-q3-update, Released: July 10, 2019***
I get some errors - maybe somebody wants to take care of them:

Code:
In file included from C:\Arduino\hardware\teensy\avr\cores\teensy4/core_pins.h:32,
                 from C:\Arduino\hardware\teensy\avr\cores\teensy4/wiring.h:38,
                 from C:\Arduino\hardware\teensy\avr\cores\teensy4/WProgram.h:45,
                 from c:\temp\arduino_build_474724\pch\Arduino.h:6:
C:\Arduino\hardware\teensy\avr\libraries[COLOR=#ff0000][B]\SPI/SPI.h[/B][/COLOR]: In member function 'void SPIClass::usingInterrupt(uint8_t)':
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:33: [COLOR=#ff0000]error[/COLOR]: expression '((IMXRT_REGISTER32_t*)1075544064)->IMXRT_REGISTER32_t::offset000' has side-effects
 #define GPIO1_DR   (IMXRT_GPIO1.offset000)
                    ~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\[COLOR=#ff0000][B]SPI/SPI.h[/B][/COLOR]:1148:20: note: in expansion of macro 'GPIO1_DR'
    case (uint32_t)&GPIO1_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4966:24: [COLOR=#ff0000]error[/COLOR]: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075544064)' is not a constant expression
 #define IMXRT_GPIO1  (*(IMXRT_REGISTER32_t *)0x401B8000)
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:21: note: in expansion of macro 'IMXRT_GPIO1'
 #define GPIO1_DR   (IMXRT_GPIO1.offset000)
                     ^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1148:20: note: in expansion of macro 'GPIO1_DR'
    case (uint32_t)&GPIO1_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4967:42: [COLOR=#ff0000]error[/COLOR]: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
 #define GPIO1_DR   (IMXRT_GPIO1.offset000)
                                          ^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1148:20: note: in expansion of macro 'GPIO1_DR'
    case (uint32_t)&GPIO1_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:33: [COLOR=#ff0000]error[/COLOR]: expression '((IMXRT_REGISTER32_t*)1075560448)->IMXRT_REGISTER32_t::offset000' has side-effects
 #define GPIO2_DR   (IMXRT_GPIO2.offset000)
                    ~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
    case (uint32_t)&GPIO2_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4978:24: [COLOR=#ff0000]error[/COLOR]: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075560448)' is not a constant expression
 #define IMXRT_GPIO2  (*(IMXRT_REGISTER32_t *)0x401BC000)
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:21: note: in expansion of macro 'IMXRT_GPIO2'
 #define GPIO2_DR   (IMXRT_GPIO2.offset000)
                     ^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
    case (uint32_t)&GPIO2_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4979:42: [COLOR=#ff0000]error[/COLOR]: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
 #define GPIO2_DR   (IMXRT_GPIO2.offset000)
                                          ^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1152:20: note: in expansion of macro 'GPIO2_DR'
    case (uint32_t)&GPIO2_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:33: error: expression '((IMXRT_REGISTER32_t*)1075576832)->IMXRT_REGISTER32_t::offset000' has side-effects
 #define GPIO3_DR   (IMXRT_GPIO3.offset000)
                    ~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
    case (uint32_t)&GPIO3_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4990:24: error: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075576832)' is not a constant expression
 #define IMXRT_GPIO3  (*(IMXRT_REGISTER32_t *)0x401C0000)
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:21: note: in expansion of macro 'IMXRT_GPIO3'
 #define GPIO3_DR   (IMXRT_GPIO3.offset000)
                     ^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
    case (uint32_t)&GPIO3_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:4991:42: error: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
 #define GPIO3_DR   (IMXRT_GPIO3.offset000)
                                          ^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1156:20: note: in expansion of macro 'GPIO3_DR'
    case (uint32_t)&GPIO3_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:33: error: expression '((IMXRT_REGISTER32_t*)1075593216)->IMXRT_REGISTER32_t::offset000' has side-effects
 #define GPIO4_DR   (IMXRT_GPIO4.offset000)
                    ~~~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
    case (uint32_t)&GPIO4_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5002:24: error: 'reinterpret_cast<IMXRT_REGISTER32_t*>(1075593216)' is not a constant expression
 #define IMXRT_GPIO4  (*(IMXRT_REGISTER32_t *)0x401C4000)
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:21: note: in expansion of macro 'IMXRT_GPIO4'
 #define GPIO4_DR   (IMXRT_GPIO4.offset000)
                     ^~~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
    case (uint32_t)&GPIO4_DR:
                    ^~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:5003:42: error: conversion from pointer type 'volatile uint32_t*' {aka 'volatile long unsigned int*'} to arithmetic type 'uint32_t' {aka 'long unsigned int'} in a constant expression
 #define GPIO4_DR   (IMXRT_GPIO4.offset000)
                                          ^
C:\Arduino\hardware\teensy\avr\libraries\SPI/SPI.h:1160:20: note: in expansion of macro 'GPIO4_DR'
    case (uint32_t)&GPIO4_DR:
                    ^~~~~~~~

*** Unfortunatley, coremark is *still* slower than with "our" gcc version
 
Last edited:
I'm not sure if you are on the beta list...
No I'm not, although I sure wish I was :( I'll be placing an order as soon as pre-orders are announced!

While I'm waiting, has anybody looked at the T4 to see if the T3.6 "bug" - where the I2S stream from the Audio board after a program reload (or less frequently on power-up) is out of sync by one sample between the left and right channels - is still present? This creates havoc when processing quadrature (complex) data streams. The bug was first reported here, and I elevated it to a formal bug report here. The problem has never been solved despite building audio board clones with different codec chips, and spending many, many hours looking at the I2S/DMA/STL5000 code, all without luck. I have reverted to using FFT based automatic bug detection, and invoking a delay register to bring the channels back in sync after reload or power-up.

It would be wonderful if the problem went away with the T4 :cool:
If anybody wants to take a look at it, I will be happy to provide sketches that demonstrate the problem.
 
@Frank B:
I tricked play_sd_wav.cpp into playing 8kHz and 12kHz. However, on closer listening to the audio, the 12kHz signal is noisy on playback. I'm still trying to figure out what's going on.

Pete
 
Red alert !!

I have suspicions tonight that my experiments with turning on 150 MHz for GPT timers may have damaged the chip internally. Until I can clarify this further, please will all beta users refrain from trying this for themselves.

The evidence that something ODD has happened is the behaviour of the GPT timers - things that used to work fine, now do not seem to be so fine. It may take me some while to pin the situation down.

The posts relevant here are #3554, #3557, #3578, #3579, #3582, #3583, #3586, #3591, #3611, #3638, #3642, #3644.

Specifically do not try the code in #3611 !!

Thanks for your patience. I shall report again in due course.
 
I have suspicions tonight that my experiments with turning on 150 MHz for GPT timers may have damaged the chip internally. Until I can clarify this further, please will all beta users refrain from trying this for themselves.

The evidence that something ODD has happened is the behaviour of the GPT timers - things that used to work fine, now do not seem to be so fine. It may take me some while to pin the situation down.

The posts relevant here are #3554, #3557, #3578, #3579, #3582, #3583, #3586, #3591, #3611, #3638, #3642, #3644.

Specifically do not try the code in #3611 !!

Thanks for your patience. I shall report again in due course.
maybe T4 is locked up with run away interrupts, try holding program button for 15 s to erase flash
 
Thanks for the tip. I will try that.

The reason I'm suspicious that something has changed is that I have - so far - been unable to "go backwards" and undo the mux that switched on the 150 MHz. Something else that is bizarre - if I put the line GPT1_CR=0; early in setup then that's OK, but if I put the line GPT2_CR=0; then it locks up. Couple this with the odd behaviour of the Compare interrupts (I reported) then until I can clarify exactly what has/has not changed, its not safe.

Your tip for erasing flash will be useful. I'll try that - amongst other ideas. I'll work on this tomorrow and see if I can get something definitive.
 
Good added info - still need to decipher and decode/read SRC_SRSR for debug_tt.

If it does trigger one of those _isr()'s that would be the way to get a _callback. If it were set to a _weak default the user could include custom code for resolution.

Thanks for typo false alarm check - I was willing to ignore it until seeing there were three _0, _1, and _2 variations in the header.

@defragster - went back into my original standalone sketch: https://github.com/mjs513/WIP/tree/master/TempMonitorStuff/T4-TEMPMON. You can see how I did the Callbacks if the ISR is tripped for HIGH and panic temps. Also the panic temp is set that high that the chip would go into meltdown - you can always test I presume if you run the chip at "Ludicrous Speed"
 
I am playing around with simple breakout board, to play with doing Robotics. With this I don't need complex sounds or the like, usually just some form of multiple beeps or the like. Things like, you pressed a button to control it and maybe signal with mode you are in. Or battery is getting low...

I am wondering if with T4, probably best off going back to what I was doing before, which is to connect up speaker/buzzer sometimes directly to IO pin, but usually when putting on a board, I would use a transistor, diode, ...

Later I started using a small amplifier chip off of the DAC pin(s). Or wonder if it makes sense to use some other I2S device and some form of AMP?

Just wondering which way I want to go.
 
I am playing around with simple breakout board, to play with doing Robotics. With this I don't need complex sounds or the like, usually just some form of multiple beeps or the like. Things like, you pressed a button to control it and maybe signal with mode you are in. Or battery is getting low...

I am wondering if with T4, probably best off going back to what I was doing before, which is to connect up speaker/buzzer sometimes directly to IO pin, but usually when putting on a board, I would use a transistor, diode, ...

Later I started using a small amplifier chip off of the DAC pin(s). Or wonder if it makes sense to use some other I2S device and some form of AMP?

Just wondering which way I want to go.

maybe use T4's MQS pin(s) with capacitor and speaker https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=197727&viewfull=1#post197727

AudioOutputMQS audioOutput;
https://github.com/manitou48/teensy4/blob/master/wav2mqs.ino

https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=198364&viewfull=1#post198364
 
@defragster - went back into my original standalone sketch: https://github.com/mjs513/WIP/tree/master/TempMonitorStuff/T4-TEMPMON. You can see how I did the Callbacks if the ISR is tripped for HIGH and panic temps. Also the panic temp is set that high that the chip would go into meltdown - you can always test I presume if you run the chip at "Ludicrous Speed"

I have pulled that original sample and thought about changing the PANIC temp to something near normal temp to see it work, was going to ask how and how much you tested. Played some before moving on - I was dong it in conjunction with the STARTUP_HOOKS and stopped to do the Pull request because that part was working right and seemed useful to be able to get in early and use time that would be wasted in those while(waits).

Wanted to be sure I understood enough to catch interrupt and such without having to actually make time to read the manual. I suppose I could edit the Startup.c code to pull the included TempMon_Init() and call out to a LIB test version where I saw you passed in the TEMP values.
 
I have pulled that original sample and thought about changing the PANIC temp to something near normal temp to see it work, was going to ask how and how much you tested. Played some before moving on - I was dong it in conjunction with the STARTUP_HOOKS and stopped to do the Pull request because that part was working right and seemed useful to be able to get in early and use time that would be wasted in those while(waits).

Wanted to be sure I understood enough to catch interrupt and such without having to actually make time to read the manual. I suppose I could edit the Startup.c code to pull the included TempMon_Init() and call out to a LIB test version where I saw you passed in the TEMP values.

Well tested it pretty good to make sure things tripped when they were suppose to in that test sketch. Just for the fun of it I also lowered the panic temp and tested to see if it really reset using a panic temp near normal run time temps. And before you ask yes it did keep resetting until I put the temps back to way I had it. Never got around to try looking at the SRC bits - punted on that one.
 
I am playing around with simple breakout board, to play with doing Robotics. With this I don't need complex sounds or the like, usually just some form of multiple beeps or the like. Things like, you pressed a button to control it and maybe signal with mode you are in. Or battery is getting low...

I am wondering if with T4, probably best off going back to what I was doing before, which is to connect up speaker/buzzer sometimes directly to IO pin, but usually when putting on a board, I would use a transistor, diode, ...

Later I started using a small amplifier chip off of the DAC pin(s). Or wonder if it makes sense to use some other I2S device and some form of AMP?

Just wondering which way I want to go.

@KurtE

I did add the capability to the Talkie library to use a PWM pin on the T4 with @defragster's comments. Volume was just low. However I just found this regarding using PWM that might be of interest that uses a transistor and PWM: https://os.mbed.com/users/4180_1/notebook/using-a-speaker-for-audio-output/ . Guess I have something else to think about adding :)
 
Well tested it pretty good to make sure things tripped when they were suppose to in that test sketch. Just for the fun of it I also lowered the panic temp and tested to see if it really reset using a panic temp near normal run time temps. And before you ask yes it did keep resetting until I put the temps back to way I had it. Never got around to try looking at the SRC bits - punted on that one.

Cool, - no PANIC :) - I wasn't clear on when the _isr()'s triggered? Maybe now - LOW or HIGH come in on High_Low_Temp_isr() and that is why it is testing which it is.
And on PANIC the CPU just RESETS without warning or calling the Panic_Temp_isr() that is commented out? Does the 'keep resetting' happen after the call to tempmon_init() with "//Start temp monitoring"?
 
@defragster - Essenstially that's it - the system automatic triggers reset when panic temp is exceeded - it will keep resetting unless you do something to lower the temp. Believe so on the init and tempmon start.
 
@manitou and @mjs513, I may have to play around with both techniques. Actually @mjs513, the link you gave circuit is pretty close to what I mentioned I was using on older boards.

Actually from the earlier breakout board I mentioned earlier (email) from it's schematic:
PWM-sound-out.jpg
 
@defragster - Essenstially that's it - the system automatic triggers reset when panic temp is exceeded - it will keep resetting unless you do something to lower the temp. Believe so on the init and tempmon start.

Thx, that gives me a starting point for expectations without redoing what you already discovered. I'll work with a void startup_reset_hook(void) before the clock speed is bumped to 600M (after the debug Serial4 printf_debug_init()) and see what I find from there.
 
@Paul: Is the T4 MSU by any chance always restarted with a reset from the bootloader MCU? Perhaps that is just how it comes online as configured?

Either that or I am reading the wrong value, or reading it the wrong way as this is always == 1 == #define SRC_SRSR_IPP_RESET_B ((uint32_t)(1 << 0)):
Code:
	uint32_t WIPstartup_reset_SRSR = SRC_SRSR; // WIP

from:
Code:
…\hardware\teensy\avr\cores\teensy4\imxrt.h about line 7650:
// 52.7: page 2969
#define IMXRT_SRC		(*(IMXRT_REGISTER32_t *)0x400F8000)
// ...
#define SRC_SRSR			(IMXRT_SRC.offset008)

Where I understood the value of SRC_SRSR would be one of those shown after that like : SRC_SRSR_TEMPSENSE_RST_B

… @mjs513 -
I've set the PANIC temps to 50C and it is working up to that and shutting down but on repowering - or any other start I've seen it always reports the code 1 above. I capture the value as first line of ResetHandler() which seems to be the first code executed?

Funny I can read the tempmonGetTemp() at 50 for some time then it just goes away. Running on 2 T4B2's - ribbon one restarted once, but has been sitting at 49-50C for some time while the other pre-ribbon Mod goes to 49-50C and then has tripped over 6 times.

The breakout POWER LED stays on - it does NOT shut off the MCU Power - and it responds to POWER button to turn OFF - then back ON … where it powers up with :: MY_startup_reset_SRSR == 1
> Same #1 as with : Upload, USB power cycle …

… on to the _isr()'s ...
 
Status
Not open for further replies.
Back
Top