Teensy 4.0 First Beta Test

Status
Not open for further replies.
@MichaelMeissner @PaulStoffregen @mjs513 @defragster ... - Wondering how much to do with this library (teensy_ssd1351) which installs with Teensyduino as just ssd1351?

That is it was originally done by the member @kirberich - Last change was back in 2016 and it looks like he has not been up on forum since April 2017.

I have it running now on T4... I am playing with the UnCannyEyes to see how fast this library would make it versus the Adafruit library...
I agree with Michael, that the library names confusion would be nice to avoid...

Also this library is not overly compatible with the Adafruit_ssd1351 library. That is unlike some of the others where we can get away with maybe only changing which object we are using and maybe changes on constructor and/or init member... There are lots of differences. Things like:

Object definitions: Instead of something like:
Code:
Adafruit_SSD1351 tft = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, CS_PIN, DC_PIN, MOSI_PIN, SCLK_PIN, RST_PIN);

you have something like:
Code:
auto display = ssd1351::SSD1351<ssd1351::HighColor, ssd1351::SingleBuffer, 128, 128>(CS_PIN, DC_PIN, RST_PIN);

Which is easy enough to deal with... They both have the same begin()... So again not an issue.

This library does not support: setRotation()

In UnCannyEyes - there is the issue that most of the primitives take a specific object type for color, instead of an something like uint16_t.
So for example: fillScreen(0);
Needs to be changed to something like: fillScreen(ssd1351::RGB(0, 0,0));


So question would be: how much to play here? I may do a little more hacking here to see how bad the changes to uncanny would be...

Again wondering with libraries like this to support displays where the originators are no longer active what to do?
Hopefully when I issue a PR, he might accept it. Looks like his github account is still active.
 
@mjs513 and whoever might have an Adafruit OLED ssd1351...

I made a first pass through the SSD1351 library (shows up as teensy_ssd1351). I hope I have most of the pieces in place. Their simple program compiles. I don't have the display yet (should be here later today)...

Put WIP branch up at: https://github.com/KurtE/teensy_ssd1351/tree/t4_beta

Ok, I was able to try this out. Using both a New Haven 128x128 OLED display (NHD-1.5-128128ASC3) and the Adafruit 128x128 OLED display, I was not able to get anything displayed using the Teensy 4.0 beta 2 board. I am using my normal uncanny eyes defaults:
  • CS: A8 (A9 is the other display in uncanny eyes);
  • DC: A1
  • Reset: A0
  • SCLK: 13
  • MOSI: 11
  • VDD: 3.3v

I tried at various SPI bus speeds (11Mhz .. 15Mhz, 18Mhz).

I checkout the branch via svn and used the branches/t4_beta directory in my ~/Arduino/libraries directory. If I used the trunk, it got all of the PUSHR errors mentioned before.

