Teensy 4.0 First Beta Test

Status
Not open for further replies.
It does not happen with GCC 6 - so simplest assumption is: Compiler/Linker Bug.
GCC 8: Does not compile because of WireIMXRT.cpp (see above...)
GCC7: Don't have a installation at the moment.

So, I will not dig deeper.. makes not much sense :)

Edit: "Our" gcc (5.4.1 from 2016) is quite old..but with coremark, it's the fastest so far. Maybe we should do more benchmarks with newer versions? Maybe the newer versions just don't like coremark.
 
Last edited:
Ok, I can reproduce that now.

Creepy! ;)

It does not happen with GCC 6 - so simplest assumption is: Compiler/Linker Bug.
GCC 8: Does not compile because of WireIMXRT.cpp (see above...)
GCC7: Don't have a installation at the moment.

So, I will not dig deeper.. makes not much sense :)

Yes, it is some confusion in the build>linker dropping out some needed code shown comparing the LST files.

:( - thought for sure I assembled the libs from the right place … where I used them from …

As far as the PULL request for (used) - I only mentioned that as not yet done - but ODDLY it comes from the same place in the code to some degree and wondering if that is where the dropping of this code is from.

AFAIK @mjs513 ran into a few issues in his beta work that were similarly ODD if not the same - but it didn't hit many others that made mention.

re @mjs crosspost - yes many other compile options not yet tried - or failed when tried … I noted that the other day as something to have tested.
 
Isn't it though :). Wonder if it shows the same behavior with other optimizations? Oh - it does work on a T3.6 last I looked.

Not sure what it would be good for. I'd just accept that it is an old bug which seems to be fixed in the "newer" GCC 6
I'd just switch to GCC 6 :)


p.s. I suspect that the GCC 8 problem from above("side-effects") is also just a (new) bug...
 
Oh, i see.. there is a big 5.4.1 folder inside - remaining from a test I did some months ago.. :) sry :)
I think you can delete the 5.4.1 folder inside \arm6\lib\gcc\arm-none-eabi
 
@Frank B and @defragster @KurtE

Hope you don't mind but I just downloaded and installed your GCC 6. Ok don't get the that error anymore but without debug_tt the eyes on the two screens are distorted. Yes you can make changes with it crashing and loosing usb but:
20190716_172955.jpg
 
@Frank B and @defragster @KurtE

Hope you don't mind but I just downloaded and installed your GCC 6.

It's there to be downloaded :) I'll leave it there.

I don't know where the distortions come from. Maybe a bug somewhere else.. the picture looks like overflows or memory corruption.
I don't have the displays.
 
@mjs513 - Maybe we should try selecting a lower SPI speed and see if that makes a difference there?
 
@mjs513 - Maybe we should try selecting a lower SPI speed and see if that makes a difference there?

@KurtE Tried several SPI freq lowering it down to 8Mhz but no change to the distorted image.

Note that if I do and include debug_tt it the eyes on both screens display normally.

It looks almost like a memory issue
 
@KurtE Tried several SPI freq lowering it down to 8Mhz but no change to the distorted image.

Note that if I do and include debug_tt it the eyes on both screens display normally.

It looks almost like a memory issue

instead of debug_tt - do the prior posted sketch local copy of the Fault_Handler:
Code:
#if 1  // TOGGLE 0 to exclude and cause BAD USB - set back to 1 and recompile to correct.
#ifdef __cplusplus
extern "C" {
#endif

#if defined(__IMXRT1052__) || defined(__IMXRT1062__)
void HardFault_HandlerC(unsigned int *hardfault_args) {
  digitalWriteFast( 13, HIGH );
  while (1);
}
#endif
#ifdef __cplusplus
} // extern "C"
#endif
#endif

The code isn't being called - though that should run - but it shows it is a simple linkage {code movement or memory setup?} issue going to smaller code if that affects it.

My effort to switch to arm6 doesn't work?

It exists here as indicated?:
"T:\arduino_1.8.9_146\hardware\tools\arm6\bin\arm-none-eabi-g++.exe"

But with change in boards.txt stops with this after closing and re-opening the IDE::
"T:\\Ard186t4b2\\hardware\\teensy/../tools/arm6/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\cores\\teensy4" "T:\\TEMP\\arduino_build_226809\\sketch\\uncannyEyes0.ino.cpp" -o nul
exec: "T:\\Ard186t4b2\\hardware\\teensy/../tools/arm6/bin/arm-none-eabi-g++": file does not exist
Error compiling for board Teensy 4-Beta2.
 
@defragster

Change "arm6" to arm and it will run. I zipped the present toolchain and then copied arm6 over and renamed it to "arm". I also deleted the 5.3.1 folder.
 
@defragster - @Frank B

Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2
 
