Teensyduino 1.58 Beta #1 (updated toolchain trial)

PaulStoffregen · Sep 10, 2022

shawn said:
Curious, will there be a MacOS version of 1.58-beta2?

If I package it up later today, then no. Building for MacOS is complicated, and especially a change like this is going to take some fiddling to adapt the way I do the signing and Apple notarization steps.

But if I wait a week or so, probably.

At this moment I'm looking at whether to include time.h. Runing the verify_all perl script now...

defragster · Sep 10, 2022

KurtE said:
Sorry, I know that all of this is somewhat off topic, but I keep meaning to also try:

...
Sorry, back to the normal interruptions.

Beta 1 Thread near EOL so off topic keeps us interested and trying different ways to stay active

posted ALT link in p#75 - looks like .rst got dropped?

That solution seems to be non Windows specific which is COOL ... at least for 'those' people

The TSET is cool cause I can hack and edit it.

PaulStoffregen · Sep 10, 2022

Some of the compile errors (not merely warnings) found by the perl script are related to time_t not defined. I'm debating what to do about it....

Turns out some Arduino boards define time_t by default, but others don't. Some boards also define the time() function by including time.h by default.

Code:

                time_t  time()

Teensy 2.0      no      no
Arduino Uno     no      no
Nano Every      no      no
Teensy LC/3/4   yes     no
Arduino Zero    yes     no
ESP32           yes     yes
ESP8266         yes     yes
Arduino Due     yes     yes, but no _gettimeofday
Nano RP2042     yes     yes
RaspPi Pico     yes     yes
Portenta H7     yes     yes
Nano 33 BLE     yes     yes

I'm leaning towards including time.h, since many of the other 32 bit boards are including it. But this change will break certain programs where people have named a global scope variable "time", like this Snooze library example.

The alternative is to find a way to define only time_t with the new toolchain.

Here are the 2 test programs.

Code:

// Does Arduino.h define time_t

time_t count = 0;

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

void loop() {
  Serial.println(count++);
  delay(250);
}

Code:

// Does Arduino.h define time(void *)

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

void loop() {
  Serial.println(time(NULL));
  delay(250);
}

PaulStoffregen · Sep 10, 2022

I committed include of time.h, at least for testing with 1.58-beta2.

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

If this causes too many programs to break or other problems, it may get removed and replaced with some way to define only time_t as the old toolchain did.

thebigg · Sep 10, 2022

Also be aware that the size of time_t has been changed from int32_t to int64_t in recent gcc releases to cater for the "Year 2038 Problem"

PaulStoffregen · Sep 11, 2022

Yup, looks like time_t is 64 bits with the new toolchain.

Code:

void setup() {
  Serial.begin(9600);
  Serial.print("sizeof(time_t) = ");
  Serial.println(sizeof(time_t));
}

void loop() {
}

So far I haven't seen it cause any problems, but this is certainly a difference to keep in mind.

PaulStoffregen · Sep 11, 2022

KurtE said:
SO suppose I add this to MTP_teensy.h

Code:

#if defined(__has_include) && __has_include(<SD.h>) #include <SD.h> #endif

.....as such Arduino does not include the SD library into the search path... ... I earlier raised with Arduino. They informed me that it is a GCC issue...

I wouldn't call this a gcc issue. It's a consequence of the way Arduino automatically discovers which libraries are used. The library search path list is created on-the-fly based on which files have been included.

You probably want __has_include to resolve whether SD.h could be included, from the set of all possible libraries Arduino might use. But with the way Arduino runs gcc, it only tells if you whether SD.h could be included from any of the (small) set of libraries it has found are needed based on includes in all files. You can't expect gcc to know about any other locations it wasn't giving when Arduino ran it.

But this is probably a lot of focusing on trees rather than the forest. I'm pretty sure the real problem is we don't yet have enough functionality in FS.h. Adding this is high on my priority list for 1.58.

PaulStoffregen · Sep 11, 2022

KurtE said:
Paul (or others) have you looked at the addr2line issue:

Sadly, no, not yet. Have been going through compile errors.

KurtE · Sep 11, 2022

Again, I know that this is somewhat off topic, but was curious if the behavior changed with this toolchain

PaulStoffregen said:
I wouldn't call this a gcc issue. It's a consequence of the way Arduino automatically discovers which libraries are used. The library search path list is created on-the-fly based on which files have been included.

You probably want __has_include to resolve whether SD.h could be included, from the set of all possible libraries Arduino might use. But with the way Arduino runs gcc, it only tells if you whether SD.h could be included from any of the (small) set of libraries it has found are needed based on includes in all files. You can't expect gcc to know about any other locations it wasn't giving when Arduino ran it.