I switched to my Teensy 3.2, and I was not able to run either display without setting SLOW_SPI. When i set SLOW_SPI, I was able to run both displays. Ditto for the Teensy 3.5, which I tried at the normal 120Mhz, and over-clocked to 168Mhz. Note, when running the uncanny eyes program, I have to reduce the SPI bus speed down to 11Mhz for the Adafruit display (I haven't re-measured what the max New Haven speed is, but in the past, it was faster than the Adafruit display).

I would suggest in the future, adding an #ifdef around setting SPICLOCK to allow the user to reset this to specific speeds:

Code:
#ifndef SPICLOCK
#ifdef SLOW_SPI
#define SPICLOCK 15000000
#else
#define SPICLOCK 18000000
#endif
#endif
 
Last edited:
@MichaelMeissner @PaulStoffregen @mjs513 @defragster ... - "Wondering how much to do with this library (teensy_ssd1351) which installs with Teensyduino as just ssd1351? "

Know I am late here but would it make more sense to switch to the Adafruit SSD1351 library in teensyduino rather the current version. Otherwise we might be creating more work. Previous lib may have been done prior to Adafruits version?
 
Hi @MichaelMeissner - Are you trying T4 using something like breadboard or using Paul's breakout? With Paul's breakout getting some of those specific pins as many of the signals are not routed to the socket you plug the Audio board into... But I think all of those are brought out...
CS - A8 - ??? Not sure?
DC - A1 - You can use the RX pin on the Serial3 connection
Reset A0 - You can use the TX pin on Serial 3 connection
SCLK does route to pin marked SCK on Audio connection
MOSI 11 routes to MOSI (different location but labeled)

Since I have not yet done the PR: I added your suggestion for #ifndef SPICLOCK

Pushed it up...

Note: I hacked my copy yesterday and the display appeared to work at 25mhz SPI speed. Although Spec almost looks like it should work at 4mhz?
 
Hi @MichaelMeissner - Are you trying T4 using something like breadboard or using Paul's breakout? With Paul's breakout getting some of those specific pins as many of the signals are not routed to the socket you plug the Audio board into... But I think all of those are brought out...
CS - A8 - ??? Not sure?
DC - A1 - You can use the RX pin on the Serial3 connection
Reset A0 - You can use the TX pin on Serial 3 connection
SCLK does route to pin marked SCK on Audio connection
MOSI 11 routes to MOSI (different location but labeled)

Since I have not yet done the PR: I added your suggestion for #ifndef SPICLOCK

Pushed it up...

Note: I hacked my copy yesterday and the display appeared to work at 25mhz SPI speed. Although Spec almost looks like it should work at 4mhz?

Basically I removed the audio card, and use those 2x14 set of pins to plug it in. Yes, the silk screen says different pins for SCLK, MOSI, etc (since the audio board uses the alternative pins in those cases), but I assumed the basic 28 pins were routed straight to the equivalent pins on the outside of the Teensy.
 
@MichaelMeissner - Nope only the IO pins Paul needed for Audio work was actually routed to that socket. Some are in strange locations. Like where 20, 21, 23 I think are routed to those pins marked like(LRCLK, BCLK, MCLK) I end up using my program blink any pin: Which I modified slightly from the last time I posted it...

Code:
int current_pin = 13;
int next_pin_number = 0;
#define DBGSerial Serial
void setup() {
  // Blink any pin.  Note: I put pin 13 as input to see if we can
  // jumper to it to see if we can find the pin...
  while (!Serial && millis() < 5000);
  DBGSerial.begin(115200);
  delay (250);
  DBGSerial.println("Find Pin by blinking");
  DBGSerial.println("Enter pin number to blink");
  pinMode(13, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  if (DBGSerial.available()) {
    int ch;
    while (DBGSerial.available()) {
      ch = DBGSerial.read();
      if ((ch >= '0') && (ch <= '9')) {
        next_pin_number = next_pin_number * 10 + (ch - '0');
      } else {
        if (next_pin_number == 0) next_pin_number = current_pin + 1;
        digitalWrite(current_pin, LOW); // turn the previous pin to low...
        current_pin = next_pin_number;
        pinMode(current_pin, OUTPUT);
        if (current_pin != 13)
          pinMode(13, INPUT);
        digitalWrite(current_pin, HIGH);
        next_pin_number = 0;  // setup to enter next pin
        DBGSerial.printf("Now Blinking pin %d\n\r", current_pin);
        while (DBGSerial.read() != -1) ; // get rid of the rest of input
      }
    }
  } else {
    digitalWrite(current_pin, !digitalRead(current_pin));
    delay(250);
  }
}
Which starts blinking pin 13 (LED) and it allows you to type in number for which pin to blink... If not 13 it sets pin 13 to input...
So if you type 20 and connect up a wire to pin 13, and touch it to what you think pin 20 is, the LED should start blinking.

The simple difference I made was: If you then simply type CR it will increment to next pin number, so in this case 21...
 
Basically I removed the audio card, and use those 2x14 set of pins to plug it in. Yes, the silk screen says different pins for SCLK, MOSI, etc (since the audio board uses the alternative pins in those cases), but I assumed the basic 28 pins were routed straight to the equivalent pins on the outside of the Teensy.

Not. for T4B2 breakout i have
Code:
               T4    audio header  silk screen 
               13 to SCK  (14)
               12    MISO (12)
               10    CS   (10)
               11    MOSI (7)
               23    MCLK    (was 5?)
               21    BCLK    (was 4)
                9    MEMCS
               19    SCL
               18    SDA
               20    LRCLK
                7    Tx      (was 6)
                8    Rx      (was 7)
               15    Vol   A1
 
@PaulStoffregen - New T4 cards - :D :D :D hard copy one arrived in mail yesterday!

If/When you update the card, would probably suggest changes for Pin 0 and Pin 1
That is these pins are used for SPI1
Pin 0 is CS
Pin 1 is MISO

You do show the other SPI1 pins on the back of the card:
26 MOSI1
27 SCK1
 
@Jean-Marc

I have been looking at different ways to cache reads and writes from USB Mass Storage drives. This is something that I have no experience with. With the T4 there is lots of memory options to use.
On one of my T3.6 boards I have a simple file manager that is a two pane display of files. Kinda like MC in Linux. The main problem I have is running out of memory caching large numbers of files in directories.

I have tried USDFS with USB MSC library, it goes very well. I created a small app on the ILi9341 to browse files from USB and SD card (using Sdio connected of the break out board). For the SD file browsing I had to use the SD library with build-in option but I cannot create files. Is there a way to use usdfs with build-in sd interface? The project is on my git, teensync part of the teensyMCUME archive.
 
@MichaelMeissner - Nope only the IO pins Paul needed for Audio work was actually routed to that socket. Some are in strange locations. Like where 20, 21, 23 I think are routed to those pins marked like(LRCLK, BCLK, MCLK) I end up using my program blink any pin: Which I modified slightly from the last time I posted it...
Learn something new each day. I assumed all of the pins were routed straight through. I have a similar program, and I will use it tonight to find the usable pins. Thanks.

Which starts blinking pin 13 (LED) and it allows you to type in number for which pin to blink... If not 13 it sets pin 13 to input...
So if you type 20 and connect up a wire to pin 13, and touch it to what you think pin 20 is, the LED should start blinking.

The simple difference I made was: If you then simply type CR it will increment to next pin number, so in this case 21...
 
GPT timer clock selections

@manitou - Yup, the RTC looks to be that little tin at the side of the reset button. Cute. I was mentally expecting a round long tin for RTC. Habits...

The reason for lack of option 5 on GPT_CR clock selection is simple... there's another gate in the same GPT_CR register on bit 10 which enables 24M directly from the crystal. Once that is enabled, then both 150 and 24 MHz are available together for selection. I presume all this clock gating is to minimise the power consumption and lower the core temperature when stuff not needed.

So my simple code to enable 150 MHz ended up gating clocks on GPTs and PITs only, during the switch over of the mux. Attached for what its worth. GPT1_CNT and GPT2_CNT can then be read at leisure.

Code:
  //set clock gating registers to inhibit GPT and PIT clocks
  Save1 = CCM_CCGR0;                          //save current state 0
  Save2 = CCM_CCGR1;                          //save current state 1
  CCM_CCGR0 &= 0xF0FFFFFF;                    //inhibit GPT2 (CG12,CG13)
  CCM_CCGR1 &= 0xFF0FCFFF;                    //inhibit GPT1 and PIT (CG6,CG10,CG11)
  
  //change the mux setting for IPG_CLK_ROOT (set bit6 = 0)
  CCM_CSCMR1 &= 0xFFFFFFBF;

  //restore GPT and PIT gated clocks
  CCM_CCGR0 = Save1;
  CCM_CCGR1 = Save2;
  
  //configure clocks for GPT modules
  CCM_CCGR0 |= 0x0F000000;                    //enable clocks to GPT2 (CG12,CG13)
  CCM_CCGR1 |= 0x00F00000;                    //enable clocks to GPT1 (CG10,CG11)
  
  //configure GPT1 for test
  GPT1_CR = 0;                                //clear the control register
  GPT1_IR = 0;                                //disable all interrupts
  GPT1_SR = 0x3F;                             //clear all prior status
  GPT1_PR = 0;                                //prescale register set divide by 1
  GPT1_CR |= GPT_CR_CLKSRC(2);                //clock selection (150 MHz)
  GPT1_CR |= GPT_CR_ENMOD;                    //reset count to zero before enabling
  GPT1_CR |= GPT_CR_EN_24M;                   //enable the 24 MHz clock option
  GPT1_CR |= GPT_CR_EN;                       //enable GPT1 counting at 150 MHz

  //configure GPT2 for test
  GPT2_CR = 0;                                //clear the control register
  GPT2_IR = 0;                                //disable all interrupts
  GPT2_SR = 0x3F;                             //clear all prior status
  GPT2_PR = 0;                                //prescale register set divide by 1
  GPT2_CR |= GPT_CR_CLKSRC(5);                //clock selection (24 MHz)
  GPT2_CR |= GPT_CR_ENMOD;                    //reset count to zero before enabling
  GPT2_CR |= GPT_CR_EN_24M;                   //enable the 24 MHz clock option
  GPT2_CR |= GPT_CR_EN;                       //enable GPT2 counting at 24 MHz
 
@mjs513 - @Paul - As mentioned in other thread.
I was playing with the uncanny eyes as modified by @mjs513 to work with our ST7735_t3 library, the program is up at: https://forum.pjrc.com/threads/5573...3-x-and-beyond?p=209650&viewfull=1#post209650

BTW, I was looking at some of my saved stuff on ebay, and I recall seeing this display meant for the PI. It is a 128x128 TFT display (ST7735), but it has several buttons and a joystick if people wanted to incorporate the display into some other work:
 
@MichaelMeissner - Thanks


For now I think I have enough of these small displays to collect to go into my displays and sensors box as I am a hoarder :D

ST7735:
128x128 - I have 2 with different memory layout than Adafruit I think (https://smile.amazon.com/gp/product/B00V5846YC)
plus one matching Adafruit (https://smile.amazon.com/gp/product/B073R6SQRY)
and soon when package from Mouser will have an Adafruit:

128x160: https://smile.amazon.com/gp/product/B00LSG51MM

I don't have any of their small ones yet

ST7789:
One that works (has CS Pin): https://smile.amazon.com/gp/product/B07MH93747
On that I have not gotten to work (no CS Pin): https://smile.amazon.com/gp/product/B07P9X3L7M
Another on order without CS pin (should be here in about a week): https://www.ebay.com/itm/153515689082

SSD1351: So far just one:https://smile.amazon.com/gp/product/B01HHPOD44/


And @mjs513 ...
Talking about the OLED. I hacked up the uncannyEyes and have it working with the st7735 library in 16 bit color mode...
And have it sort of working for just one eye. Don't see any way without mods to do some of the sendCommands... Could maybe add to his library...

But With this hacked up version, it is now updating the eye at about 55 frames per second
 

Attachments

  • uncannyEyes-190710a.zip
    944.1 KB · Views: 85
@Frank B
I just received the T4 beta today so I'm playing catch up.
Is there a new version of your setI2SFreq function - I can't find any mention of it in this thread? I need to set the audio frequency to 12kHz to get my FT4 encoder working with the audio board on the T4. I've added 12kHz to it for PLL frequencies up to 240MHz but don't know how to handle it with T4.

Pete
Hi Pete,

probably something like this:
Code:
#include <Audio.h>
[COLOR=#ff0000][B]#include <utility/imxrt_hw.h>[/B][/COLOR]
  
void setI2SFreq(int freq) {
  // PLL between 27*24 = 648MHz und 54*24=1296MHz
  int n1 = 4; //SAI prescaler 4 => (n1*n2) = multiple of 4
  int n2 = 1 + (24000000 * 27) / (freq * 256 * n1);
  double C = ((double)freq * 256 * n1 * n2) / 24000000;
  int c0 = C;
  int c2 = 10000;
  int c1 = C * c2 - (c0 * c2);
  set_audioClock(c0, c1, c2, true);
  CCM_CS1CDR = (CCM_CS1CDR & ~(CCM_CS1CDR_SAI1_CLK_PRED_MASK | CCM_CS1CDR_SAI1_CLK_PODF_MASK))
       | CCM_CS1CDR_SAI1_CLK_PRED(n1-1) // &0x07
       | CCM_CS1CDR_SAI1_CLK_PODF(n2-1); // &0x3f 
}
 
Frank B posted this on PT8211 - I tested it to work as noted on T4B2:


Made that edit and this works on T4B2:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine sine1; //xy=329,317
AudioOutputPT8211 out1; //xy=523,317
AudioConnection patchCord1(sine1, 0, out1, 0);
AudioConnection patchCord2(sine1, 0, out1, 1);
// GUItool: end automatically generated code

uint32_t ffreq = 440;
void setup() {
	AudioMemory(20);
	sine1.amplitude(0.80);
	sine1.frequency(ffreq);
}

void loop() {
	if ( !(millis() % 600) ) {
		ffreq += 220;
		if ( ffreq > 2200 ) ffreq = 440;
		sine1.frequency(ffreq);
	}
}
 
@Frank B - what do you think of post #3576 :: Teensy-4-0-First-Beta-Test?p=209759&viewfull=1#post209759

Seems you were on the early post about startup_???_hooks()? Do those look like good places to allow sketch to do some pre-setup() work when needed? They offer the sketch time that would otherwise be spent spinning in a while()

Does it need one any earlier where the printf_debug_init() is currently initialized? Perhaps : void startup_reset_hook(void) // Very early after reset before clocks or anything else are started

Not sure how that compares to the _hook()'s presented on T_3.x's as far as how they are used - and if they would ever directly relate given the new MCU startup.
 
@Frank B - what do you think of post #3576 :: Teensy-4-0-First-Beta-Test?p=209759&viewfull=1#post209759

Seems you were on the early post about startup_???_hooks()? Do those look like good places to allow sketch to do some pre-setup() work when needed? They offer the sketch time that would otherwise be spent spinning in a while()

Does it need one any earlier where the printf_debug_init() is currently initialized? Perhaps : void startup_reset_hook(void) // Very early after reset before clocks or anything else are started

Not sure how that compares to the _hook()'s presented on T_3.x's as far as how they are used - and if they would ever directly relate given the new MCU startup.

My intention was to provide a way to shutdown the T4 if it was reset due to too high temperature. Any hook would work :) But I'd pefer a special hook for that (right before your "late" hook, maybe) - using the "early" or "late" hook prevents use for other cases.
 
My intention was to provide a way to shutdown the T4 if it was reset due to too high temperature. Any hook would work :) But I'd pefer a special hook for that (right before your "late" hook, maybe) - using the "early" or "late" hook prevents use for other cases.

Okay - code shows this:
Code:
	tempmon_init();

	startup_late_hook();
	while (millis() < 300) ; // wait at least 300ms before calling user code

So that could be added to the " tempmon_init(); " call where it has a _hook() in the case hi temp is seen on startup?

If T4 is still Hot - maybe that would be that place to do it before it does this that may just restart again there?
Code:
  //Start temp monitoring
  TEMPMON_TEMPSENSE0 |= 0x2U;   //starts temp monitoring

If nothing else that code might TEST current temp before that 'Start' and drop FCPU_ACTUAL immediately then call out?
 
@mjs513 - you did this right ? - does post #3618 on tempmon_init(); look like the place to do the High or Panic _CallBack to use code to deal with this during startup? If this can cause MCU Reset it will repeat while temp is over threshold once the monitoring is enabled?
 
The TimeAlarm library appears to work. I ran the TimeAlarmExample.pde from Paul's github repo. Here's the output:
Code:
14:23:02.018 -> 8:29:0014:23:02.952 -> 8:29:01
14:23:03.944 -> 2 second timer
14:23:03.944 -> 8:29:02
14:23:04.970 -> 8:29:03
14:23:05.962 -> 2 second timer
14:23:05.962 -> 8:29:04
14:23:06.954 -> 8:29:05
14:23:07.947 -> 2 second timer
14:23:07.947 -> 8:29:06
14:23:08.972 -> 8:29:07
14:23:09.964 -> 2 second timer
14:23:09.964 -> 8:29:08
14:23:10.957 -> 8:29:09
14:23:11.949 -> 2 second timer
14:23:11.949 -> This timer only triggers once, stop the 2 second timer
14:23:11.949 -> 8:29:10
14:23:12.975 -> 8:29:11
14:23:13.967 -> 8:29:12
14:23:14.959 -> 8:29:13
14:23:15.952 -> 8:29:14
14:23:16.944 -> 15 second timer
14:23:16.977 -> 8:29:15
14:23:17.969 -> 8:29:16
14:23:18.962 -> 8:29:17
14:23:19.987 -> 8:29:18
14:23:20.979 -> 8:29:19
14:23:21.971 -> 8:29:20
14:23:22.964 -> 8:29:21
14:23:23.989 -> 8:29:22
14:23:24.982 -> 8:29:23
14:23:25.974 -> 8:29:24
14:23:26.966 -> 8:29:25
14:23:27.992 -> 8:29:26
14:23:28.984 -> 8:29:27
14:23:29.977 -> 8:29:28
14:23:30.969 -> 8:29:29
14:23:31.962 -> 15 second timer
14:23:31.995 -> 8:29:30
14:23:32.987 -> 8:29:31
14:23:33.980 -> 8:29:32
14:23:34.972 -> 8:29:33
14:23:35.998 -> 8:29:34
14:23:36.991 -> 8:29:35
14:23:37.983 -> 8:29:36
14:23:38.976 -> 8:29:37
14:23:40.001 -> 8:29:38
14:23:40.993 -> 8:29:39
14:23:41.986 -> 8:29:40
14:23:43.011 -> 8:29:41
14:23:44.004 -> 8:29:42
14:23:44.996 -> 8:29:43
14:23:45.989 -> 8:29:44
14:23:46.948 -> 15 second timer
14:23:47.014 -> 8:29:45
14:23:48.006 -> 8:29:46
14:23:48.999 -> 8:29:47
14:23:49.991 -> 8:29:48
14:23:51.017 -> 8:29:49
14:23:52.009 -> 8:29:50
14:23:53.001 -> 8:29:51
14:23:53.997 -> 8:29:52
14:23:55.019 -> 8:29:53
14:23:56.012 -> 8:29:54
14:23:57.004 -> 8:29:55
14:23:57.997 -> 8:29:56
14:23:59.022 -> 8:29:57
14:24:00.015 -> 8:29:58
14:24:01.007 -> 8:29:59
14:24:01.967 -> Alarm: - turn lights off
14:24:01.967 -> 15 second timer
14:24:02.000 -> 8:30:00
14:24:03.026 -> 8:30:01
14:24:04.019 -> 8:30:02
14:24:05.011 -> 8:30:03
14:24:06.004 -> 8:30:04
14:24:07.029 -> 8:30:05
14:24:08.022 -> 8:30:06
14:24:09.015 -> 8:30:07
14:24:10.007 -> 8:30:08
14:24:11.033 -> 8:30:09
14:24:12.025 -> 8:30:10
14:24:13.018 -> 8:30:11
14:24:14.010 -> 8:30:12
14:24:15.036 -> 8:30:13
14:24:16.028 -> 8:30:14
14:24:16.955 -> 15 second timer
14:24:17.021 -> 8:30:15
14:24:18.046 -> 8:30:16
14:24:19.039 -> 8:30:17
14:24:20.031 -> 8:30:18
14:24:21.024 -> 8:30:19
14:24:22.049 -> 8:30:20
14:24:23.042 -> 8:30:21
14:24:24.034 -> 8:30:22
14:24:25.027 -> 8:30:23
 
@mjs513 - you did this right ? - does post #3618 on tempmon_init(); look like the place to do the High or Panic _CallBack to use code to deal with this during startup? If this can cause MCU Reset it will repeat while temp is over threshold once the monitoring is enabled?

@defragster - been awhile - but from what I remember when temp goes over high threshold it will automatically trip one of the power registers - have to go back to the manual to very. Was waiting to go further until @Frank B came up with how we wanted to handle that - had a discussion early on about that in the thread - just to throttle back or disable the pins etcc.

EDIT: Check page 1341 of the manual:
SRC_SRSR:
bit 8 - tempsense_rst_b
Temper Sensor software reset. Indicates whether the reset was the result of software reset from on-chip Temperature Sensor.
0 Reset is not a result of software reset from Temperature Sensor.
1 Reset is a result of software reset from Temperature Sensor.

So if you test this bit on startup would be the best bet. Tempmon generates an automatic reset when the panic temp is exceeded.
 
Last edited:
@defragster - been awhile - but from what I remember when temp goes over high threshold it will automatically trip one of the power registers - have to go back to the manual to very. Was waiting to go further until @Frank B came up with how we wanted to handle that - had a discussion early on about that in the thread - just to throttle back or disable the pins etcc.

awhile indeed … I was lucky to remember who touched it :) - Looking only at the code is where I got my assumptions - that until this:
Code:
  //Start temp monitoring
  TEMPMON_TEMPSENSE0 |= 0x2U;   //starts temp monitoring

The MCU would happily melt without warning ( except maybe it has a factory high default IIRC )? So that would be the place in start up to check the reset reason or current temp and maybe pause startup to give a _user_callback_BadHeat() before enabling that and causing restart loop?

It seems there would be an _isr() triggered for HIGH and PANIC? - not just an MCU reset - for this and that is where the trap _callback() should be?
Code:
        IRQ_TEMPERATURE =       63,
        IRQ_TEMPERATURE_PANIC = 64,
// …
#define PMU_MISC1_IRQ_TEMPHIGH			((uint32_t)(1<<29))
#define PMU_MISC1_IRQ_TEMPLOW			((uint32_t)(1<<28))
#define PMU_MISC1_IRQ_TEMPPANIC			((uint32_t)(1<<27))

Possible TYPO here - using TEMPMON_TEMPSENSE2 twice? Perhaps one should be TEMPMON_TEMPSENSE1?
Code:
  //Set Panic Alarm Temp
  tempCodeVal = (uint32_t)(s_hotCount + (s_hotTemp - panicAlarmTemp) * s_roomC_hotC / s_hot_ROOM);
   [COLOR="#FF0000"] TEMPMON_TEMPSENSE2[/COLOR] |= (((uint32_t)(((uint32_t)(tempCodeVal)) << 16U)) & 0xFFF0000U);
  
  // Set Low Temp Alarm Temp
  tempCodeVal = (uint32_t)(s_hotCount + (s_hotTemp - lowAlarmTemp) * s_roomC_hotC / s_hot_ROOM);
    [COLOR="#FF0000"]TEMPMON_TEMPSENSE2[/COLOR] |= (((uint32_t)(((uint32_t)(tempCodeVal)) << 0U)) & 0xFFFU);
 
@defragster - just added some info in previous post. Not to worry - if it hits panic temp it resets automatically and keeps resetting until temp goes down :)

No typo - check the masking = different between the two
 
@defragster - just added some info in previous post. Not to worry - if it hits panic temp it resets automatically and keeps resetting until temp goes down :)

