Teensy 4.1 Beta Test

I tend to use something like this
Code: 
#define HOT FASTRUN    __attribute__((hot))
#define COLD FLASHMEM  __attribute__((cold))

and then write

Code: 
HOT void blah_this_must_be_fast(void) { ..  }
or
COLD void some_stuff_for_init_only_or_not_critical(void) { ..  }
 
Experiments With Soldering Memory Chips To Teensy 4.1 Board

@All - Teensy 4.1 Arduino 1.8.12 TD 1.52.

Just made an attempt at soldering PSRAM chip to one of my T4.1 boards. 2 hours later I think I have it done without error (I hope). Tried using tape to hold the PSRAM chip to the T4.1. Was not working well for me. Then I thought why not use a dab of silicone sealer to hold it to the board. Nah, had to wait for it to setup. Then I thought what I need is a clamp. A small clamp to hold the chip in place to the board. I saw that big paper clip. Yes, that could be formed into clamp using needle nose pliers. That is what I did. After tinning the pads on the T4.1 I clamped and centered the PSRAM chip to the T4.1 and tacked two apposing PSRAM pins to the board. Then I finished soldering the rest of the pins.

I really am not sure of the best way to test for functionality now. I tried testing the PSRAM chip with 'teensy4.1_psram_memtest.ino' and got this:
Code: 
EXTMEM Memory Test, 0 Mbyte
With a fast blinking LED:(

Then I tried 'teensy41_extram.ino' and got this response:
Code: 
External RAM test
hardware initialized
ID: 0D 5D 52 A1 A8 58 DC 9A
read @000000:  55 55 55 55 55 55 54 75 55 55 55 55 54 55 55 55 41 75 55 45 55 45 51 55
rd @70000000:  55 55 55 55 55 55 54 75 55 55 55 55 54 55 55 55 41 75 55 45 55 45 51 55
write @000000: 48 65 6C 6C 6F 20 57 6F 72 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00
read @000000:  48 65 6C 6C 6F 20 57 6F 72 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00
rd @70000000:  48 65 6C 6C 6F 20 57 6F 72 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00
read @000000:  48 65 6C 6C 6F 20 57 6F 72 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00
rd @70000000:  48 65 6C 6C 6F 20 57 6F 72 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00
write @000000: 54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00
read @000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00
rd @70000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00
read @000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EA 00 00 00 00 00 00
rd @70000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EA 00 00 00 00 00 00
read @000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EB 00 00 00 00 00 00
rd @70000000:  54 65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EB 00 00 00 00 00 00
read @000001:  65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EB 00 00 00 00 00 00 55
rd @70000001:  65 73 74 20 31 32 33 20 54 65 73 74 00 00 00 00 EB 00 00 00 00 00 00 55
ID: FF FF FF

I also had this compiler message:
Code: 
teensy41_extram: In function 'void setup()':
/home/wwatson/Arduino/teensy41_extram/teensy41_extram.ino:157:27: warning: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'char*' [-fpermissive]
  strcpy(buf, "Hello World");
                           ^
In file included from /home/wwatson/arduino-1.8.12/hardware/tools/arm/arm-none-eabi/include/stdlib.h:11:0,
                 from /home/wwatson/arduino-1.8.12/hardware/teensy/avr/cores/teensy4/WProgram.h:34,
                 from /tmp/arduino_build_565606/pch/Arduino.h:6:
/home/wwatson/arduino-1.8.12/hardware/tools/arm/arm-none-eabi/include/string.h:34:8: note:   initializing argument 1 of 'char* strcpy(char*, const char*)'
 char  *_EXFUN(strcpy,(char *__restrict, const char *__restrict));
        ^
/home/wwatson/Arduino/teensy41_extram/teensy41_extram.ino:163:29: warning: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'char*' [-fpermissive]
  strcpy(buf, "Test 123 Test");
                             ^
In file included from /home/wwatson/arduino-1.8.12/hardware/tools/arm/arm-none-eabi/include/stdlib.h:11:0,
                 from /home/wwatson/arduino-1.8.12/hardware/teensy/avr/cores/teensy4/WProgram.h:34,
                 from /tmp/arduino_build_565606/pch/Arduino.h:6:
/home/wwatson/arduino-1.8.12/hardware/tools/arm/arm-none-eabi/include/string.h:34:8: note:   initializing argument 1 of 'char* strcpy(char*, const char*)'
 char  *_EXFUN(strcpy,(char *__restrict, const char *__restrict));
        ^

I guess I am not sure if I killed the chip or if it is actually working:)
 
