Teensy 4.0 First Beta Test

[Frank B]

@Paul, can we talk about the memorymap?
I think it may be better to move DMAMEM behind the heap. Heap-start: 0x20200000, DMA-start 0x20200000 + SIZEOF(OCRAM) - SIZEOF(DMAMEM) ( with correct granularity)
Problem is (I think, if I understand that correctly!!!), the MPU can divide a region into 8 subregions with eqal size only.

So if we place DMAMEM before Heap, and let's say DMAMEM is 153600 Bytes, and Heap starts after that, the first part of heap has to have the same cache-setting as DMA.
If we reverse that, and place DMAMEM after Heap, we have basically the same situation, but if we move the region a bit down we can have the DMAMEM as intended and only a small part of the upper heap (which is not used with a bit luck) with wrong cache-setting.

 

[WMXZ]

@Walter: IRQ_SOFTWARE is already defined (70)

Yes, I know, but contrary to T3x, all ISR are by default unused ( and blink fast).

 

[mjs513]

TEMPERATURE MONITORING in CORE FILES

First don't panic, unless the chip get over 95C nothing chip won't restart automatically. Attached is a zip with the changes to the core to get the tempmonitor into the core to start automatically. Then from any sketch you just call tempmonGetTemp() and you get the current core temp. If you want to give it a try.

View attachment tempMonCore.zip

There are only 2 functions, init and gettemp.

Up to the boss if he wants to incorporate this piece into the core. As for what to do when the panic temp is hit, I will leave it up to FrankB

 

[Frank B]

LOL, that' Pauls decision (I can help to write some code)

I thought about that, and I think - if we run at high frequencies - we should remove loops like while(1); from the core (there are a few places) and switch-off* instead.
While(1); without temperature-monitoring may be very bad... with temperature monitoring we should at least make sure that the temperature does not rise more after a "panic"-event. My idea was to issue a reset (this will work with a crashed app, too) when "panic" and switch off* after reset.

mjs, I'll look at your zipfile thank you!

Edit:
*or run while(1); with a very low frequency

 

[mjs513]

with temperature monitoring we should at least make sure that the temperature does not rise more after a "panic"-event. My idea was to issue a reset (this will work with a crashed app, too) when "panic" and switch off after* reset.

That's the beauty of the temp monitor. If the panic temp is exceed it will auto reset. On reset it the PMU_MISC1 register identifies the cause of the reset including temperature. So, if you test for that on startup then you can tell it to "switch off". Like you said that's up to Paul. I am trying to get things crossed off his giant list of things to do

Oh, in case you are wondering you don't need to do a read temp for it work, it does it automatically in the background.

Maybe that list should be broken up to a couple of lists. Whats done and whats left to do. Might be easier to go through.

Respectfully
Mike

EDIT:

*or run while(1); with a very low frequency

Throttling?

EDIT2: Don't need to replace analog.c = put it in there by accident.

 

[PaulStoffregen]

@Paul, can we talk about the memorymap?

Just to let you know, today I'm having to deal with some business stuff - less time for dev work today. Hope to be back up to speed early tomorrow.

I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou. I have a 5th board where Serial7 isn't connected - don't know why yet.

These breakout boards have a place to plug in an audio shield. But when I designed the breakout board, I didn't plan the heights too well, so the audio board's headphone jack can't be plugged in with the Teensy 4 in place (this will be pretty easy to see when you get the boards). So we're sending you an audio board and a pair of the tall headers, so you can raise the audio board up enough to be able to actually get the headphone plugged in. There's a slide switch which controls some mux chips, so either SAI1 or SAI2 can be connected to the audio shield.

The SD card pins of the audio shield (11, 7, 14) route to the SPI pins (11, 12, 13), so this should also give a convenient way to test SD cards with SPI access.

The breakout board also has 2 pogo pins for the 2nd USB port, going to a USB host connector. USB host power is from VIA through a TPS2055A current limiter, so hopefully you can hot-plug USB devices without crashing Teensy 4's power.

I have not actually tested the audio connections or USB stuff yet - only the serial port signals have actually been tried. Hopefully I didn't mess this board up, cause we're sending to you now.