No typo - check the masking = different between the two

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.
 
I have tried USDFS with USB MSC library, it goes very well. I created a small app on the ILi9341 to browse files from USB and SD card (using Sdio connected of the break out board). For the SD file browsing I had to use the SD library with build-in option but I cannot create files. Is there a way to use usdfs with build-in sd interface? The project is on my git, teensync part of the teensyMCUME archive.

Yes there is a way to use the built in SDHC card slot with uSDFS. If you look in the examples directory of uSDFS you will find several examples that give you the option to mount SPI, SDHC, USB or all three. Check out lines 5-13 of 'uSDFS_test.ino' for example:
Code:
#define TEST_DRV 2
//
#if TEST_DRV == 0
  const char *Dev = "0:/";  // SPI
#elif TEST_DRV == 1
  const char *Dev = "1:/";  // SDHC
#elif TEST_DRV == 2
  const char *Dev = "2:/";  // USB
#endif

If you define 'TEST_DRV' as 1 uSDFS will mount and change to the built in SDHC card slot. If you check further down the example you will see where 'Dev' is used in those operations.
I have used all three at the same time successfully when copying files.

I hope I understood your question correctly.

Will checkout your Github site. Sounds real interesting.

EDIT:
I have been wanting to try out your emulators for a long time now. Just lost site of it:)

In 'teensysync.ino' I see you are using Sdfat and uSDFS together. You might try using uSDFS for both:
Code:
  if((rc = f_mount (&fatfs, SDpath, 1))) { 
    emu_printf("f_mount() for USB MSC  failed");
  }
Code:
  if((rc = f_mount (&fatfs1, USBpath, 1))) { 
    emu_printf("f_mount() for USB MSC  failed");
  }

USBpath = "2:/" and SDpath = "1:/".

Of course all I/O ref's to SDFat would have to change to FatFS I/O op's.
Not sure if SDFat and uSDFS play well together.
 
Last edited:
Status
Not open for further replies.
Back
Top