Last edited:
Is that the sketch from : Teensy-4-1-Beta-Test that post Paul posted 5/13?
>> github.com/PaulStoffregen/teensy41_psram_memtest/blob/master/teensy41_psram_memtest.ino

If so it would start like:
Code: 
EXTMEM Memory Test, 16 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
testing with pseudo-random sequence, seed=1438200953

or:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124

or:
Code: 
EXTMEM Memory Test, 0 Mbyte

Depending on the size of PSRAM recognized.
It will give good feedback if soldered and working right.
 
Plans for T4.1 Ethernet library

I was wondering what are the plans for the software support of the native T4.1 Ethernet. Will the https://github.com/PaulStoffregen/teensy41_ethernet be extended upon towards Arduino Ethernet library compatibility, will the Arduino Ethernet library be enriched with native T4.1 Ethernet support, or will the focus be on lwip supporting the T4.1?

Kind regards,
Sebastian
 
wangnick said:
Plans for T4.1 Ethernet library

I was wondering what are the plans for the software support of the native T4.1 Ethernet. Will the https://github.com/PaulStoffregen/teensy41_ethernet be extended upon towards Arduino Ethernet library compatibility, will the Arduino Ethernet library be enriched with native T4.1 Ethernet support, or will the focus be on lwip supporting the T4.1?

Kind regards,
Sebastian
Click to expand...

Not sure where it will be in the end with regard to PJRC - but there is this thread: T4-1-Ethernet-Library that has current details.
 
WMXZ said:
My beta board has yesterday reached Italy. still waiting.
Meanwhile, I ordered some T4.1 from Exp-Tech.de, arrived via USP in no time. (No custom issue within Europe)
Click to expand...

For the record, my beta-board arrived today (25-may-2020).
 
defragster said:
Is that the sketch from : Teensy-4-1-Beta-Test that post Paul posted 5/13?
>> github.com/PaulStoffregen/teensy41_psram_memtest/blob/master/teensy41_psram_memtest.ino

If so it would start like:
Code: 
EXTMEM Memory Test, 16 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
testing with pseudo-random sequence, seed=1438200953

or:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124

or:
Code: 
[COLOR="#FF0000"]EXTMEM Memory Test, 0 Mbyte[/COLOR]

Depending on the size of PSRAM recognized.
It will give good feedback if soldered and working right.
Click to expand...

Unfortunately it appears to not be working. I guess I will have to pop that chip off and try again. I will check the solder connections again with my magnifying glass first. I did check for shorts between pins but detected none.

Thanks for the link.
 
@wwatson, did you solder it in to where the smaller pattern is on the back of the board? (around pads 31-32?)

You might, retouch each solder joint with solder iron to make sure good contacts, and check for any shorts...

Also at times like this, I use the hilow test sketch that @defragster and I hacked on awhile ago to see if all of the IO pins appear to work.
I think one of t last places that sketch was posted was up at: https://forum.pjrc.com/threads/3875...-(ILI9341_t3n)?p=226808&viewfull=1#post226808

And several places have documented what each of the pins on these patterns are. Including my excel document:
Code: 
FLASH or 2nd RAM
4.26		1:12					RX1		P	52			GND											
4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
									3.3V			(pin 1)	51	P					SCL1				4.22	EMC_22
		
RAM																						
4.26		1:12					RX1		P	52			GND											
4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
									3.3V			(pin 1)	48	P		RX8							4.24	EMC_24
Pardon the spacing of quick copy/paste
 
KurtE said:
@wwatson, did you solder it in to where the smaller pattern is on the back of the board? (around pads 31-32?)

You might, retouch each solder joint with solder iron to make sure good contacts, and check for any shorts...

Also at times like this, I use the hilow test sketch that @defragster and I hacked on awhile ago to see if all of the IO pins appear to work.
I think one of t last places that sketch was posted was up at: https://forum.pjrc.com/threads/3875...-(ILI9341_t3n)?p=226808&viewfull=1#post226808

And several places have documented what each of the pins on these patterns are. Including my excel document:
Code: 
FLASH or 2nd RAM
4.26		1:12					RX1		P	52			GND											
4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
									3.3V			(pin 1)	51	P					SCL1				4.22	EMC_22
		
RAM																						
4.26		1:12					RX1		P	52			GND											
4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
									3.3V			(pin 1)	48	P		RX8							4.24	EMC_24
Pardon the spacing of quick copy/paste
Click to expand...

@All - I have the PSRAM chip working. It wasn't my soldering or a ruined chip:)

