Teensy 4.0 First Beta Test

Status
Not open for further replies.
Change to make CoreMark not Fault when ITERATIONS causes run time over 10 secs:

T:\tCode\T4\teensy4_coremark\core_portme.c ::
Code: 
secs_ret time_in_secs(CORE_TICKS ticks) {
	secs_ret retval=ticks / 1000;
	return retval;
}

Doesn't return the right answer for the displayed info - but stops the fault. The line changed was :: secs_ret retval=((secs_ret)ticks) / (secs_ret)EE_TICKS_PER_SEC;

When value here takes over 10 secs to run :: "T:\tCode\T4\teensy4_coremark\core_portme.c" : #define ITERATIONS 24000

Without edit fault comes from :: T:\tCode\T4\teensy4_coremark\core_main.c : line 328
Code: 
			ee_printf("CoreMark 1.0 : %f / %s %s",[U]default_num_contexts*results[0].iterations/time_in_secs(total_time)[/U],COMPILER_VERSION,COMPILER_FLAGS);
 
Last edited:
defragster said:
Fresh post follow up - it seems to be working - but I have to push button now?

Manitou - did you run Set_Arm_Clock on your T4?
Click to expand...

I only modified MHz with Set_Arm_Clock() in startup.c for coremark timings at different mhz.
(I'm wondering if my latest problem on my desktop (32-bit linux) might be related to exhausting some USB table. I need to reboot, but I don't really want to push my luck with my temperamental T4, so i may delay the reboot test...) I still have to push the program button, but T4 is otherwise working my 64-bit linux box.

edit: i did reboot my 32-bit desktop, and for now T4 is working (still have to push program button after upload)
 
Last edited:
Not sure if this is related to some of these issues.

But once yesterday, I had the Arduino IDE (1.8.8 and beta7) Not able to program the T4, nor talk to it. In fact when I tried to compile it said no Teensy Found, likewise pushing program button did not work. When I looked that the Tools/Port menu it did not show any Teensy stuff in it, Nor the port associated with the Teensy.

All I did was to close down the Arduino IDE and the Teensy App, and restarted it, and it then showed the Teensy 4 (in I believe the waiting to program state). I then compiled and downloaded sketch and it worked just fine.

Again not sure if this is the same issue that some of you have seen as well, or just some fluke?
 
I did a quick and dirty update of the avr_emulation.h file to add in the SPI registers. Note: So far I only have done a real minor part of it.
In particular:
SPCR - nothing done, all code simply commented out
SPSR - Only the SPIF flag is returned.
SPDR - I do write to it (LPSPI4_TDR) and read from it (LPSPI4_RDR)

With this at least on my machine the Adafruit_ili9341 library graphic test compiles and runs. I don't think so but may rely on my SPI library changes as well...

