Teensy 4.0 First Beta Test

[defragster]

err...no... "hot" fires before critical. So, the user can react to "hot". critical is _really_ critical. And with a reset, all pins get disabled, so, in a sensitve application, the user can add pullups/pulldonws to ensure a secure shutdown-state. This is needed anyway, because during startup the pins are not enabled, too.

That looks Cool Frank … err … Hot … Warm … : too many words :: Okay - so Frank is seeing 'hot' what I called 'Warning' - then Critical == hot Shutdown temp.

 

[Frank B]

I use "cold" - > "hot" -> "critical"
Critical is too late to do anything.. and we don't want a crash, a stackoverflow or another bug here, or a delay(1000000) .. so please no usercode for "critical"!
On the other hand, "hot" can be free for anything ..

 

[tonton81]

Tim, just got mine an hour or so ago, gonna have to clean up the sphagetti wiring test stuff i did with the t3.x/lc units on my desk and figure out what i can help with hehe

 

[mjs513]

That looks Cool Frank … err … Hot … Warm … : too many words :: Okay - so Frank is seeing 'hot' what I called 'Warning' - then Critical == hot Shutdown temp.

Ok - just woke up from my nap "HOT-WARNING" is what I would be the "HIGH Temp" threshold where "CRITICAL - HOT SHUTDOWN TEMP" would be what the manual refers to as "PANIC" temp. We can set these thresholds appropriately - just have to decide.

As Tim said in his post, I want to the temperature monitor working first - "NO THROTTLING" - just the hooks for the interrupts that will let us decide what we what to do. Then we can put it into the startup code to have it run continuously.

Now with all that said - after doing a little more homework:

The panic threshold is a special programmable threshold in that if the temperature increases above this value and the temperature-panic-reset interrupt is enabled in the System Reset Controller, the hardware will assume that software no longer has control over the thermal situation and will initiate a reset of the chip.

see page 2983. Also, on reset:

The SRSR is a write to one clear register which records the source of the reset events for the chip. The SRC reset status register will capture all the reset sources that have occurred.

and it just so happens on temperature reset "tempsense_rst_b" bit is set in the SRC Reset Status Register (SRC_SRSR). So on startup the bit can be tested and then just HALT.

Now - see what happens when I get some sleep.

 

[PaulStoffregen]

I've put the first beta installer on msg #2.

Hopefully no big software surprises, though it does have the boards.txt which is missing from github, and a build of Teensy Loader that recognizes the new board. The actual protocol is pretty much identical to Teensy 3.6 - just using a new ID number in the HID report descriptor. One other minor change is the linker scripts now put an ID symbol into the .elf files and Teensy Loader now uses that to figure out which board was intended. If that new symbol is missing, it falls back to the same old guessing based on stack starting address (the reason we had to leave 8 bytes unused on Teensy 3.5), so it should still be fully compatible with all existing compiled .elf files.

I had hoped to do much more before posting this, and I will soon, but here's a very rough first version!

The core library is still filled with printf output. It's sent to Serial4, so if you have a USB-serial cable, or another Teensy running File > Examples > Teensy > USB_Serial > USBtoSerial, connect its receive pin to Teensy4's pin 17 output to see the many printf messages. Baud rate is 115200.

USB Serial is sadly still not very stable, and so far I've only tested with Linux - so it may not work at all on Windows & Mac. I also still have a small pile of unpublished I2C & SPI code sitting here. Will do more on this tonight and hopefully put up another beta installer before more beta boards arrive.

 

[mjs513]

Just installed a clean copy of Arduino 1.8.8 and installed the T4 Beta-1 of Teensyduino. No problems on the on installing Teensyduino and compiling the Blink sketch - no errors Running a windows 10(x64) home edition version 1809. The T4 is identified as Teensy 4 - Beta1. Let the games begin.

Thanks
Mike

 

[defragster]

TeensyDuino version 1.46 beta 1 installed on/over a copy of IDE 1.88, it worked.

Did BLINK as Third Sketch and it does Verify with No Warning or Error - Half RAM?:

Sketch uses 5648 bytes (0%) of program storage space. Maximum is 1572864 bytes.
Global variables use 10608 bytes (4%) of dynamic memory, leaving 251536 bytes for local variables. Maximum is 262144 bytes.

Cool - For T4 Debug Out - based on Post #3 Serial4 is :: PIN 17/A3 UART3_TX

Fun Indeed … with the first two open IDE sketches::
First sketch Verify is ugly as 'device specific' things don't exist as the Debug_t3 open looked for them: GPIOC_PTOR, UART2_C2, SIM_SCGC(???)
<edit> - T4 MCU's won't have bitbanding access like with :: GPIOC_PTOR
Second includes freemem() from forum : warning about 'usb_transmit', error "undefined reference to `_sbrk'"

 

[Frank B]

Oh... it'll be exciting. DHL has announced a new arrival time. Monday. That's exciting because Monday (dec, 31) is only half a working day here. Usually, only in the morning, before noon we work on this day.. not all, but most of us. Tuesday is a holiday and nobody works. Well, maybe I get the T4 Monday... (Which would be awesome, but I can't believe it...)

 

[manitou]

i compiled with new teensyduino on 1.8.8. I don't think fpu is correct in boards.txt. it reads -mfpu=fpv4-sp-d16 -fsingle-precision-constant
probably should be -mfpu=fpv5-d16
Not sure how to handle single-precision-constant, since T4 fpu does both double and single precision in hardware.

 

[tonton81]

void loop() {
  static uint32_t reflash = millis();
  (void)reflash;
}

it seems declaring static variables as opposed to local vars throws errors

C:\Users\Tony\Documents\Arduino\BETA-T4/BETA-T4.ino:7: undefined reference to `__cxa_guard_acquire'
C:\Users\Tony\Documents\Arduino\BETA-T4/BETA-T4.ino:7: undefined reference to `__cxa_guard_release'

 

[defragster]

Works like this - something more to do with the assignment of the millis() return?:

static uint32_t reflash = millis();
void loop() {
  uint32_t ii;
  static uint32_t jj;
  ii = reflash;
  ii++;
  jj = ii;
  jj++;
}

 

[tonton81]

This works:

void loop() {
  static uint32_t reflash = 20000UL;
  (void)reflash;

so it seems millis() is fine to set a scoped local but not a scoped static

EDIT:
micros() has same behaviour.

EDIT2: I can replicate this with a simple function return:

void loop() {
  static uint32_t reflash = test();
  (void)reflash;
}


uint32_t test() {
  return 1234UL;
}

C:\Users\Tony\AppData\Local\Temp\arduino_build_504252\sketch\BETA-T4.ino.cpp.o: In function `loop':

C:\Users\Tony\Documents\Arduino\BETA-T4/BETA-T4.ino:7: undefined reference to `__cxa_guard_acquire'

C:\Users\Tony\Documents\Arduino\BETA-T4/BETA-T4.ino:7: undefined reference to `__cxa_guard_release'

collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy 4-Beta1.

As simple as it is I don't think it's pointing to an issue of millis/micros, something else causing it

most google searches say add a library flag "-lstdc++" in the makefile to fix the issue

 

[manitou]

compiling coremark, i too get sbrk error

arduino-1.8.8/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'

 

[tonton81]

ok i added a compiler flag in boards.txt

teensy4b.build.flags.cpp=-fno-exceptions -felide-constructors -std=gnu++14 [COLOR="#FF0000"][B]-fno-threadsafe-statics[/B][/COLOR] -Wno-error=narrowing -fno-rtti

that seems to compile

now if you look at the demo:

void setup() {
  pinMode(13, OUTPUT);
}

void loop() {
  static uint32_t reflash = millis();
  (void)reflash;
  if ( millis() - reflash > 500 ) {
    reflash = millis();

    //    digitalWrite(13, !digitalRead(13)); <------------------------ digitalread doesnt work?

    static bool flip;
    digitalWrite(13, flip = !flip);

  }
}

toggling a bool to flash the led every millis() interval is fine. I'm not sure if digitalRead is working because led just stays on forever when uncommented

 

[defragster]

Wondering how much work it was to get this much to work ... this past YEAR! ... not to mention the purchasing and the EE part and making PCB's … before all the issues get posted … Thanks Paul for working to make this tame and usable.

Nothing in mailbox or recorded to post office yet ... just looking around with Verify ...

Paul ... I opened Verbose on Loader and still seeing repeat 'callback' on my Win 10 - I closed Teensy_ports and they stopped - if msgs not likely relevant to T4 can they get disabled?:

// ... about 15 pages ...
16:45:14.740 (ports 2): callback C12C
16:45:16.757 (ports 2): callback C12C
16:45:17.456 (loader): remote connection 1332 closed

<EDIT> WORKED for me too adding to build.flags >> -fno-threadsafe-statics

 

[defragster]

compiling coremark, i too get sbrk error
...

That is in :: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\libc.c

Swapping/commenting out the first line and replacing it allows it to compile:

//extern unsigned long _ebss;
unsigned long _ebss;

char *__brkval = (char *)&_ebss; // TODO: put heap into OCRAM, not DTCM

 

[tonton81]

coremark running

647120
2K performance run parameters for coremark.
647810 us 13072680 
CoreMark Size    : 666
Total ticks      : 13069010
Total time (secs): 13.069010
Iterations/Sec   : 2295.506699
Iterations       : 30000
Compiler version : 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags   : 
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x5275
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 2295.506699 / 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]  / STACK
.... done
done

Thanks Tim, I used the same line though

/*extern*/ unsigned long _ebss;

 

[PaulStoffregen]

The memory usage info is wrong for program size, maybe ram too. Correct info can be found in the .sym file.

For now, we're using the fixed partition of the RAM as 128K ITCM (code that isn't "progmem"), 128K DTCM (variables & strings that aren't progmem) and 256K OCRAM (currently not used at all, but soon dmamem and malloc/net). Later we'll switch to automatically sizing ITCM to fit the compiled code, fixed size for OCRAM, and DTCM taking the rest.

 

[tonton81]

#include "circular_buffer.h"
Circular_Buffer<uint32_t, 8> cb;
Circular_Buffer<uint32_t, 8, 100> cba;

#include "coremark.h"

void setup() {
  uint32_t arr[5] = { 1, 2, 3, 4, 5 };
  cba.push_back(arr, 5);
  cb.push_back(0x1234);
  pinMode(13, OUTPUT);
}

void loop() {
  static uint32_t reflash = millis();
  (void)reflash;
  if ( millis() - reflash > 500 ) {
    reflash = millis();

    //        digitalWrite(13, !digitalRead(13));

    static bool flip;
    digitalWrite(13, flip = !flip);
    Serial4.println("Toggled Led");
    Serial4.println(cb.peek());

    //
    //    Serial4.println("coremark running\n");
    //    Serial4.println(micros());
    //
    //    mainCoreMark();
    //
    //    Serial4.println("done\n");

    uint32_t arr[5];
    cba.pop_front(arr, 5);
    cba.push_back(arr, 5);
    for ( uint8_t i = 0; i < 5; i++ ) {
      Serial4.print(arr[i]); Serial4.print(" ");
    } Serial4.println();
  }
}

CB/CBA works on T4 both circular and array versions, without warnings or errors
It uses the algorithm c++ library

 

[mjs513]

Tried running a eigen library test and after incorporating Tim's sbrk fix and Tony's -cxa fix and manitou's -mpu change the only error received was as follows:

f:\arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\type_traits:38:28: fatal error: bits/c++config.h: No such file or directory.

type_traits is called from wiring.h. There is a c++config.h file but in arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\arm-none-eabi\armv7e-m\bits and up level in F:\arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\arm-none-eabi\bits. Do we need it? or which copy to we link too?

EDIT: Problem was changing this -mfpu=fpv4-sp-d16 -fsingle-precision-constant to -mfpu=fpv5-sp-d16. When I put it back that error disappeared. I also forgot to get rid of -lstdc++ now I am left with:

undefined reference to `operator new[](unsigned int)'

 

[tonton81]

I tested the listed non standard AVR functions on the list, they match the outputs as expected

    float f_val = 123.67942;
    char outstr[15];
    dtostrf(f_val, 7, 5, outstr);
    Serial4.println(outstr);

    long  a = 10000000;
    char buffer[50];
    ltoa(a, buffer, 16); // here 2 means binary
    Serial4.printf("value = %s\n", buffer);


    char output[40];
    uint32_t tmp = 0x12345678;
    ultoa(tmp, output, 16);
    Serial4.println(output);

T3.2 monitor:

123.67942
value = 989680
12345678

 

[tonton81]

Mike, I don't know which version you have or if you messed up the build file but im using bolderflight Eigen library on github, it wouldn't compile though because of the operator new error:

 undefined reference to `operator new(unsigned int)'

however i added 3 lines AFTER the demo's includes:

#include <Eigen.h>     // Calls main Eigen matrix class library
#include <Eigen/LU>             // Calls inverse, determinant, LU decomp., etc.
using namespace Eigen;    // Eigen related statement; simplifies syntax for declaration of matrices
[COLOR="#FF0000"]#include <stdlib.h> // for malloc and free
void * operator new(size_t size) {
  return malloc(size);
}
void operator delete(void* ptr) {
  if (ptr) free(ptr);
}[/COLOR]

it compiles without warnings or errors
T3.2 monitor shows:

nrow: 6
ncol: 6

0.112775, 0.048292, -0.313197, -0.067979, 0.238543, 0.096648, 
-0.002733, -0.177438, 1.128800, 0.750399, -1.283369, -0.084223, 
0.645583, 0.189010, -1.758835, -1.095649, 2.438091, 0.718835, 
-0.613755, -0.359209, 2.150181, 1.179505, -2.575186, -0.930255, 
0.504728, 0.085257, -0.751615, -0.277679, 1.106807, 0.128982, 
-0.107398, 0.104756, 0.108780, 0.094344, -0.231374, 0.222546,

 

[mjs513]

Interesting Tony,
Just reinstalled teensyduino did Tim's fix for sbrk and your fix

teensy4b.build.flags.cpp=-fno-exceptions -felide-constructors -std=gnu++14 -fno-threadsafe-statics -Wno-error=narrowing -fno-rtti

and that's it. I added in those lines to bolderflight's eigentest example which is what you ran but I am still getting the error on

 undefined reference to `operator new(unsigned int)'

. Not sure I could have messed up.

I did a verify on our coremark file and your CBA, both compiled without errors. Same for Brian's ublox library.

EDIT> this problem seems like deja vu where I ran into it another time and can't remember if it was related to newlib or newlib-nano.

 

[defragster]

Prior post ...

That is in :: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\libc.c

Swapping/commenting out the first line and replacing it allows it to compile:

//extern unsigned long _ebss;
unsigned long _ebss;

char *__brkval = (char *)&_ebss; // TODO: put heap into OCRAM, not DTCM

Just a hack to get the compiler happy ...

Interesting Tony,
... Tim's fix for sbrk
...

- copied there also was Paul's TODO note where the HEAP needs get relocated - and it somehow doesn't like the former expression that evolves from this.

T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\imxrt.ld:
74: _ebss = ADDR(.bss) + SIZEOF(.bss);

 

[manitou]

Tried running a eigen library test and after incorporating Tim's sbrk fix and Tony's -cxa fix and manitou's -mpu change the only error received was as follows:

f:\arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\type_traits:38:28: fatal error: bits/c++config.h: No such file or directory.

type_traits is called from wiring.h. There is a c++config.h file but in arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\arm-none-eabi\armv7e-m\bits and up level in F:\arduino-1.8.8\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\arm-none-eabi\bits. Do we need it? or which copy to we link too?

EDIT: Problem was changing this -mfpu=fpv4-sp-d16 -fsingle-precision-constant to -mfpu=fpv5-sp-d16. When I put it back that error disappeared. I also forgot to get rid of -lstdc++ now I am left with:

undefined reference to `operator new[](unsigned int)'

FWIW, a few weeks back working on NXP EVK eval board, I got this bits/c++config.h error when trying to use the Arduino tool chain to test gcc 5.4.1 on EVKB programs. Eventually I fetched a fresh 5.4.1 tool chain from GNU and the problem disappeared.