I could not figure out why the one sketch 'teensy41_extram.ino' appeared to be working and 'teensy4.1_psram_memtest.ino' was not. So I started with comparing the configuration of the psram chip in both 'teensy41_extram.ino':
Code: 
	// reset the chip
	flexspi_ip_command(0, 0);
	flexspi_ip_command(1, 0);
	flexspi_ip_command(2, 0);
	[COLOR="#FF0000"]delayMicroseconds(50);[/COLOR]

and in 'startup.c':
Code: 
	// look for the first PSRAM chip
	flexspi2_command(0, 0); // exit quad mode
	flexspi2_command(1, 0); // reset enable
	flexspi2_command(2, 0); // reset (is this really necessary?)
	if (flexspi2_psram_id(0) == 0x5D0D) {
		// first PSRAM chip is present, look for a second PSRAM chip
		flexspi2_command(4, 0);
		flexspi2_command(0, 0x800000); // exit quad mode
		flexspi2_command(1, 0x800000); // reset enable
		flexspi2_command(2, 0x800000); // reset (is this really necessary?)
		if (flexspi2_psram_id(0x800000) == 0x5D0D) {
			flexspi2_command(4, 0x800000);
			// Two PSRAM chips are present, 16 MByte
			external_psram_size = 16;
		} else {
			// One PSRAM chip is present, 8 MByte
			external_psram_size = 8;
		}
		// TODO: zero uninitialized EXTMEM variables
		// TODO: copy from flash to initialize EXTMEM variables
		// TODO: set up for malloc_extmem()
	} else {
		// No PSRAM
	}

The reason one sketch worked and the other did not was this:
Code: 
[COLOR="#FF0000"]delayMicroseconds(50);[/COLOR]

So I added that delay after the reset code:
Code: 
	// look for the first PSRAM chip
	flexspi2_command(0, 0); // exit quad mode
	flexspi2_command(1, 0); // reset enable
	flexspi2_command(2, 0); // reset (is this really necessary?)
delayMicroseconds(50);
	if (flexspi2_psram_id(0) == 0x5D0D) {
		// first PSRAM chip is present, look for a second PSRAM chip
		flexspi2_command(4, 0);
		flexspi2_command(0, 0x800000); // exit quad mode
		flexspi2_command(1, 0x800000); // reset enable
		flexspi2_command(2, 0x800000); // reset (is this really necessary?)
		if (flexspi2_psram_id(0x800000) == 0x5D0D) {
delayMicroseconds(50);
			flexspi2_command(4, 0x800000);
			// Two PSRAM chips are present, 16 MByte
			external_psram_size = 16;
		} else {
			// One PSRAM chip is present, 8 MByte
			external_psram_size = 8;
		}
		// TODO: zero uninitialized EXTMEM variables
		// TODO: copy from flash to initialize EXTMEM variables
		// TODO: set up for malloc_extmem()
	} else {
		// No PSRAM
	}

And the result was this:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
testing with pseudo-random sequence, seed=1438200953
testing with pseudo-random sequence, seed=3413783263
...
testing with fixed pattern 55555555
testing with fixed pattern 33333333
testing with fixed pattern 0F0F0F0F
testing with fixed pattern 00FF00FF
testing with fixed pattern 0000FFFF
testing with fixed pattern AAAAAAAA
testing with fixed pattern CCCCCCCC
testing with fixed pattern F0F0F0F0
testing with fixed pattern FF00FF00
testing with fixed pattern FFFF0000
testing with fixed pattern FFFFFFFF
testing with fixed pattern 00000000
 test ran for 35.50 seconds
All memory tests passed :-)

What confuses me is why nobody else seemed to have this problem. Anyway for me, problem solved:)
 
Frank B said:
This is the output for T4.1:
Code: 
PIN   GPIOn-BITm  |  GPIOn-BITm    PIN

------------------|-------------------