Anyway checked this in on my other cores SPI PR (https://github.com/PaulStoffregen/cores/pull/320) that defined SPI structure

And my SPI changes are in the SPI PR (https://github.com/PaulStoffregen/SPI/pull/38)
 
RTC ticking

Here is a simple sketch to start up the RTC clocked by the 32khz crystal. Starts up LPSRTC. Needs a few symbols to be added to imrxt.h

https://github.com/manitou48/teensy4/blob/master/rtc.ino

Other things to be done: set/get time, start and sync HPRTC and test alarm, core set-time logic

SNVS_LPSRTCLR counts RTC ticks, so low order 15 bits gives sub-second values (32768/sec)


EDIT: VBAT tested. 3v3 to VBAT and gnd to gnd. RTC time keeps ticking after unplugging T4 and plugging back in.
 
Last edited:
KurtE : I can't hook up just now - but with that filler for avremulation.h I can now compile the SSD1306 for i2c!

~3 warnings for not return value where expected in func() and
T:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined

#define PROGMEM
Click to expand...

BTW: Prior combo sketch has IR_Recv incorporated in 4 port Serial test and IntervalTimer and the LCDcontrol - all running fine overnight.

<Edit>: @manitou> Added Rtc enable and sec print to Combo sketch - works here.
 
Last edited:
Thanks @defragster - I thought I handled the not return value ones... Will double check, probably

As for redefine PROGMEM, saw that as well, but not sure what to do as it is not something we changed... Probably could update Paul's version of the GFX library.
 
Have attached a 1306 I2C Display - works.

I don't have the progmem-warning (!?)

edit: No..found it.
 
Last edited:
Got the copper heatsink - looks great on the T4. For the beta-board, the size is perfect. I've not attached it so far. Sitting on the chip, it's above other components and does not touch them, even if I move the heatsink a bit over them. If it will be same for the production-T4 this heatsink would be OK, and PJRC should sell something like that as addon.
 
I had my PC sleeping (T4 removed from USB), and when I came back today, switched PC on, connected T4 - and I had to press the T4-button.
Well, then i've see there was a windows-update pending.
Rebooted.
After that everything was normal, no T4-button press needed (!?)
 
Frank B said:
I had my PC sleeping (T4 removed from USB), and when I came back today, switched PC on, connected T4 - and I had to press the T4-button.
Well, then i've see there was a windows-update pending.
Rebooted.
After that everything was normal, no T4-button press needed (!?)
Click to expand...

My machine took an update too : Win 10 1809.17763.253 was released 1/8/19. Not sure that relates to my troubles that were similar to whatever "I" did before - but it was in there.
My T4 and system are perfectly good and normal again [ DOZENS more uploads needing NO BUTTON ] - it may just be the current T4 USB stack <to be updated> interacting badly with Windows 10 when it comes and goes - in your case SLEEP - in my case power spasms?
> Given the way Windows does USB and Sleep - best to go into power settings and disable power save tricks like hybrid or whatever is under there.
> MSFT also added a new Startup speedup that is not cool - ShutDown does a hybrid Hibernate (my terms) where they store/restore some system state on shutdown. Results in unclean shutdown or unfresh Start. Under 'what power buttons do' have to 'enable things not available' and uncheck 'turn on fast startup' - odd obvious thing like powering up machine and it shows 14 days runtime in TaskMan.

Not sure about 'PROGMEM' - I don't think I have any custom files . . . maybe I did - KurtE saw it …

Will see if I get same heat sink size when mine arrives in coming days.

Glad you got ssd1306 working now! I have a couple work items to do then I can connect.
 
I've found my "progmem warning" :)
@Paul: I could not find the Adafruit GF library in your Github account.
Line 7 in glcdfont.c needs to be:
Code: 
#if defined(__AVR__) ||  defined(__IMXRT1052__) || defined(__IMRTX1062__)
or maybe defined(teensyduino) would be more clear and still work..

- Can't create a pull request.
 
__rtc_localtime

How/where is __rtc_localtime created? we could move the logic into the T4 build for setting RTC
 
XBEE Library
Been testing the XBEE library with the T4. Put the T4 in both Tx and Rx mode and used XCTU. Tested both with Series1 and Series 2 XBeeS. I have a Series1 Pro so it is a little better than regular S1's. Any tx16/rx16 both work with the T4 with the 2 sets of sketches. On the other hand when I tested Tx64 (this worked) and Rx64 it didn't seem to work. Again this is using Digi's XCTU app. Have another board coming so I can test the T4 to T3.x. It may be something with the way I am generating the frames. But I would say so far so good.
 
__rtc_localtime
Only place I found it with grepwin was in the makefile in the teensy3 directory:
Code: 
# linker options
LDFLAGS = -Os -Wl,--gc-sections,--defsym=__rtc_localtime=0 --specs=nano.specs -mcpu=$(CPUARCH) -mthumb -T$(MCU_LD)
 
manitou said:
__rtc_localtime

How/where is __rtc_localtime created? we could move the logic into the T4 build for setting RTC
Click to expand...


You can find it in boards.txt :
Code: 
teensy36.build.flags.ld=-Wl,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk66fx1m0.ld" -lstdc++
Seems that it is missing for T4 - shouldn't be a problem to just add it.
Edit: The builder fills it with the local time, I think.
 
Frank B said:
You can find it in boards.txt :
Code: 
teensy36.build.flags.ld=-Wl,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk66fx1m0.ld" -lstdc++
Seems that it is missing for T4 - shouldn't be a problem to just add it.
Edit: The builder fills it with the local time, I think.
Click to expand...

Thanks. I modified teensy4b.build.flags.ld in boards.txt and T4 can get build localtime
Code: 
extern void *__rtc_localtime; // Arduino build process sets this
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  while(!Serial);
  Serial.println("hello");
  Serial.println((uint32_t)&__rtc_localtime);
}

void loop() {
}
....
hello
1547053571
I'll add variable to my RTC sketch in post #656
 
Found an old program in a post: https://forum.pjrc.com/threads/2655...lloc-It-seems-to-just-keep-going-(Teensy-3-1)
Code: 
void* pointer;
uint32_t counter = 0;

void setup() {
  delay(1000);
}

void loop() {
  pointer = malloc(1);
  counter++;
  if (pointer == NULL) Serial.println("got null");
  else Serial.println(String(counter) + " allocations made");
}

Error:
C:\Arduino\hardware\teensy\avr\cores\teensy4/Print.cpp:177: undefined reference to `String::getBytes(unsigned char*, unsigned int, unsigned int) const'
 
manitou said:
How/where is __rtc_localtime created? we could move the logic into the T4 build for setting RTC
Click to expand...

This is going away. The replacement is one of many little things I meant to do before we started this beta, but didn't finish in time.

To answer the original question, the Arduino IDE creates this for us, so we can always get the compile time even if none of the core library files needed to be recompiled. It does into the final liner command.

For Teensy 4, I'm going to add a bootloader command to set the RTC, and add support in Teensy Loader to always do this as the final step. Then we won't need to depend on Arduino giving this special symbol, and non-Arduino build systems won't have to replicate this special feature. We can also get rid of the complicated startup code that tries to guess if the RTC setting is "fresh" vs "stale". It should also help solve the minor offset between Arduino running the linker and when the code finally boots up and sets the RTC.
 
Frank B said:
Found an old program in a post: https://forum.pjrc.com/threads/2655...lloc-It-seems-to-just-keep-going-(Teensy-3-1)
[/code][/COLOR]
Error:
C:\Arduino\hardware\teensy\avr\cores\teensy4/Print.cpp:177: undefined reference to `String::getBytes(unsigned char*, unsigned int, unsigned int) const'
Click to expand...

Is that because String isn't fixed yet?

I ran that and single non-free() bytes it ran for 16383 and quit - with edited print pair.

I changed to alloc(counter) bytes, and free(pointer) at loop end - looks like Max Alloc is > 258028
258028
allocations made
got null
Click to expand...

Adafruit SSD1306 is powered and running ... not integrated to combo sketch yet … 8-or-9 pins open [2,3,4,5,8, 13,(16),22,23] - where 16 could now be Ser#4 Rx. Need to move LedControl from 10/11/12 for SPI. There I moved 10/11/12 to 3/4/5 so a Touch ILI9341 can fit
<edit>: SSD1306 working - just inverting the boot AdaFruit logo each second for now.
>> One T4 doing :: [ Adafruit_SSD1306, 4X Serial ports w/2 looped and 2 EventResponder, IRremote.h, LedControl.h, rtc_init(), 2 ms IntervalTimer _isr , 2 elapsedMillis ]
 
Last edited:
Frank B said:
I had my PC sleeping (T4 removed from USB), and when I came back today, switched PC on, connected T4 - and I had to press the T4-button.
Well, then i've see there was a windows-update pending.
Rebooted.
After that everything was normal, no T4-button press needed (!?)
Click to expand...

did you check the bios to see if USB Initialization is set to Full instead of Partial? my PC wont boot with T4 attached until i disconnect it and reboot, dunnonif its related but first time i seen that hehe the asus ROG extreme defaults to Partial Initialization for USB, after i set full it boots fine, perhaps its a USB descriptor issue
 
@defragster, @Paul - Yes there are issues where some things with String objects don't link.

What I have tried on my machine is to copy: wstring.cpp from the teeny3 directory into the teensy4 directory and now it links.

Not sure if there is a reason not to do this, like you ware wanting to use some other STD::String library for this, or it was just missed.
 
XBEE LIBRARY

Working for Series 1 XBEE modules. Had T4 Tx'ing and Rx'ing from a T3.5 running the equivalent sketch. The problem I was having in my earlier post was due to me forgetting how to get things set up the XBEEs using API2. I typically use transparent or API1. Easier to use.

Don't have any Series 2 modules so if some one wants to give it a try with those to confirm but pretty sure it will work.
 
KurtE said:
@defragster, @Paul - Yes there are issues where some things with String objects don't link.

What I have tried on my machine is to copy: wstring.cpp from the teeny3 directory into the teensy4 directory and now it links.

Not sure if there is a reason not to do this, like you ware wanting to use some other STD::String library for this, or it was just missed.
Click to expand...

did the String.cpp copy and the errors persist from :: Serial.println(String(counter) + " allocations made");

Same code compiles for T_3.6.
 
Status
Not open for further replies.
Back
Top