On the memory, the main reason to have the static DMA buffers first is the heap grows upward. I believe _sbkr() is supposed to cause malloc and new to not do more allocations when they reach the limit.... so many it's safe to put static buffers after the heap? But it still *feel* strange. I need a little time to think on this.

 

[Frank B]

Thank you, awesome.

Memory: Isn't the stack behind the heap on the other boards? Not sure if I remember correctly.

 

[WMXZ]

These breakout boards have a place to plug in an audio shield. But when I designed the breakout board, I didn't plan the heights too well, so the audio board's headphone jack can't be plugged in with the Teensy 4 in place (this will be pretty easy to see when you get the boards). So we're sending you an audio board and a pair of the tall headers, so you can raise the audio board up enough to be able to actually get the headphone plugged in. There's a slide switch which controls some mux chips, so either SAI1 or SAI2 can be connected to the audio shield.

@those_who_get_the_breakout_board
If you are interested in a SAI test program, I put my (running) program to GitHub https://github.com/WMXZ-EU/basicSAI
(it is 32 bit, but I trust you know how to change to 16 bit)

 

[Frank B]

I am interested I think we can parts of that for SPDIF? I've bought a new SPDIF-DAC to test the T4.

 

[mjs513]

I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou.

WOW. Thank you Paul. Pleasant surprise.

 

[KurtE]

Thanks Paul,

Will start testing some of the bottom pins when it arrives

I just checked in my changes to SPI for transfer(buf, retbuf, cnt)

I updates the delay between bytes to be half the value computed for the speed. At least that is what looks like it should work properly. The good news is that looks correct, the bad news is that it probably slows down single byte transfers... But that is expected as same as T3.x...

Not sure yet which thing to look at next:

a) Update Transfer16 should be simple... Just need to update TCR.FRAMESZ - question to self is to change once and back after the transfer16, or cache the information and only change when needed...

b) Play with CS pin, to see how it works (can I control it it and use for DC pin?

c) SPI.transfer - Async version ---Would help to see a working DMA operation... How close is it to T3.x?

d) SerialX - Try out the half duplex support - maybe try out Dynamixel Servos...

e) Maybe something completely different? Has anyone tried playing with the Flex Pins? Like make an SPI setup or Wire or Serial?

Now back to playing

 

[mjs513]

TALKIE LIBRARY

Made a minor updates and put pin 5 into the .cpp if you specify a propshield is attached. Only example updated is toms_diner. If you want to give it a try its on GitHub: https://github.com/mjs513/WIP

 

[manitou]

Sigh, T4 won't load at all this morning. After pushing program button, i get slow flashing red LED, but no progress bar and uploads fail. no /dev/ttyAMC0. Holding down program button for 13 secs, gets steady red LED for a few seconds ... but doesn't fix anything

It was working last night with beta7. I think the last thing i did was I2C test of setClock() with scope -- looked good at 100k, 400k, and 1mhz.

5v on Vin, 3.3v on 3v3 pin.

I've tried on other desktops, other USB cables. T3* stuff still works.

Well, i hooked T4 up to my laptop (linux 1.8.8 beta5), and it was able to upload and run . (I still have to push program button after load to get it to run and /dev/ttyACM0 to appear)... maybe it's something to do with beta7 and my T4? though i ran several sketches under beta7.

i'll do my builds on my laptop, til i feel brave enough to go back to desktops...

 

[defragster]

I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou.

WOW. Thank you Paul. Pleasant surprise.

I'll second that and add a -

@WMXZ - Ordered a pair of the PJRC PT8211 kits with my Beta T4 assuming they be good for testing - Will they be useful against your basicSAI code? - of course with a dedicated Audio Board …

Found an old Panasonic VCR remote [with understood codes] and the IR_recv code is of course still working from last upload last night.

 

[Frank B]

I think I have some PT8211 (at least their China pendants..forgot the part number) too, Walter.
Might be faster from Germany..

 

[KurtE]

Looks like the gap timing between transfers still needs some work... Running a quick test program to test some of the different SPI transfers including SPI.transfer16().

I implemented the transfer16, which you can see in the screenshot:


You can see how the 16 bits output as one unit and way to big of a gap between transfers. Asked for 30mhz transfer speed...

 

[manitou]

TRNG

T4 has a hardware random number generator, it is quite complex and slow, and documentation is subject to NDA. See earlier post
https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=193965&viewfull=1#post193965
The NXP SDK has some examples using the TRNG, and I was able to mostly port the code to Teensy 4. There are lots of statistical configuration parameters -- I just took the defaults (whatever they may be). The TRNG produces 512 bits every 13470 us -- much much slower than the T3.5/3.6 TRNG, so the T4 TRNG is best suited for generating a random seed for a PRNG. I haven't done the NIST statistical tests for randomness (yet), but I did calculate byte-entropy on 16K TRNG bytes , getting 7.98. 16 KB of random() bytes has entropy of 7.94

The SDK TRNG example with its configured statistical parameters takes 212856 us to generate 512 random bits, and NIST statistical tests look good.

EDIT: I ran some randomness stat tests on 1MB of TRNG data. Results weren't that good, one will need to configure TRNG rather than taking default POR values.

EDIT 2: enabling von neumann sample mode (0) in the TRNG increased the time to generate 512 random bits to 52780 us, and the various NIST statistical tests look good.

EDIT 3: using von neumann mode (2) is faster (13484 us for 512 bits) and NIST tests are good.



sample sketch: https://github.com/manitou48/teensy4/blob/master/trng.ino

SDK ref: https://mcuxpresso.nxp.com/api_doc/dev/210/group__trng__driver.html

Teensy 3.5/3.6 TRNG

performance data of various MCU RNGs

UPDATE 8/2020: T3 and T4 TRNGs have been added to Teensy Entropy lib


See NXP 1170 TRNG and PRNG performance.

 

[manitou]

If someone wants to know how to switch the IMXRT off completely, mail me.. tested, works... but I don't write that here, because if you have no long delay before that, there is currently no way to switch it on again, as it will immediately switch off when it runs the program with the command ... so..it's risky. have not tried if the 13-seconds reset works in this case..

edit: ok, 13 seconds reset still works, so i think it's the bootloader-chip which stays alive and monitors the button.

edit: and this confirms the 13-seconds reset works, too

Frank can you email me your code? Usually, with scary sketch, i add an INPUT_PULLUP pin that I spin on at the start of the sketch, and won't "start" til the pin is pulled low.

Actually, what i'm interested in is the power implications. Can you measure power (milliamps) for your T4 running blank sketch, and then run your shutdown sketch and measure power when IMRXT is off. Then we know the overhead power used by the bootloader etc. on the PCB.

 

[defragster]

Frank can you email me your code? Usually, with scary sketch, i add an INPUT_PULLUP pin that I spin on at the start of the sketch, and won't "start" til the pin is pulled low.

Actually, what i'm interested in is the power implications. Can you measure power (milliamps) for your T4 running blank sketch, and then run your shutdown sketch and measure power when IMRXT is off. Then we know the overhead power used by the bootloader etc. on the PCB.

Frank sent me a copy, I can PM to you if Frank is offline.

I get 86.3 mA with blank sketch, I may have put yield() in the loop() cycle.

Frank's Sketch runs just over 87 mA printing for 10 seconds it then powers off to 28 mA.

It then ignores button push … not sure where that power is going ...

Repowering goes back to 87 mA - then after countdown is sitting at 28.1 mA.

I had two other Teensy's on breadboards with common GND and unplugging them shows it sitting at 28.3 mA

That is the first I ran the sketch - it counts down 10 seconds - just did a Verify sketch and powered up with button and it uploaded IRrecvDemo no problem - Funny it was showing 100 mA before putting power back to BBoard to the IR device (with a blue pilot light LED) and it dropped to 98.7 mA.

 

[manitou]

Frank sent me a copy, I can PM to you if Frank is offline.

I get 86.3 mA with blank sketch, I may have put yield() in the loop() cycle.

Frank's Sketch runs just over 87 mA printing for 10 seconds it then powers off to 28 mA..

Thanks. Those numbers look good, suggesting MCU consumes 59 ma. Spec says 0.11ma/MHz, so for 600MHz about 66ma

 