But this is probably a lot of focusing on trees rather than the forest. I'm pretty sure the real problem is we don't yet have enough functionality in FS.h. Adding this is high on my priority list for 1.58.

Note this issue is not just related to the SD files and the like issues.

But more generic. I ran into this with several different usage patterns. Like, use JPGDEC library if installed, or use my Hex Dump library if installed.

More information about it up on the Arduino Issue I created a while ago that has been closed.
https://github.com/arduino/arduino-cli/issues/1782
which they pointed to the open issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753

But as you said, in this specific case, there are probably better solutions, that allows code that is called with a FS pointer or File pointer to be able to understand more about the object passed in. Sort of like when I am running a program on an RPI, that is passed in an object to Serially input or output to, I may need/want to know what type of object it is. For example, to minimize latency, I may want to know that it is an
FTDI object, in which case I want to call the TCDRAIN function. But if it is not an FTDI object TCDRAIN can be very detrimental.

Now back to playing.

PaulStoffregen · Jan 14, 2023

Kurt, could you remind me what's wrong with addr2line?

KurtE said:
addr2line from this toolchain gives wrong information:

I tried a few quick tests on Linux. Seems to work fine. Maybe it's only on Windows?

Can you suggest a test case?

PaulStoffregen · Jan 14, 2023

KurtE said:

addr2line from this toolchain gives wrong information:
....
EDIT: Just had another one, different sketch:

Code:

C:\Users\kurte\AppData\Local\Temp\arduino-sketch-E3CDFA778F47585FDF08194635A9E9C9>addr2line -e keyboard_viewer.ino.elf 0x108E4
??:?

Code:

000108c0 <strlen>:
   108c0:	f890 f000 	pld	[r0]
   108c4:	e96d 4502 	strd	r4, r5, [sp, #-8]!
   108c8:	f020 0107 	bic.w	r1, r0, #7
   108cc:	f06f 0c00 	mvn.w	ip, #0
   108d0:	f010 0407 	ands.w	r4, r0, #7
   108d4:	f891 f020 	pld	[r1, #32]
   108d8:	f040 8049 	bne.w	1096e <strlen+0xae>
   108dc:	f04f 0400 	mov.w	r4, #0
   108e0:	f06f 0007 	mvn.w	r0, #7
 [COLOR="#FF0000"]  108e4:	e9d1 2300 	ldrd	r2, r3, [r1][/COLOR]
   108e8:	f891 f040 	pld	[r1, #64]	; 0x40
   108ec:	f100 0008 	add.w	r0, r0, #8

Are you sure this was really wrong information? It looks like the sort of error expected if something called strlen() with a null pointer.

This got me to looking at places where we use strlen(). By far the commonly called case is in Print.h, though in most circumstances the compiler knows the string length. Still, if Serial.print() or any library that inherits Print class, like displays, were to try printing a null pointer, we would print a small amount of garbage on Teensy 3 but trigger a memory fault on Teensy 4. After some testing to make sure it doesn't add anything compiled in the common string constant case, I committed a nullptr check to the Print class.

https://github.com/PaulStoffregen/cores/commit/7243438117f858e234f95f885485dc5f327ad742

Not sure if this will really solve any current problems, but it adds no compiled code in the common string constant case.

KurtE · Jan 15, 2023

PaulStoffregen said:
Kurt, could you remind me what's wrong with addr2line?

I tried a few quick tests on Linux. Seems to work fine. Maybe it's only on Windows?

Can you suggest a test case?

We had some cases working in USBHost where dealing with NULLPTR. ...

Not sure if this shows similar or not:

Code:

#include <ILI9341_t3.h>
ILI9341_t3 *ptft = nullptr;
void setup() {
  if (CrashReport) {
    while (!Serial && millis() < 4000);
    Serial.print(CrashReport);
    Serial.print("Paused, hit any key to continue");
    while (Serial.read() == -1) ;
    while (Serial.read() != -1) ;
  }
  Serial.println("Probably go boom");
  ptft->begin();
}

void loop() {
  
}

Here is a crash report:

Code:

CrashReport:
  A problem occurred at (system time) 5:41:49
[COLOR="#FF0000"]  Code was executing from address 0x27C[/COLOR]
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x55206EF3
  Temperature inside the chip was 28.21 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
  Breadcrumb #1 was 1954268917 (0x747BC6F5)
  Breadcrumb #5 was 1676069787 (0x63E6CB9B)
  Breadcrumb #6 was 3160958208 (0xBC686500)
Paused, hit any key to continue

Code:

C:\Users\kurte\AppData\Local\Temp\arduino-sketch-DECE862A8C38F65BC2E4A75893A1637E>dir
 Directory of C:\Users\kurte\AppData\Local\Temp\arduino-sketch-DECE862A8C38F65BC2E4A75893A1637E
...
01/15/2023  05:41 AM                34 zzz.ino.eep
01/15/2023  05:41 AM            87,301 zzz.ino.ehex
01/15/2023  05:41 AM           916,492 zzz.ino.elf
01/15/2023  05:41 AM            86,477 zzz.ino.hex
01/15/2023  05:41 AM           382,888 zzz.ino.lst
01/15/2023  05:41 AM            15,915 zzz.ino.sym
              10 File(s)      1,500,375 bytes
               7 Dir(s)  134,984,286,208 bytes free

C:\Users\kurte\AppData\Local\Temp\arduino-sketch-DECE862A8C38F65BC2E4A75893A1637E>addr2line
addr2line: 'a.out': No such file

[COLOR="#FF0000"]C:\Users\kurte\AppData\Local\Temp\arduino-sketch-DECE862A8C38F65BC2E4A75893A1637E>addr2line -e zzz.ino.elf 0x27c
C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\0.58.3\libraries\ILI9341_t3/ILI9341_t3.h:359
[/COLOR]
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-DECE862A8C38F65BC2E4A75893A1637E>subl *.lst

Line 359 in header file:

Code:

	void waitFifoNotFull(void) {
    	uint32_t tmp __attribute__((unused));
    	do {
        	if ((IMXRT_LPSPI4_S.RSR & LPSPI_RSR_RXEMPTY) == 0)  {
            	tmp = IMXRT_LPSPI4_S.RDR;  // Read any pending RX bytes in
   [COLOR="#FF0000"]         	if (_pending_rx_count) _pending_rx_count--; //decrement count of bytes still levt[/COLOR]
        	}
    	} while ((IMXRT_LPSPI4_S.SR & LPSPI_SR_TDF) == 0) ;

On the RED line.

From the LST file:

Code:

00000248 <ILI9341_t3::begin()>:
		*(portControlRegister(hardware->tx_pins[tx_pin_index_].pin)) =  IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) 
     248:	e92d 4ff0 	stmdb	sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
     24c:	b085      	sub	sp, #20
     24e:	4604      	mov	r4, r0
     250:	2300      	movs	r3, #0
     252:	f880 3038 	strb.w	r3, [r0, #56]	; 0x38
     256:	4d98      	ldr	r5, [pc, #608]	; (4b8 <ILI9341_t3::begin()+0x270>)
     258:	4628      	mov	r0, r5
     25a:	f000 fbcb 	bl	9f4 <SPIClass::begin()>
     25e:	f894 0021 	ldrb.w	r0, [r4, #33]	; 0x21
		*(portConfigRegister(hardware->tx_pins[tx_pin_index_].pin)) = hardware->tx_pins[tx_pin_index_].mux_val;
     262:	4b96      	ldr	r3, [pc, #600]	; (4bc <ILI9341_t3::begin()+0x274>)
     264:	0101      	lsls	r1, r0, #4
     266:	eb03 1200 	add.w	r2, r3, r0, lsl #4
     26a:	585b      	ldr	r3, [r3, r1]
     26c:	62e3      	str	r3, [r4, #44]	; 0x2c
     26e:	68d3      	ldr	r3, [r2, #12]
     270:	62a3      	str	r3, [r4, #40]	; 0x28
     272:	2101      	movs	r1, #1
     274:	f001 f86e 	bl	1354 <pinMode>
	if (format & 0x04) ctrl |= LPUART_CTRL_M;		// 9 bits (might include parity)
     278:	6ae3      	ldr	r3, [r4, #44]	; 0x2c
     27a:	6aa2      	ldr	r2, [r4, #40]	; 0x28
  [COLOR="#FF0000"] [B]  27c:	f8c3 2084 	str.w	r2, [r3, #132]	; 0x84[/B][/COLOR]
	if (!(*hardware->serial_event_handler_default)) addToSerialEventsList(); 		// Enable the processing of serialEvent for this object
     280:	4b8f      	ldr	r3, [pc, #572]	; (4c0 <ILI9341_t3::begin()+0x278>)
};

PaulStoffregen · Jan 15, 2023

If you see this problem again, could you save the .elf file and crash report text?

Teensyduino 1.58 Beta #1 (updated toolchain trial)

PaulStoffregen

Well-known member

defragster

Senior Member+

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member

thebigg

Well-known member

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member

KurtE

Senior Member+

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member

KurtE

Senior Member+

PaulStoffregen

Well-known member