@defragster - @Frank B

Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2

Odd Frank B thought the new 'arm6' path with edit would make it work to use new compiler … except for the part before " … " the last part should have found the .exe?

Doesn't sound like a good solution without more work. Not sure if Paul has any thoughts of replacing tools now? It might have seemed sensible up front with Beta to add new libs/features or updated 1062 type support . . .

… Uncanny eyes I don't have hardware and it was noted the resultant EXE has odd but functional behavior I wouldn't see.
… Eigen or other not working?

Seems like the .ld and segmentation or build flags or func() decorations may need tweeked?

Though maybe UncannyEyes just has a fault or code issue in it somewhere - though why that would exhibit as it did is odd.

Will be interesting as the other optimize/build choices get used more.
 
I just undid boards.txt back to arm\bin with unchanged TD version of gcc. I did a build without local Hard_Fault and the LST MASM file is SMALL - but AUTO Upload works, the SerMon shows proper text and the LED is blinking. The below line was commented.

Then uncommented this and rebuilt:
#define LIGHT_PIN_FLIP // If defined, reverse reading from dial/photocell

the LST MASM file is still the same size and now it is failing. So that obvious difference isn't behind the issue?
T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 16 2019 17:02:07
********
T4 connected Serial_tt ******* debug_tt port

T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 16 2019 17:02:07InitCreate display #Create display #Reset displaysCall init/begin func for each display

Note: debug_tt not in use - that is just a print line in setup()

Something very odd … but not apparently indicated by just the small lst file.

<EDIT>
This code is expecting 10 bit analog 1023 max value? Is this resolving to a fatal value without the #define of LIGHT_PIN_FLIP?:
Code:
void loop() {

#if defined(LIGHT_PIN) && (LIGHT_PIN >= 0) // Interactive iris

  int16_t v = analogRead(LIGHT_PIN);       // Raw dial/photocell reading
#ifdef LIGHT_PIN_FLIP
  v = 1023 - v;                            // Reverse reading from sensor
#endif
  if (v < LIGHT_MIN)      v = LIGHT_MIN; // Clamp light sensor range
  else if (v > LIGHT_MAX) v = LIGHT_MAX;
  v -= LIGHT_MIN;  // 0 to (LIGHT_MAX - LIGHT_MIN)
#ifdef LIGHT_CURVE  // Apply gamma curve to sensor input?
  v = (int16_t)(pow((double)v / (double)(LIGHT_MAX - LIGHT_MIN),
                    LIGHT_CURVE) * (double)(LIGHT_MAX - LIGHT_MIN));
#endif
  // And scale to iris range (IRIS_MAX is size at LIGHT_MIN)
  v = map(v, 0, (LIGHT_MAX - LIGHT_MIN), IRIS_MAX, IRIS_MIN);
#ifdef IRIS_SMOOTH // Filter input (gradual motion)
  static int16_t irisValue = (IRIS_MIN + IRIS_MAX) / 2;
  irisValue = ((irisValue * 15) + v) / 16;
  frame(irisValue);
#else // Unfiltered (immediate motion)
  frame(v);
#endif // IRIS_SMOOTH
 
This code is expecting 10 bit analog 1023 max value? Is this resolving to a fatal value without the #define of LIGHT_PIN_FLIP?:
I have a optoresitor in the loop attached to pin A2 but I've run the sketch with one display with and without it attached.... besides on compile/upload it should be an issue until it runs - so it doesn't even get that far.
 
@defragster - @Frank B

Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2

Of course, it's quite possible that there are incompatibilities.
Which errors do you get? We should fix them (if in the core), for the future. Paul will surely want to use a newer toolchain sometime later.
The default GCC 5.4 is quite old.
 
Of course, it's quite possible that there are incompatibilities.
Which errors do you get? We should fix them (if in the core), for the future. Paul will surely want to use a newer toolchain sometime later.
The default GCC 5.4 is quite old.

@Frank B
Really don't remember the errors but would definitely need to be fixed if Paul updated from GCC 5.4 - not sure if he wants to do this at this point in time - a lot of regression testing would probably have to be done not only for the T4 but for the T3.x's but....
 
I hope it's okay to ask this here, as I'm not a beta tester...

Is there a general idea of when the T4 might be released? I have an application which could really use the CPU and RAM of the T4.

Thanks to all those contributing their expertise to the beta testing, you're making things easy for us mere mortals who use the finished products.
 
...
Is there a general idea of when the T4 might be released? …

Only Paul can answer specifically - but general from prior posts plan was IIRC July 2019 - may still make it - but last post noted delivery of production PCB's was not 100% on schedule and production was starting with smaller initial batching to test the building of the little Monsters.
 
Status
Not open for further replies.
Back
Top