[defragster]

Thanks. Those numbers look good, suggesting MCU consumes 59 ma. Spec says 0.11ma/MHz, so for 600MHz about 66ma

<edit> - sketch not the evil - DO NOT RUN THIS SKETCH ?!?!?!?!?!?!
I think the issue may have been the way power checking was forcing the device to restart.
I just revisited the sketch a bit more - making sure it returned the F_CPU to 600 - also the RTC started to make sure Millis clocks right - and it had Serial running as well.

This sketch boots to ~83 mA then drops to 58 mA

extern "C" uint32_t set_arm_clock(uint32_t frequency);
void setup() {
  S e r I a l .begin(9600); // This line broken on purpose 
  while ( !Serial && millis() < 800 ) ;
  Serial.println("F_CPU_ACTUAL");
  Serial.println(F_CPU_ACTUAL);
  delay(5000);
set_arm_clock(300000000);
  Serial.println("F_CPU_ACTUAL");
  Serial.println(F_CPU_ACTUAL);
}
void loop() {
}

and prints::

F_CPU_ACTUAL
600000000
F_CPU_ACTUAL
300000000

Not Funny but ODD - after running that sketch I pull USB and replug - it prints speed drop and then only consumes 27 mA? I rewrote the sketch to end with 600 MHz - and it went to 37 mA … but doesn't seem to be running ???

Just did a 15 second hold ? Light Red went to solid RED for some seconds then Off and T4 is Back - but not running Right yet?

Paul - here is Verbose TLoader in case it shows something? View attachment SetArmClock_XXX.txt

Uploaded a MinBlink after another 15 second reset and T4 Debugt output just shows:

status = 00370080
status = 00370080
status = 00370080
status = 00370080
status = 00370080
status = 00370080
status = 00370080
status = 00370080
status = 00370080

Uploaded a non-printing min blink - never gets to Setup - here is debug output:

***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
USB reset took 5 loops
analogInit
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup

Closes T_sermon and then saw this as debug port output:

usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
after setup

It is now blinking?

 

[defragster]

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?

Initial Serial USB not always showing - it is different? I need to Reboot - PORTS are not right again.

Pic of Ports Menu:
View attachment 15551

Rebooted machine - which was seemingly messed up above - no TyCommander updates - just games with power and speed as noted …

Machine seems fine - good ports menu and T4 programs just fine.

 

[mjs513]

Manitou - did you run Set_Arm_Clock on your T4?

Tim. Never tried changing the clock speed direct from the sketch only from the startup file, and that was never a problem. Didn't look close at the code for set_arm_clock but I know there are all kinds of warning about changing clocks while running. Wonder if the USB speed got messed up some how which caused the ports to be lost? Just talking out loud.

In the temp monitor SDK example they change AHB divider but the function has a handshaking function going on, it checks the CDHIPR register which states:

The CDHIPR register contains read-only bits that indicate that CCM is in the process of updating dividers or muxes that might need handshake with modules

Page 728. clockspeed.c doesn't wait for the clocks not to be busy so it probably messed all the clocks up. Know I am not saying this right but think you get the idea.

 

[mjs513]

@defragster - just went through the sdk example, getting good with the clock stuff, a down and dirty for changing the arm clock would be something like this (It needs a lot of clean up before really ready), it is untested - will do that tomorrow:

PS: You should recognizer your assert function from ahrs days

Divider is 1, default - got this from p676 of the ref manual (fig 18-2 clock tree), haven't verified this yet

WARNING: UNTESTED

#define CCM_TUPLE(reg, shift, mask, busyShift)                                                                     \
    ((((uint32_t)(&((CCM_Type *)0U)->reg)) & 0xFFU) | ((shift) << 8U) | ((((mask) >> (shift)) & 0x1FFFU) << 13U) | \
     ((busyShift) << 26U))
#define CCM_TUPLE_REG(base, tuple) (*((volatile uint32_t *)(((uint32_t)(base)) + ((tuple)&0xFFU))))
#define CCM_TUPLE_SHIFT(tuple) (((tuple) >> 8U) & 0x1FU)
#define CCM_TUPLE_MASK(tuple) ((uint32_t)((((tuple) >> 13U) & 0x1FFFU) << ((((tuple) >> 8U) & 0x1FU))))
#define CCM_TUPLE_BUSY_SHIFT(tuple) (((tuple) >> 26U) & 0x3FU)

