Teensyduino 1.58 Beta #1 (updated toolchain trial)

Building the Large FLASH code: T4Encrypt\Code4Code\CodeMade.ino :: Defragster/T4LockBeta/tree/main/Code4Code

Code:
<< TRUNCATED console output ??? >>
|                   ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t [B]ThisFunc3752[/B](uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:56297:24: error: 'seePi' cannot be used as a function
56297 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~
...
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t [B]ThisFunc0[/B](uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:60019:24: error: 'seePi' cannot be used as a function
60019 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~

exit status 1

Compilation error: 'uint' was not declared in this scope; did you mean 'rint'?

There are 4000 of these funcs, console output is truncated. Switching to smaller set with 4 not 4,000 copies:
Code:
Using board 'teensy41' from platform in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1
Using core 'teensy4' from platform in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1
Detecting libraries used...
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/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=158 -DARDUINO=10607 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1\\cores\\teensy4" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\sketch\\Code4Code.ino.cpp" -o nul
Generating function prototypes...
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/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=158 -DARDUINO=10607 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1\\cores\\teensy4" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\sketch\\Code4Code.ino.cpp" -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\preproc\\ctags_target_for_gcc_minus_e.cpp"
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\builtin\\tools\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\preproc\\ctags_target_for_gcc_minus_e.cpp"
Compiling sketch...
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/precompile_helper" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1/cores/teensy4" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-g++" -x c++-header -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -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=158 -DARDUINO=10607 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1/cores/teensy4" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A/pch/Arduino.h" -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A/pch/Arduino.h.gch"
Using previously compiled file: C:\Users\Tim\AppData\Local\Temp\arduino-sketch-4CE48C18C39C39394423426F2C82860A\pch\Arduino.h.gch
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -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=158 -DARDUINO=10607 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A/pch" "-IC:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1\\cores\\teensy4" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\sketch\\Code4Code.ino.cpp" -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino-sketch-4CE48C18C39C39394423426F2C82860A\\sketch\\Code4Code.ino.cpp.o"
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:12: error: 'uint' was not declared in this scope; did you mean 'rint'?
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |            ^~~~
      |            rint
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:28: error: expected primary-expression before 'char'
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |                            ^~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:39: warning: expression list treated as compound expression in initializer [-fpermissive]
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |                                       ^
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino: In function 'void setup()':
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:41:8: error: 'seePi' cannot be used as a function
   41 |   seePi( 200, NULL ); // Just for fun to see 800 Pi digits takes 9.1ms
      |   ~~~~~^~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:44:41: error: 'seePi' cannot be used as a function
   44 |   iiCnt = theCount = ThisFunc1( 0, seePi( PI_DIGITS, szPi ), &sumPi60dig );
      |                                    ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:49:25: error: 'seePi' cannot be used as a function
   49 |   int seePiStart = seePi( PI_DIGITS, szPi );
      |                    ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:77:33: error: 'seePi' cannot be used as a function
   77 |   theCount = ThisFunc1( 0, seePi( PI_DIGITS, szPi ), &sumPi60dig );
      |                            ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:91:21: error: 'seePi' cannot be used as a function
   91 |   seePiStart = seePi( PI_DIGITS, szPi );
      |                ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino: In function 'void loop()':
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:125:35: error: 'seePi' cannot be used as a function
  125 |     theCount = ThisFunc1( 0, seePi( PI_DIGITS, szPi ), &sumPi60dig );
      |                              ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:131:27: error: 'seePi' cannot be used as a function
  131 |     int seePiStart = seePi( PI_DIGITS, szPi );
      |                      ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino: At global scope:
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:12:20: warning: inline variables are only available with '-std=c++17' or '-std=gnu++17'
   12 | #define PI_INLINE  inline  // Set to 'inline' for seePi() inline
      |                    ^~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:1: note: in expansion of macro 'PI_INLINE'
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      | ^~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:15: error: redefinition of 'int seePi'
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |               ^~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:5: note: 'int seePi' previously defined here
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |     ^~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:22: error: 'uint' was not declared in this scope; did you mean 'rint'?
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |                      ^~~~
      |                      rint
C:\T_Drive\tCode\T4Encrypt\Code4Code\Code4Code.ino:172:38: error: expected primary-expression before 'char'
  172 | PI_INLINE int seePi( uint maxDigits, char *szPi ) {
      |                                      ^~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t ThisFunc1(uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:32:24: error: 'seePi' cannot be used as a function
   32 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t ThisFunc2(uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:47:24: error: 'seePi' cannot be used as a function
   47 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t ThisFunc3(uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:62:24: error: 'seePi' cannot be used as a function
   62 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino: In function 'uint32_t ThisFunc0(uint32_t, uint32_t, const uint32_t*)':
C:\T_Drive\tCode\T4Encrypt\Code4Code\CodeMade.ino:79:24: error: 'seePi' cannot be used as a function
   79 |   uint32_t myPi = seePi( PI_DIGITS, szPi );
      |                   ~~~~~^~~~~~~~~~~~~~~~~~~

exit status 1

Compilation error: 'uint' was not declared in this scope; did you mean 'rint'?

Gotta Run ... This built fine before - now 'int' is a problem and cascades ???
 
@Paul - @ftrias

Working on mods to teensythreads to get rid of errors and warnings. I did use @KurtE's
Code:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Warray-bounds"
  uint32_t *m = (uint32_t*)stack;
  *m = thread_marker;
#pragma GCC diagnostic pop
}
to get rid of array bounds issues on compile. That leaves this one that not sure what to do with:
Code:
F:\arduino-1.8.19-1131\hardware\teensy\avr\libraries\TeensyThreads\TeensyThreads.cpp:374:13: warning: 'void context_pit_empty()' defined but not used [-Wunused-function]
  374 | static void context_pit_empty() {}
      |             ^~~~~~~~~~~~~~~~~
Note this is identified as
Code:
/*
 * Empty placeholder for IntervalTimer class
 */

EDIT: Changes are currently in my fork
https://github.com/mjs513/TeensyThreads
 
@defragster can just change uint to unsigned int or do something like this

#ifndef uint
#define uint unsigned int
#else
#error
#endif
 
@defragster can just change uint to unsigned int or do something like this

...

Arrgh - close but gets redundant/recursive or something ... will just make them all uint32_t's ... Thx

working with this hack:
Code:
#ifndef uint
#define uint unsigned int
#endif
#ifndef int
#define int  int
#endif
 
Ok got a strange problem going on again with one of my libraries - happens on 1.57 as well as 1.58b1 but it did work at one time :) as usual.

I am trying to update my Teensy OpenGL library but when I load the sketch the TMM or the T4.1 both give me 9 blinks on the yellow led on the TMM or the red led on the T41. Unfortunately can not find where the blink codes are listed. And I loose USB Connection to Windows when it happens

UPDATE: Ok found the blink codes here https://www.pjrc.com/store/ic_mkl02_t4.html

but for 9 blinks:
Code:
9 Blinks = ARM JTAG DAP Init Error
The ARM JTAG DAP was detected (4 blinks) but could not be initialized. This error is rather unlikely!

EDIT2
Here is the log file - didn't notice anything strange View attachment log.zip

Heres where it was working:
https://forum.pjrc.com/threads/60571-Teensy-4-x-meets-OpenGL-(pseudo-OpenGL-anyway)?highlight=opengl\


UPDATE: Figureout the problem. Was using Franks T4PowerButton library to get ram info. Once commented out it loaded and ran no issues on the T4.1 but for some reason (have to investigate was failing on the TMM. Had that problem before but never found out why.
 
Last edited:
Note: I just pushed up a couple PR's for warnings:
RA8876... issue with indent.
JPEGDec - static functions defined but not implemented.

Running our enhanced picture viewer on an RA8876, with MTP of the SD drive.

With these warning messages for code formatting.

At times I wonder if we should aim toward something like Adafruit has done, where all of their libraries have gone through code formatter/verification
and PRs (actually with pre-commit) you can not commit until all of the formatting issues are resolved, likewise they do documentation tests as well, and then before PR is merged it has to pass building on all of
the appropriate platforms...
 
Note: I just pushed up a couple PR's for warnings:
RA8876... issue with indent.
JPEGDec - static functions defined but not implemented.

Running our enhanced picture viewer on an RA8876, with MTP of the SD drive.

With these warning messages for code formatting.

At times I wonder if we should aim toward something like Adafruit has done, where all of their libraries have gone through code formatter/verification
and PRs (actually with pre-commit) you can not commit until all of the formatting issues are resolved, likewise they do documentation tests as well, and then before PR is merged it has to pass building on all of
the appropriate platforms...

Sounds good but complicated to maintain .... but may be better in the long run
 
Good news or Bad news, depending on how you look at it ;)

Note: I am using USBHost_t36 with my HID_keyboard branch.

Built MouseKeyboardForward.ino W11 IDE2 this beta.
For T4.1 USB Type Serial.

I have a Gigabyte Force K83 plugged into the USBHost. No HUB just straight in.

When it finished uploading, it faulted. Like some of the time on current release.

Code:
USB Mouse and Keyboard forwarder
CrashReport:
  A problem occurred at (system time) 14:20:14
  Code was executing from address 0x26F0
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x10 (nullptr)
	  Check code at 0x26F0 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x26F0" for filename & line number.
  Temperature inside the chip was 38.01 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected

I will bet it is in ehci.c

Looks like the addr2line I have link to needs to be updated...
Code:
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-7858D9125BABC79477386166F029CF48>addr2line -e MouseKeyboardForward.ino.elf 0x26F0
addr2line: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information.
HardwareSerial.cpp:?

Although version from 1.8.19:
Code:
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-7858D9125BABC79477386166F029CF48>C:\arduino-1.8.19\hardware\tools\arm\bin\arm-none-eabi-addr2line.exe -e MouseKeyboardForward.ino.elf 0x26F0
c:\Users\kurte\Documents\Arduino\libraries\USBHost_T36/MassStorageDriver.cpp:889
Which does not make sense...
 
Looks like the addr2line I have link to needs to be updated...

The new toolchain has an updated copy. With Arduino 1.8.19 the default path on Windows would be C:/Program Files (x86)/Arduino/harware/tools/arm/bin/arm-none-eabi-addr2line.exe. Should also be within the IDE2 packages, probably easiest to search for "arm-none-eabi-addr2line.exe".
 
The new toolchain has an updated copy. With Arduino 1.8.19 the default path on Windows would be C:/Program Files (x86)/Arduino/harware/tools/arm/bin/arm-none-eabi-addr2line.exe. Should also be within the IDE2 packages, probably easiest to search for "arm-none-eabi-addr2line.exe".

I sort of showed that in the 2nd try... Also did it with the version in:
Code:
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-7858D9125BABC79477386166F029CF48>C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1-beta1\arm\bin\arm-none-eabi-addr2line.exe -e MouseKeyboardForward.ino.elf 0x26F0
c:\Users\kurte\Documents\Arduino\libraries\USBHost_T36/MassStorageDriver.cpp:889

Code:
 static const char *decodeAscAscq(uint8_t asc, uint8_t ascq) {
	static char msg[64];
	uint16_t ascAscq = asc<<8 | ascq;

	switch (ascAscq) {
#define SENSE_CODE_KEYED(_asc_, _fmt_)
#define SENSE_CODE(_asc_, _ascq_, _msg_) case _asc_<<8 | _ascq_: return _msg_;
[COLOR="#FF0000"]	ASC_NUM_LIST[/COLOR]
#undef SENSE_CODE
#undef SENSE_CODE_KEYED
	}

#define SENSE_CODE_KEYED(_asc_, _fmt_) if (asc == _asc_) { snprintf(msg, sizeof(msg), _fmt_, ascq); return msg; }
#define SENSE_CODE(_asc_, _ascq_, _msg_)
	ASC_NUM_LIST
#undef SENSE_CODE
#undef SENSE_CODE_KEYED

	snprintf(msg, sizeof(msg), "UNKNOWN ASC/ASCQ (%02Xh/%02Xh)", asc, ascq);
	return msg;
}

As I mentioned it really does not make sense as this sketch does not use MSC stuff.
The only USBHost stuff it uses is:
Code:
USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);
KeyboardController keyboard1(myusb);
KeyboardController keyboard2(myusb);
USBHIDParser hid1(myusb);
USBHIDParser hid2(myusb);

MouseController mouse1(myusb);
USBHIDParser hid3(myusb);
USBHIDParser hid4(myusb);

But since USBHost_t36 is a collection of several types of objects it ends up building several other libraries as well:
Code:
"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_size" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino-sketch-7858D9125BABC79477386166F029CF48/MouseKeyboardForward.ino.elf"
Multiple libraries were found for "USBHost_t36.h"
  Used: D:\github\USBHost_t36
  Not used: C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\USBHost_t36
Multiple libraries were found for "SdFat.h"
  Used: D:\github\SdFat
  Not used: C:\Users\kurte\Documents\Arduino\libraries\SdFat_-_Adafruit_Fork
  Not used: C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SdFat
Using library USBHost_T36 at version 0.2 in folder: D:\github\USBHost_t36 
Using library SDFat at version 2.1.2 in folder: D:\github\SdFat 
Using library SPI at version 1.0 in folder: C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SPI
 
@KurtE - @Paul

Just repeated Kurt's test with my K83 Gigabyte keyboard and got the same error:
Code:
  A problem occurred at (system time) 0:0:10
  Code was executing from address 0x23C4
  CFSR: 82
    (DACCVIOL) Data Access Violation
    (MMARVALID) Accessed Address: 0x10 (nullptr)
      Check code at 0x23C4 - very likely a bug!
      Run "addr2line -e mysketch.ino.elf 0x23C4" for filename & line number.
  Temperature inside the chip was 48.53 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected

running: C:\Users\Merli\AppData\Local\Temp\arduino-sketch-7E31F5E4632D6ADD46A2486534C99313>F:\arduino-1.8.19\hardware\tools\arm\bin\arm-none-eabi-addr2line.exe -e C:\Users\Merli\AppData\Local\Temp\arduino-sketch-7E31F5E4632D6ADD46A2486534C99313\KeyboardForeward.ino.elf 0x23C4 gives me the exact same error as Kurt showed:
Code:
arm-none-eabi-addr2line.exe: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information.
HardwareSerial.cpp:?

tried a couple of other keyboards and none gave me the reboots seen with the Gigabyte K83 keyboard. The other gigabyte kB I have isn't made by gigabyte but works.
 
Updated : github.com/Defragster/T4LockBeta

Using int32_t and all is well - it doesn't like 'int'
> though printf( %d ) when seeing int32_t it uses 'int' to say it should be long int ... so err msg uses a 'int' to help you fix when it doesn't know what 'int' is :)

All looks good - using IDE2 w/TD1.58b1 to build that test sketch that abuses FLASH to hold all 1.2MB of code.
Code:
Memory Usage on Teensy 4.1:
  FLASH: code:1216784, data:331272, headers:8420   free for files:6569988
   RAM1: variables:86880, code:48552, padding:16984   free for local variables:371872
   RAM2: variables:24736  free for malloc/new:499552

NOTE: IDE2 does seems to rebuild faster on small stuff - but compiling that 4000 set of funcs seems to take the same time as Sublime cmdline build - both 130+ secs
 
Ran it with debug turned on:
Code:
USB Mouse and Keyboard forwarder
CrashReport:
  A problem occurred at (system time) 18:16:15
  Code was executing from address 0x2780
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x10 (nullptr)
	  Check code at 0x2780 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x2780" for filename & line number.
  Temperature inside the chip was 44.82 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
  Breadcrumb #1 was 861226463 (0x335545DF)
  Breadcrumb #4 was 1962022025 (0x74F21489)
USB2 PLL running
 reset waited 6
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20005000
periodictable = 20005000

ISR: 408C
 Port Change
port change: 10001803
    connect

ISR: 1004088
 Timer0
  begin reset

ISR: 408C
 Port Change
port change: 10001805
  port enabled

ISR: 1004088
 Timer0
  end recovery
new_Device: 12 Mbit/sec
new_Pipe

ISR: 4C081
 USB Async
enumeration:

ISR: 4C081
 USB Async
enumeration:

ISR: C082
 USB Error
ERROR Followup
    remove from followup list
    remove from followup list
FYI - this is the same issue that mentioned in a few other places including: https://forum.pjrc.com/threads/6925...yboard-Problem?p=312261&viewfull=1#post312261


Code:
USB Mouse and Keyboard forwarder
CrashReport:
  A problem occurred at (system time) 0:0:10
  Code was executing from address 0x2780
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x10 (nullptr)
	  Check code at 0x2780 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x2780" for filename & line number.
  Temperature inside the chip was 47.30 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
Again I checked the Addr2line for this one:
Code:
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-7858D9125BABC79477386166F029CF48>addr2line -e MouseKeyboardForward.ino.elf 0x2780
c:\Users\kurte\Documents\Arduino\libraries\USBHost_T36/MassStorageDriver.cpp:889

Which I know is bogus... SO for the heck of it I reenabled the objdump post process step in the platform.txt file.

Looking at that address:
Code:
    2770:	d5e8      	bpl.n	2744 <USBHost::followup_Error()+0x70>
				Pipe_t *haltedpipe = p->pipe;
    2772:	f8d5 a028 	ldr.w	sl, [r5, #40]	; 0x28
				free_Transfer(p);
    2776:	4628      	mov	r0, r5
			Transfer_t *next = p->next_followup;
    2778:	4626      	mov	r6, r4
				Transfer_t *first = NULL;
    277a:	4625      	mov	r5, r4
				free_Transfer(p);
    277c:	f003 fea8 	bl	64d0 <USBHost::free_Transfer(Transfer_struct*)>
				p = (Transfer_t *)(haltedpipe->qh.next & ~0x1F);
    2780:	f8da 4010 	ldr.w	r4, [sl, #16]
				while (p && ((p->qtd.token & 0x40) == 0)) {
Which is what I expected. from the previous faults.
 
Updated : github.com/Defragster/T4LockBeta

Using int32_t and all is well - it doesn't like 'int'
> though printf( %d ) when seeing int32_t it uses 'int' to say it should be long int ... so err msg uses a 'int' to help you fix when it doesn't know what 'int' is :)

Note the inttypes.h include file defines various format modifiers for passing values to the *printf and *scanf functions. These format modifiers are string literals, and you can use the C/C++ functionality where adjacent string literals are combined by the compiler:

Code:
#include <inttypes.h>

volatile uint32_t u32;

void setup ()
{
    Serial.begin (9600);

    while (!Serial && millis () < 3000UL)
        ;

    Serial.printf ("u32 is %" PRIu32 "\n", u32);
}

void loop ()
{
}
 
relocation truncated

As mentioned some 1.5 years ago in the 1.54 beta thread (https://forum.pjrc.com/threads/66357-Teensyduino-1-54-Beta-7?p=274861&viewfull=1#post274861) there is an issue compiling the following simple code with newer gcc versions. Looks like the issue was introduced with commit "dc56788 Changes to support HAB (thanks dresden-fx)" from 2020-10-18 see https://github.com/PaulStoffregen/cores/commit/dc567880488dc53ba2e71eb07e04356bda7e2a7e

Code:
#include "Arduino.h"
#include <string>

void setup()
{
    std::string zahlString = std::to_string(42);
}

void loop()
{ 
}

The generated error message is this "truncated relocation" linker error which was reported recently in another context as well. The clear relation to the mentioned commit, which introduced changes in the linker scripts, might help fixing this and the other "relocation" issues.

Error messsage:
Code:
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(string-inst.o):(.ARM.exidx.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.extab.text.__cxa_begin_catch+0x0): relocation truncated to fit: R_ARM_PREL31 
against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.exidx.text.__cxa_begin_catch+0x4): relocation truncated to fit: R_ARM_PREL31 
against `.ARM.extab.text.__cxa_begin_catch'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text._ZL21base_of_encoded_valuehP15_Unwind_Context+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZL21base_of_encoded_valuehP15_Unwind_Context'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.extab.text.__gxx_personality_v0+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text.__gxx_personality_v0+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__gxx_personality_v0'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE+0x0): relocation truncated 
to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv111__terminateEPFvvE+0x4): relocation truncated 
to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv112__unexpectedEPFvvE+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv112__unexpectedEPFvvE'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZSt10unexpectedv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt10unexpectedv'
c:/progra~2/arduin~1.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/thumb/v7e-m+dp/hard\libstdc++.a(vterminate.o):(.ARM.extab.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x0): additional relocation overflows omitted from the output
 
Last edited:
Note the inttypes.h include file defines various format modifiers for passing values to the *printf and *scanf functions. These format modifiers are string literals, and you can use the C/C++ functionality where adjacent string literals are combined by the compiler:

Code:
#include <inttypes.h>

volatile uint32_t u32;

void setup ()
{
    Serial.begin (9600);

    while (!Serial && millis () < 3000UL)
        ;

    Serial.printf ("u32 is %" PRIu32 "\n", u32);
}

void loop ()
{
}

Interesting but 'fix' was just taking "%d" to "%ld" when prior working 'int' became 'int32_t'.
> It is a valuable warning - at least when using a uint64_t type SIZE from FS file where without "%llu" give really bad numbers for reference.
 
Committed a fix for the "relocation truncated to fit: R_ARM_PREL31" errors.

https://github.com/PaulStoffregen/cores/commit/d496c4579e86821f6a8dbeb2f0a7bbbd5288331b


Looks like the issue was introduced with commit "dc56788 Changes to support HAB (thanks dresden-fx)" from 2020-10-18

Yes, it was related to that commit, but only as a side effect.

The real problem is newer toolchains added more .ARM.blah_blah_blah sections which the linker script wasn't including in the proper place (or anywhere). As a result, they were left over after the linker runs all the output sections, leaving them with essentially undefined values which depend on details of whatever the linker script caused the linker to do. Adding the .text.csf output section, which is needed to allocate space for the CSF which teensy_secure uses, caused leftover unassigned stuff to get different values. The true problem wasn't anything in that commit. It was the fact that the old linker script didn't handle assigning this extra stuff which the older toolchains never had.
 
If I compile with using std=gnu++17 instead of the standard gnu++14, Arduino.h clashes with <chrono>. Including "Arduino.h" after <chrono> fixes this. I assume the clash is related to #defining standard things like min/max etc in wiring.h.

Line 34ff of wiring.h has this code:
Code:
#include <stdint.h>
#include <stdlib.h>
#include <stdbool.h>
#include "binary.h"
#include "core_id.h"
#include "core_pins.h"

// type_traits interferes with min() and other defines
// include it early, so we can define these later
// for Arduino compatibility
#ifdef __cplusplus
#include <type_traits>

Might be a good idea to add #include <chrono> after #include<type_traits> which fixes the issue for <chrono> as well.

Switching from c++14 to c++17 by default would be nice.
 
Yes, it was related to that commit, but only as a side effect.

The real problem is newer toolchains added more .ARM.blah_blah_blah sections which the linker script wasn't including in the proper place (or anywhere). As a result, they were left over after the linker runs all the output sections. Adding the .text.csf output section, which is needed to allocate space for the CSF which teensy_secure uses, caused leftover unassigned stuff to get different values. The true problem wasn't any of the stuff added in that commit. It was the fact that the old linker script didn't handle assigning this extra stuff which the older toolchains never had.

Great, I'll give it a try later.
 
I was also wondering if you ran your perl scripts?

Yes, ran it briefly before packaging. Let it complete last night. Will build a list soon. The script's output isn't a nice & pretty format.


Also curious on what things are gained by this and where problems are more likely to be lurking?

For example, if the biggest is gain is to allow some more modern stuff in let's say templates or std:: classes, I more or less seldom if ever use them, so I am less likely to find any issues there.
Hopefully others who use it, will test those areas.

Personally, I'm pretty happy with gcc 5.4.1. Staying with the old toolchain would be the easy choice which allows focusing on hardware and software features. Over and over I've put off update the toolchain. It's pretty commonly requested, mostly by C++ & STL fans, and I do take notice of things people request even if they're not something I would personally want.

The rest of the Arduino ecosystem is moving to newer toolchains, like gcc 9 or newer. Looks like most are sticking with C++11 dialect for now. But sooner or later, Arduino or others are going to publish examples or libraries where we'll need a newer toolchain for compatibility.


Note: some of the code that the compiler flags, makes me want to pull out a few more strands of hair. Like:

Code:
:\Users\kurte\Documents\Arduino\libraries\USBHost_T36\USBHost_t36.h:2479:44: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
 2479 |                 Device_t *dev = *(Device_t * volatile *)&device;
      |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixed
https://github.com/PaulStoffregen/USBHost_t36/commit/0c86f2cb3ecc645fe11fe63339dfc6247110537b


What is gained by this versus:
Code:
operator bool() { return device != nullptr;}
What does volatile gain you here?

Using volatile prevents the compiler from optimizing reading the pointer outside of a loop if the Arduino sketch code checks the status like this: "while (!mydrive) { /* wait */ }". The compiler (usually) will inline this function, and without volatile it is free to just read the pointer once, since it's stored in memory and the compiler assumes memory doesn't just spontaneously change. But of course the USB host library runs on interrupts and things like this pointer do change.
 
It is complaining that for example dtf.mday is a byte that it might get trancated... But the last time I checked there are no months that have 100+ days in them ;)

Probably simplest to just make the ctimebuf[16], mtimebuf[16] buffers 21 bytes, even though the extra bytes would only be used if the struct had invalid data.

Yeah, it's a waste of 10 bytes. But if something else went wrong and the struct has invalid data, it would prevent that issue from turning into a buffer overflow.
 
Back
Top