Teensy 4.0 First Beta Test

Status
Not open for further replies.
I got this to repro following what @mjs513 reported with uncannyeyes from noted thread above.

Something odd in linking or run time loading? There are multiple pieces to load as noted.

Update:: post #3710 has two ZIP files that should hold all the needed parts as I have them

I have gotten it to Fail and then Unfail and it hinges on FaultHandler code being local or the 'weak' version in the Teensy4.

No displays are needed just a T4 on a USB cable.

UPDATE :: In case it holds some info without needing to do a full setup/build/repro - here are the Hex/Lst/Elf contents of working and not working build directory in the ZIP as named:
T:\TEMP\arduino_build_159521>dir /b
build.options.json
FAILS_T4_build.options.zip :: View attachment FAILS_T4_build.options.zip << these files for FAILS
includes.cache
uncannyEyes0.ino.eep
uncannyEyes0.ino.elf
uncannyEyes0.ino.hex
uncannyEyes0.ino.lst
uncannyEyes0.ino.sym
WORKS_T4_uncannyEyes0.ino.zip :: View attachment WORKS_T4_uncannyEyes0.ino.zip << these files for WORKS

Did a CodeCompare Diff of the two LST files and tons of changes not surprising.

One BIG glaring chunk of stuff MISSING in the FAILS case { .lst is 982 KB ) that is present in the WORKS case { .lst is 1,232 KB } is:
Code:
[COLOR="#FF0000"]00006320 <_vfprintf_r>:
    6320:	e92d 4ff0 	stmdb	sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
    6324:	ed2d 8b06 	vpush	{d8-d10}
    6328:	b0b9      	sub	sp, #228	; 0xe4[/COLOR]
    632a:	461c      	mov	r4, r3
    632c:	468a      	mov	sl, r1
// there are 60+ pages for this item missing in the FAILS case.

<edit> vfprintf is its own thing:
...\hardware\teensy\avr\cores\teensy4\avr\pgmspace.h:
70 #define strstr_P(a, b) strstr((a), (b))
71 #define sprintf_P(s, ...) sprintf((s), __VA_ARGS__)
72: #define vfprintf_P(fp, s, ...) vfprintf((fp), (s), __VA_ARGS__)
73 #define printf_P(...) printf(__VA_ARGS__)
74 #define snprintf_P(s, n, ...) snprintf((s), (n), __VA_ARGS__)

Here is a copy of the post #361 from the other thread with links and parts needed - if it isn't clear @mjs513 should be able to repro and explain:

Lots of pieces from https://forum.pjrc.com/threads/55735-ILI9488_t3-Support-for-the-ILI9488-on-T3-x-and-beyond?p=210182&viewfull=1#post210182 ::
https://github.com/PaulStoffregen/cores
https://github.com/KurtE/Adafruit-GFX-Library
https://github.com/PaulStoffregen/SPI

Here is the UnCannyEyes as used here - with local copy of HardFault_HandlerC(): View attachment 16981

from post >>uncannyEyes0.Zip

… link to st7735 … https://github.com/KurtE/ST7735_t3/tree/writeRect_reset_delay

Time to gather …
NOT NEEDED :: from post >>debug_tt.zip

NOTE: Once it compiles to upload a failed repro build - to get back to working SerMon USB seems to take a SECOND Button push to get working SerMon back from USB. The SPI LED will blink - but USB stays corrupted until a second Button Push upload.

<edit> debug_tt - not required if this is placed in the sketch - just toggle: #if 0 and 1.
NOTE: It is not because the HardFault_HandlerC() is truncated - the copy in debug_tt is a full copy - and instead of the minimal copy below I did another FULL copy of the current version from CORES and the repro is the same. The problem seems to be in the linking or code placement in memory - even though in these cases the T4 is never faulting - so the code is never called or executed.
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

>> Running with BARE T4 on USB cable - white wire T4B2.
OKAY - I get REPRO when this is changed per note above when this line uncommented:
Code:
T:\tCode\t4\uncannyEyes0\config.h:
  136    #define BLINK_PIN         1 // Pin for manual blink button (BOTH eyes)
  137    #define LIGHT_PIN      A2 // Photocell or potentiometer (else auto iris)
[COLOR="#FF0000"]  138:   //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell[/COLOR]

NOTE: it fails, then Button upload when debug_tt active in sketch by uncommenting or recommenting - when the local copy of "HardFault_HandlerC" comes or goes - just the change in config.h causes the code to recompile and that brings the failure back.
Note from @mjs513 above:
To duplicate load up the sketch on a clean install and then just comment/uncomment the line
Code:
  //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