#define CCM_NO_BUSY_WAIT (0x20U)

#define assert_( a ) if (!a) { assert_3(__FILE__, __LINE__,  #a); }
// handle diagnostic informations given by assertion and abort program execution:
void assert_3(const char *__file, int __lineno, const char *__sexp) {
  // transmit diagnostic informations through serial link.
  // Serial.println(__func);
  //Serial.println(" ___ ASSERT FAILED ___ FILE, LINE#, Expression ");
  //Serial.println(__file);
  //Serial.println(__lineno, DEC);
  //Serial.println(__sexp);
  //Serial.flush();
  // abort program execution.
  //xxx abort();
  Serial.println(" ___ ASSERT FAILED ___ STOPPING !!!!");
  Serial.printf("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" function name \"%s\" \n", __sexp, __file, __lineno, __func);
  
  while ( 1 );
}


static inline void CLOCK_SetAHBDiv(uint32_t value)
{
    uint32_t busyShift;

    busyShift = CCM_TUPLE_BUSY_SHIFT(0x1U);
    CCM_TUPLE_REG(IMXRT_CCM, 0x1U) = (CCM_TUPLE_REG(IMXRT_CCM, 0x1U) & (~CCM_TUPLE_MASK(0x1U))) |
                                  (((uint32_t)((value) << CCM_TUPLE_SHIFT(0x1U))) & CCM_TUPLE_MASK(0x1U));

    assert(busyShift <= CCM_NO_BUSY_WAIT);

    /* Clock switch need Handshake? */
    if (CCM_NO_BUSY_WAIT != busyShift)
    {
        /* Wait until CCM internal handshake finish. */
        while (CCM_CDHIPR & (1U << busyShift))
        {
        }
    }
}

 

[defragster]

So that's my second Scare where everything came back after Windows reboot. And the IDE's T_port menu entries - were out of sorts as shown.

Common thread may be … tormenting Windows USB and T_ports?:
> the first time the 7 seg LED was powering from data/control lines and/or spurious GND wire - may have been putting T4 in shutdown?
> second time I was cycling power with AMP meter leads after Power Off? - this time power wire to other parts pulled and unplugged LCD to measure only T4 current.

In this case not sure which happened first - Messed up USB or Odd speed? T_sermon wasn't connecting - but on opening TyComm it could connect and get output.

Mike: First thing I saw was button required - thought of manitou testing - probably just USB confusion. No warnings in the set_arm_clock() code - though I did have to add extern "C" for compiler to find it.
I assume on restart all clocks start fresh for 600 MHz run - thought maybe not so that is why I did 15 second reset - odd thing was Amps read in 20's and 30's while it wasn't running right. That part still doesn't make sense with power that low the T4 was not running?

Cool to see the assert_() usable! I have it in the debug_t3 code … now that Kurt has all Serial#'s working I was thinking I should get back and redo that for T4. Paul has minimal 'dump' on _faults I could start with - but his 'void unused_interrupt_vector(void);' isn't weak …

There just hacked Core T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\startup.c:

// WAS >> // void unused_interrupt_vector(void);
void unused_interrupt_vector(void) __attribute__ ((weak, alias("unused_interrupt_vectorX")));

// ...

// void unused_interrupt_vector(void) __attribute__ ((weak, alias("unused_interrupt_vectorX")));


void unused_interrupt_vectorX(void)

Then I went back to the FAULT in Coremark and indeed my local Sketch function gets called.

It is still Hard Hanging without :: // TODO: polling Serial to complete buffered transmits
KurtE / Paul - do you have code to keep Serial Polling running so MCU responds to USB to Upload? Maybe this only makes sense or will be known with USB rewrite ...

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
_Tim Was Here_
T:\tCode\T4\teensy4_coremark\teensy4_coremark.inounused_interrupt_vector
_Tim Was Here_

irq 3
60001309
0000104C