00  -> GPIO6-03   |   GIPO6-02  ->  01
01  -> GPIO6-02   |   GIPO6-03  ->  00
02  -> GPIO9-04   |   GIPO6-12  ->  24
03  -> GPIO9-05   |   GIPO6-13  ->  25
04  -> GPIO9-06   |   GIPO6-16  ->  19
05  -> GPIO9-08   |   GIPO6-17  ->  18
06  -> GPIO7-10   |   GIPO6-18  ->  14
07  -> GPIO7-17   |   GIPO6-19  ->  15
08  -> GPIO7-16   |   GIPO6-20  ->  40
09  -> GPIO7-11   |   GIPO6-21  ->  41
10  -> GPIO7-00   |   GIPO6-22  ->  17
11  -> GPIO7-02   |   GIPO6-23  ->  16
12  -> GPIO7-01   |   GIPO6-24  ->  22
13  -> GPIO7-03   |   GIPO6-25  ->  23
14  -> GPIO6-18   |   GIPO6-26  ->  20
15  -> GPIO6-19   |   GIPO6-27  ->  21
16  -> GPIO6-23   |   GIPO6-28  ->  38
17  -> GPIO6-22   |   GIPO6-29  ->  39
18  -> GPIO6-17   |   GIPO6-30  ->  26
19  -> GPIO6-16   |   GIPO6-31  ->  27
20  -> GPIO6-26   |   GIPO7-00  ->  10
21  -> GPIO6-27   |   GIPO7-01  ->  12
22  -> GPIO6-24   |   GIPO7-02  ->  11
23  -> GPIO6-25   |   GIPO7-03  ->  13
24  -> GPIO6-12   |   GIPO7-10  ->  06
25  -> GPIO6-13   |   GIPO7-11  ->  09
26  -> GPIO6-30   |   GIPO7-12  ->  32
27  -> GPIO6-31   |   GIPO7-16  ->  08
28  -> GPIO8-18   |   GIPO7-17  ->  07
29  -> GPIO9-31   |   GIPO7-18  ->  36
30  -> GPIO8-23   |   GIPO7-19  ->  37
31  -> GPIO8-22   |   GIPO7-28  ->  35
32  -> GPIO7-12   |   GIPO7-29  ->  34
33  -> GPIO9-07   |   GIPO8-12  ->  45
34  -> GPIO7-29   |   GIPO8-13  ->  44
35  -> GPIO7-28   |   GIPO8-14  ->  43
36  -> GPIO7-18   |   GIPO8-15  ->  42
37  -> GPIO7-19   |   GIPO8-16  ->  47
38  -> GPIO6-28   |   GIPO8-17  ->  46
39  -> GPIO6-29   |   GIPO8-18  ->  28
40  -> GPIO6-20   |   GIPO8-22  ->  31
41  -> GPIO6-21   |   GIPO8-23  ->  30
42  -> GPIO8-15   |   GIPO9-04  ->  02
43  -> GPIO8-14   |   GIPO9-05  ->  03
44  -> GPIO8-13   |   GIPO9-06  ->  04
45  -> GPIO8-12   |   GIPO9-07  ->  33
46  -> GPIO8-17   |   GIPO9-08  ->  05
47  -> GPIO8-16   |   GIPO9-22  ->  51
48  -> GPIO9-24   |   GIPO9-24  ->  48
49  -> GPIO9-27   |   GIPO9-25  ->  53
50  -> GPIO9-28   |   GIPO9-26  ->  52
51  -> GPIO9-22   |   GIPO9-27  ->  49
52  -> GPIO9-26   |   GIPO9-28  ->  50
53  -> GPIO9-25   |   GIPO9-29  ->  54
54  -> GPIO9-29   |   GIPO9-31  ->  29
Click to expand...

Thank you for this!
 
i also got a lot of help from Frank's post. I'm still learning and that's all much appreciated. may i ask you some other questions in the future? thanks again
 
I had teething problems with getting 4.1 to work. The issue was vmware grabbing the new USB id but arduino still partially seeing it. And maybe a udev update issue. Suggestion - a better error message than just "tcgetattr error" when the USB device isn't available. And maybe a note at about udev reload-rules and trigger in the linux installation instructions.
 
Yes there are 30 GPIO pins that i can count, that is not routed from the MCU.
PaulStoffregen said:
The PCB is completely filled with routing on all 4 non-plane layers, and even a few signals escape along the edges of the ground plane layer. It just wasn't possible to escape any more signals to the right hand side of the PCB.
Click to expand...

You could widen the PCB and stack the pins, this way it's also compatible with the old layout.
teensy41_4.jpg
Some extra GND pins could be very nice, specially if you think about high speed signals that need short GND distance.
 
manicksan said:
Yes there are 30 GPIO pins that i can count, that is not routed from the MCU.
...
Click to expand...

That note from Paul refers to usable space between the MCU pads on the underside of the chip where " It just wasn't possible to escape any more signals " ... without going to a more complex PCB build perhaps.

You'll note the T_4.0 MCU is smaller than the T_4.1 MCU - only using that larger part was it possible to get the extra dozen++ pins to feed/escape for added :: QSPI pads, Ethernet chip, Edge pins to complete the T_4.1 as shipped.
 
manicksan said:
Yes there are 30 GPIO pins that i can count, that is not routed from the MCU.


You could widen the PCB and stack the pins, this way it's also compatible with the old layout.
View attachment 20587
Some extra GND pins could be very nice, specially if you think about high speed signals that need short GND distance.
Click to expand...
As you probably already know, the T4.1 has already shipped, so very unlikely anything will change.