In this case uncomment it. You don't even need to have displays attached. To duplicate it though you can't use your debug_tt. If you include it, it some how fixes the problem.

BUT:: IDE SerMon shows Garbage after first upload - it comes online properly with a second Button Upload. It looks like this:
>> This is a telling PIC of bad USB Garbage from other post <<
UnCannyE0.png
Then it clears up showing the 64's and is running???


Edit: I am seeing two kinds of fail - the obvious one I removed debug_tt and made the config.h change - T4 not running - no SPI LED and this on SerMon:
Code:
T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03
********
 T4 connected Serial_tt ******* debug_tt port

T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03InitCreate display #Create display #Reset displaysCall init/begin func for each display

The less obvious case it seemed to start and print normally - and had to observe the LED stayed OFF - with no SPI activity.

--- This text from WIP - before I had clean repro steps ---
<EDIT UPDATE> I am not getting "REPRO / NO REPRO /REPRO / … " by reverting the code?
@mjs513 - is your note saying any change to 'LIGHT_PIN' ? I did get a hang now with it commented - before it was when uncommented?
It does seem to take 'Clean Build' - once it works it seems to persist? Maybe it is a change from change to '\uncannyEyes0\config.h' ?
 
Last edited:
Paul: There is an outstanding PULL request : https://github.com/PaulStoffregen/cores/pull/358

In the PULL request that 'weak' HardFault_HandlerC() is getting dropped with LTO.

In post #3701 above printf { aka: <_vfprintf_r> ?? } is getting dropped