There are always trade offs here. For example adding that extra two rows of pins would any many cases not allow me to use the board with my current layouts of other boards.

But it will be interesting to see what layout Paul comes up with for the next board. You may want to make your comments and suggestions on one of the threads, such as:
https://forum.pjrc.com/threads/60837-Future-Teensies!?p=238827&viewfull=1#post238827
 
OK this is going to sound like a silly question at this point in time but my memory is failing me, where is the trace I have to cut to separate Vin from USB if i want to use external power?
InkedTeensy-4.1-1 (1)_LI.jpg

Is it at 1 going from Vusb to the big pads or 2 between the 2 big pads?
 
KurtE said:
The one I cut is between the two big pads in your redish/orangish colors...
Click to expand...
Yeah - just got my coffee and decided to look on the back of the T4.0 card and sure enough. Thats what I get for using your spreadsheet all the time :)
 
mjs513 said:
OK this is going to sound like a silly question at this point in time but my memory is failing me, where is the trace I have to cut to separate Vin from USB if i want to use external power?
Click to expand...
Technically you only need to do it if you plan to plug in a USB cable and provide external power at the same time. If you only provide one power source, then you don't need to cut the solder pads.
 
MichaelMeissner said:
Technically you only need to do it if you plan to plug in a USB cable and provide external power at the same time. If you only provide one power source, then you don't need to cut the solder pads.
Click to expand...

Thanks Michael. You are absolutely right except in the use case I am looking at on rover I will have primary power source when the rover is running around the house and the secondary is when i am doing testing where i would have usb plug in for debugging while still powering the rover.

Most of the time i don't bother cutting the trace :)

The one good thing that this did is that I am having a problem with the front panel USB on my PC - not putting out 5v's. Just ordered another one.
 
@All - just to let you know I touched up the soldering job on the extram chips on the one T4.1 board that I was having a problem with. That fixed the the issue I was having with having to add delay's to the config portion of startup.c.

Instead of using these:
il_794xN.1949485267_19y0.jpg

I used a new solder station I bought and had a beer:)
You guy's were right about the soldering job I did. The T4.1 is showing 16MB's of extram using @paul's test sketch without the delays.
What I don't understand is why the actual memtest portion still worked without the delay when the solder connections were feeble:confused:

Thanks for the push.
 
wwatson said:
@All - just to let you know I touched up the soldering job on the extram chips on the one T4.1 board that I was having a problem with. That fixed the the issue I was having with having to add delay's to the config portion of startup.c.
...
You guy's were right about the soldering job I did. The T4.1 is showing 16MB's of extram using @paul's test sketch without the delays.
What I don't understand is why the actual memtest portion still worked without the delay when the solder connections were feeble:confused:

Thanks for the push.
Click to expand...

Awesome - glad that worked! The old irons seem to have lost their cords - good they got replaced :)

On startup the chip uses SPI to be recognized and then gets dropped into QSPI mode to run.

Just guessing the pin that was weak or dirty/shorted with flux for the initial timing detection/setup is one getting some alternate usage for QSPI - or maybe after the chip is awake more than a few ms and polished off the first mA or so it is ready for business?
 
defragster said:
... " The old irons seem to have lost their cords - good they got replaced :) "

Those Irons are so old they pre-date electrically powered irons - they never had cords!
They used to be heated in a pan full of Sand over a gas stove between uses, and that same hot sand was used to scrub the "Tips" (heh) between uses, and then left in the pan to cool off between soldering household wiring, and very vintage radio circuitry between nails&screws driven into actual "Bread Boards".
(My 70+ mentor taught me this)
Click to expand...
 
wwatson said:
@All - just to let you know I touched up the soldering job on the extram chips on the one T4.1 board that I was having a problem with. That fixed the the issue I was having with having to add delay's to the config portion of startup.c.

Instead of using these:
...

You guy's were right about the soldering job I did. The T4.1 is showing 16MB's of extram using @paul's test sketch without the delays.
What I don't understand is why the actual memtest portion still worked without the delay when the solder connections were feeble:confused:

Thanks for the push.
Click to expand...

@KurtE - just came back here to read the posting below - wonder if this is what is bugging the T_4.x remote memory PCB? The solder is there but 'iffy'?

joetee said:
defragster said:
... " The old irons seem to have lost their cords - good they got replaced :) "

Those Irons are so old they pre-date electrically powered irons - they never had cords!
...
Click to expand...

Odd the icon hover 'text' says "Thumbs Up" - but seeing the image as a thumbs down ... and of course the lack of cords on those obviously 'externally heated' irons was noted with a :)
Click to expand...
 
You must log in or register to reply here.
Back
Top