I just added pull request line ((used) to my local CORES and it did not stop this failure and the smaller LST file - but not sure if it points to anything to help?

@Frank B {@others} - does the above look like anything to you?

NOTE: In above post this is NOT LTO compiled - just the normal default.

Where with LTO build Frank B found this 'weak' code prototype in startup.c was needed:
Code:
[B]void HardFault_HandlerC(unsigned int *hardfault_args) __attribute__((used));[/B]
__attribute__((weak))
void HardFault_HandlerC(unsigned int *hardfault_args) {
  volatile unsigned int stacked_r0 ;

Also Note - when this is removed "#define PRINT_DEBUG_STUFF" - that printf usage in the HardFault_...() code gives warnings - so there may be some linker confusion about it being needed? But this error repro's the same with or without 'Print_debug_stuff' - as I tried that first before putting it back and making the local HardFault_Handler() as tested above.

In the three cases where a SKETCH based {not weak} version of HardFault_HandlerC() is included it either doesn't include printf, or in the ZIP above it is explicit and not 'weak'
 
@PaulStoffregen (@KurtE, @defragster)

If you look at the scenario's from what I was doing as well as @KurtE and @defragster, I am seeing the following if I load uncanyeyes on a clean T4 (did a 15s restart) first and with debug_tt not included in sketch. Note: This is probably just a rehash of previous info on the USB lose. The pin issue was not described above

On first load the sketch runs as advertised for me displaying eyes on both ST7735's. Now the problems starts....

Test 1 - if I try to change the pin select from pin 6 to pin 23 for the right eye. Sketch says done uploading and get the familiar ping and Teensyduino uploading the sketch but it doesn't change to using pin 23. To make the change you have to do a 15 sec reboot. After reloading sketch using pin 23 it works using pin 23. If you do include debug_tt changing from pin 6 to pin 23 will work on reload without a 15s restart.

Test 2 - seems very repeatable is commenting and uncommenting this line as @KurtE and @defragster described:
Code:
             //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
Everytime you will loose USB port for the T4 - testing with the white wire on bottom since I can take that one out of the breakout board and put it on a breadboard. To recover I have to the 15sec restart again if I want to try something else with the sketch. Note that I tested this scenario with all 3 of the T4B2s that I have including on the breakout board with the ribbon cable.

<edit> Forgot. When this occurs gibberish is also printed out on serial4.

For the scenario with the lost USB if I load the sketch with debug_tt it will print gibberish and the eyes look like newspaper eyes but it runs. If I hit the reload it will recover --- @defragster described this in previous posts.
 
Last edited:
@MichaelMeissner

Hi Michael, I have a question:
GCC8 (Compiler version : 8.3.1 20190703 (release) [gcc-8-branch revision 273027]) complains about the xxx.offsetyyy mechanism in imxrt.h.
(Edit: Just copy the zipfile to .. /hardware/tools/arm8 and modify this line in boards.txt: teensy4b2.build.toolchain=arm8/bin/ - that's all)
Test:
Code:
#include <Wire.h>

void setup() {}
void loop() {}
Errormessages:
Code:
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1141:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset070' has side-effects
 #define CCM_CCGR2   (IMXRT_CCM.offset070)
                     ~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:307:9: note: in expansion of macro 'CCM_CCGR2'
         CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
         ^~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1141:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset070' has side-effects
 #define CCM_CCGR2   (IMXRT_CCM.offset070)
                     ~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:316:9: note: in expansion of macro 'CCM_CCGR2'
         CCM_CCGR2, CCM_CCGR2_LPI2C3(CCM_CCGR_ON),
         ^~~~~~~~~
C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1145:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset080' has side-effects
 #define CCM_CCGR6   (IMXRT_CCM.offset080)
                     ~~~~~~~~~~~^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:325:9: note: in expansion of macro 'CCM_CCGR6'
         CCM_CCGR6, CCM_CCGR6_LPI2C4_SERIAL(CCM_CCGR_ON),

In imxrt.h, we have:
Code:
typedef struct {
    volatile uint32_t offset000;
    volatile uint32_t offset004;
    volatile uint32_t offset008;
....

} IMXRT_REGISTER32_t;

...

#define CCM_CCGR2            (IMXRT_CCM.offset070)
The code in WireIMXRT which the produces the error is:
Code:
PROGMEM
constexpr TwoWire::I2C_Hardware_t TwoWire::i2c1_hardware = {
        CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
        {{18, 3 | 0x10, &IOMUXC_LPI2C1_SDA_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
        {{19, 3 | 0x10, &IOMUXC_LPI2C1_SCL_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
        IRQ_LPI2C1
};
TwoWire Wire(&IMXRT_LPI2C1, TwoWire::i2c1_hardware);
i2c1_hardware is:
Code:
    typedef struct {
        volatile uint32_t &clock_gate_register;
        uint32_t clock_gate_mask;
        pin_info_t sda_pins[cnt_sda_pins];
        pin_info_t scl_pins[cnt_scl_pins];
        IRQ_NUMBER_t irq;
    } I2C_Hardware_t;
    static const I2C_Hardware_t i2c1_hardware;

Do you know, what the errors are, or what exactly the side-effect is?
Is there a simple workaround, or shall we remove the .offsetyyy machanism? Edit: I think it is there, because GCC can use the optimized THUMB register+offset adressing (more efficient with >1 subsequent device accesses) if it is defined this way.

@all: I preferred a more simple solution for SPI.h
https://github.com/PaulStoffregen/SPI/pull/50/commits/c2197dbcf623f5e3084d8a16d96a488a06eb1b8a
 
Last edited:
Well, it's needed(unless there is a better solution) otherwise it does not compile with LTO.

Yes, that is needed for LTO to prevent it being discarded.

I was wondering about the issue in the post above where printf is not showing in the .lst file for the case where USB and the T4 fails. Somehow in this case it seems to be related to the same code but not an LTO compile and adding that 'used' declaration is not making the difference.
 
@defragster: Can you post a short Arduino-Sketch that helps to reproduce the problem?

I'm not sure how Frank … This came from efforts by @mjs513 - as posted is the only way it has been seen and reproduced.

In my efforts I have not seen this that seems to be a failure to 'compile/link'. Those linked libs on current PJRC github CORES was the first I could get to see it.

It was always failing for @mjs513 and I offered debug_tt at some point - and adding it only changed the 'Fault_Handler' by adding a non-(weak) version and in the process a usable HEX is built.

Assuming the only issue was the non-weak 'Fault_Handler' code as posted I dropped debug_tt and put a local "C" copy of HardFault_HandlerC() in the sketch as posted either a complete copy of the PJRC version - or a minimal version. When that was done it worked.


Even that took some time as the build works once it works to some degree - and takes some change to a very trivial piece of code that gets recompiled:
Code:
#ifdef LIGHT_PIN_FLIP
  v = 1023 - v;                            // Reverse reading from sensor
#endif

Changing that #define in the header leads to a failed build when using the (weak) Fault_Handler - and that is the only effect of that config.h edit.

In my case at no point did I have to do a 15s Restore - but as noted once it had a failed HEX installed - it takes not one but two Button uploads to get proper operation without the USB being messed up as pictured.
 
The reason for the needed "attribute((used))" is that HardFault_HandlerC is referenced in ASM only (I think), here: https://github.com/PaulStoffregen/cores/blob/master/teensy4/startup.c#L290
The used attribute ensures that it gets compiled in, because (I think) otherwise the linker thinks it is not needed and removes it. As a consequence, printf may be removed, too, if not used anywhere else.
Perhaps, this printf needs a attribute((used)), too?

Again, a short testsketch would be great - or a zipfile (and instructions how to use it) that contains everything needed (and it should be independend of extra hardware)
 
The p#3701 above list of libs and update cores is what is needed - including the uncannyEyes sketch. No hardware but a T4 is needed.

As for instructions that should be in #3701 this thread - or in the thread that caused this where I figured out how to recreate what @mjs513 ran into and posted here.

This should replicate those files - It is a 1.5 MB Zip of Three LIBRARIES and the SKETCH folder.

Here is the github\pjrc\CORES ZIP I used ::

In all my builds - and every one else's on the Beta this has not been any sort of recurring trouble - there is something about this it seems.

Note: I updated the above post - the missing piece I see in the .lst file is a unique :: vfprintf

And yes, it seems that the hidden ASM ref to Fault_Handler hides from the LTO code the need - so marking that USED is not the question - only came across the fact that that PULL request is still outstanding - and somewhat ODD that this non LTO build has what seems to be similar trouble in the same code area where according to the LST file - a needed and large section of CODE is being excluded that seems to be related to the HEX not being usable.
 
Last edited:
In order to compare Teensy processor speeds I ported a couple of CPU-intensive programs to T4b2.
The first is a ray-tracing program which does a *lot* of single precision floating point calculations to generate a 512x512 PPM-format image on the audio board's uSD card. I originally had it running on a T3.1 which took all night to generate one image. I have now run it on T3.6 and T4b2.
Code:
 96MHz T3.1 took 8 hours and 53 minutes.
180MHz T3.6 took 42.6 minutes
396MHz T4b2 took 3.5 minutes

…..

Pete
Ok you peaked my interest - starting to play with 3d graphics and ray tracing for the T4 - what lib did you port? Started discussing here: https://forum.pjrc.com/threads/5573...3-x-and-beyond?p=210250&viewfull=1#post210250
 
@mjs513: I used the minray code which is at various places on the internet. I've attached a zip of the code and an image.

Pete
 

Attachments

  • minray.zip
    94.4 KB · Views: 156
  • AEK.gif
    AEK.gif
    90.1 KB · Views: 145
Marked TimeAlarms as working in Post #4

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

...
 
@MichaelMeissner

Hi Michael, I have a question:
GCC8 (Compiler version : 8.3.1 20190703 (release) [gcc-8-branch revision 273027]) complains about the xxx.offsetyyy mechanism in imxrt.h.
(Edit: Just copy the zipfile to .. /hardware/tools/arm8 and modify this line in boards.txt: teensy4b2.build.toolchain=arm8/bin/ - that's all)

Note, I am a back-end person, and I only minimally use C++ in the compiler code and Arduino/Teensy scripts. I don't know why the compiler is issuing the message. Sorry.

On my Linux Fedora system, the arm-none-eabi-gcc compiler is 7.x and it works. If I download the 8.x version, it fails.
 
@Defragster, I tried your zip-files.
Does not compile - I get
Code:
uncannyEyes0: In function 'void drawEye(uint8_t, uint16_t, uint8_t, uint8_t, uint8_t, uint8_t)':
uncannyEyes0:523: error: 'displayType {aka class ST7735_t3}' has no member named 'writeRect'
     eye[e].display->writeRect(0, screenY, SCREEN_WIDTH, 1, colors);
 
@mjs513 - any ideas?

@Defragster, I tried your zip-files.
Does not compile - I get
...

Odd, There were three libraries in there that needed to be used and then the sketch folder for uncannyEyes0. Seems the ST7735_t3 library might not be the right one if it was updated? I know nothing about this code ...

Those are the ones I got from the prior post off of github and I just put them together - they should work. Here is what my build console shows using three libraries - all are in there as shown below - in my SKETCHBOOK\libraries folder:
Multiple libraries were found for "SPI.h"
Used: T:\tCode\libraries\SPI
Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
Multiple libraries were found for "Adafruit_GFX.h"
Used: T:\tCode\libraries\Adafruit_GFX
Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\Adafruit_GFX
Multiple libraries were found for "ST7735_t3.h"
Used: T:\tCode\libraries\ST7735_t3
Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\ST7735_t3
Using library SPI at version 1.0 in folder: T:\tCode\libraries\SPI
Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX
Using library ST7735_t3 at version 1.0.0 in folder: T:\tCode\libraries\ST7735_t3
 
Status
Not open for further replies.
Back
Top