K66 Beta Test

sumotoy · Jun 16, 2016

I found is faster at 168Mhz than 192Mhz.
Also tested at 96Mhz on Teensy 3.2 and 3.5, it's a bit faster with Teensy 3.5, just a bit.

manitou · Jun 16, 2016

Beta testing PROTO6 board, K66 @180mhz (using Serial1), IDE 1.6.7, teensyduino 1.29beta ubuntu 14.04

16mhz crystal drift: -8 ppm (NTP host) and GPS pps
RTC crystal (32khz) drift: -1 ppm (measured against micros()), 0 ppm measured with LPTMR
RTC alarm sketch ok

power: LED 13 off/on via hacked USB cable: 73.1/76.1 ma (LED forward voltage 1.842)
with asm("wfi") in yield.cpp (power-saving for delay()): 38.6/41.6 ma (@180mhz)
NOTE: probably don't want WFI in yield.cpp, yield() is in loop() while of main.cpp. put WFI in delay()

linpack single precision floating point (100x100) 30 mflops ; double precision, 2.15 mflops (no hardware assist)

crypto acceleration unit (CAU)
md5 10240 bytes 618 us KBs 16569.58
sha256 10240 bytes 2211 us KBs 4631.39
aes set key us 2
aes cbc 64 bytes 12 us KBs 5333.33

uses NXP assembler routines, reference http://www.freescale.com/products/a...ion-unit-cau-and-mmcau-software-library:CAUAP
also see CAU results for mbed K64

PaulStoffregen · Jun 16, 2016

If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched.

EDIT: also curious whether FASTRUN makes a big difference?

manitou · Jun 16, 2016

random number generator, @180mhz, you get 7.7 million random bits/second (spec is 32-bits every 256 F_BUS ticks == 7.5mbs)

BUG
The RNG register addresses in kinetis.h did NOT work! I used the register addresses from my MBED K64F tests, and then RNG worked

these worked

#define RNG_CR (*(volatile uint32_t *)0x40029000) // RNGA Control Register
#define RNG_SR (*(volatile uint32_t *)0x40029004) // RNGA Status Register
#define RNG_ER (*(volatile uint32_t *)0x40029008) // RNGA Entropy Register
#define RNG_OR (*(volatile uint32_t *)0x4002900C) // RNGA Output Register

test sketch with Serial1

Code:

// random RNG
#define PRREG(x) Serial.print(#x" 0x"); Serial.println(x,HEX)

#define REPS 50

#define RNG_CR_GO_MASK                           0x1u
#define RNG_CR_HA_MASK                           0x2u
#define RNG_CR_INTM_MASK                         0x4u
#define RNG_CR_CLRI_MASK                         0x8u
#define RNG_CR_SLP_MASK                          0x10u
#define RNG_SR_OREG_LVL_MASK                     0xFF00u
#define RNG_SR_OREG_LVL_SHIFT                    8
#define RNG_SR_OREG_LVL(x)                       (((uint32_t)(((uint32_t)(x))<<RNG_SR_OREG_LVL_SHIFT))&RNG_SR_OREG_LVL_MASK)
#define SIM_SCGC6_RNGA    ((uint32_t)0x00000200)
//#define Serial Serial1
uint32_t trng(){
    RNG_CR |= RNG_CR_GO_MASK;
    while((RNG_SR & RNG_SR_OREG_LVL(0xF)) == 0); // wait
    return RNG_OR;
}

void setup() {
  Serial.begin(9600);
  Serial.println("hello");  delay(2000);
    SIM_SCGC6 |= SIM_SCGC6_RNGA; // enable RNG
    PRREG(SIM_SCGC6);
    RNG_CR &= ~RNG_CR_SLP_MASK;
    RNG_CR |= RNG_CR_HA_MASK;  // high assurance, not needed
    PRREG(RNG_CR);
    PRREG(RNG_SR);
}

void loop() {
  uint32_t t, r;
  int i;

  t=micros();
  for(i=0;i<REPS;i++) r=trng();
  t=micros()-t;
  float bps = REPS*32.e6/t;
  Serial.println(bps,2);
  Serial.println(r,HEX);

  delay(2000);

}

EDIT: Who knew? there are two RNGA peripheral enables. CGC3 implies the original RNG register addresses in kinetis.h, using CGC6 wants the the new addresses I supplied (actually there were comments in kinetis.h to that effect)

ran a million bytes from RNG through NIST statistical tests -- random bits look good.

EDIT:
Ref 38.1 recommends for better crypto strength, use only 1 bit per 32-bits returned.

FYI, later thread with some statistical testing (DIEHARD, STS)
https://forum.pjrc.com/threads/48745-Teensy-3-6-Random-Number-Generator

T3.5/3.6 TRNG sketch

manitou · Jun 16, 2016

SDHC 4-bit IO
I tried porting the sector-read code that I had working on MBED K64F --- not working. TODO
K64F tests discussed here https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=103556&highlight=sdhc#post103556

adrianfreed · Jun 16, 2016

I got my board today, checked the baseline test of OSC library and all good so far!
I have to update the OSC demonstration code to accommodate all those extra pins - exactly the problem I was
hoping for. Thanks Paul and crew!

Donziboy2 · Jun 16, 2016

PaulStoffregen said:
If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched.

EDIT: also curious whether FASTRUN makes a big difference?

You gave toys to a bunch of grown up kids, of course they will just start poking stuff in random orders

manitou · Jun 16, 2016

USB latency and readbytes test @120mhz to ubuntu 14.04

Code:

     latency_test /dev/ttyACM0
     port /dev/ttyACM0 opened
     waiting for board to be ready:
     .ok
     latency @ 1 bytes: 0.14 ms average, 0.85 maximum
     latency @ 2 bytes: 0.13 ms average, 0.54 maximum
     latency @ 12 bytes: 0.16 ms average, 1.58 maximum
     latency @ 30 bytes: 0.16 ms average, 0.41 maximum
     latency @ 62 bytes: 0.28 ms average, 1.76 maximum
     latency @ 71 bytes: 0.29 ms average, 1.69 maximum
     latency @ 128 bytes: 0.39 ms average, 1.42 maximum
     latency @ 500 bytes: 1.02 ms average, 2.52 maximum
     latency @ 1000 bytes: 1.77 ms average, 2.85 maximum
     latency @ 2000 bytes: 3.25 ms average, 3.56 maximum
     latency @ 4000 bytes: 6.38 ms average, 6.55 maximum
     latency @ 8000 bytes: 12.63 ms average, 13.04 maximum

     receive_test /dev/ttyACM0
     port /dev/ttyACM0 opened
     ignoring startup buffering...
     ignoring startup buffering...
     ignoring startup buffering...
     ...
     Bytes per second = 1023437
     Bytes per second = 1023507
     Average bytes per second = 1023484

http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

manitou · Jun 16, 2016

some ADC pins misbehaving??
unconnected ADC read: on most ADC pins with analogRead() I get a randomish non-zero number EXCEPT for A11, A13, A14, A21, and A22 which all read as 0. A21 and A22 are the DAC's. And pulling A15-A19 to GND does not result in 0, but stays randomish at 300 to 400 ??? Pulling A0-A9 to GND reads 0.

defragster · Jun 16, 2016

manitou said:
random number generator, @180mhz, you get 7.7 million random bits/second

Is this the code as you used it? Cut and pasted and never runs past:

Code:

RNG_CR &= ~RNG_CR_SLP_MASK;

Note: I moved to Serial from Serial1. Was Serial1 used just to hit 180MHz?

manitou · Jun 16, 2016

defragster said:
Is this the code as you used it? Cut and pasted and never runs past:

Code:

RNG_CR &= ~RNG_CR_SLP_MASK;

Note: I moved to Serial from Serial1. Was Serial1 used just to hit 180MHz?

Did you patch kinetis.h as indicated? (Serial1 was for running at 180mhz)

JBeale · Jun 16, 2016

I have not yet absorbed the 2237 page data sheet... I gather the chip has both USB0 and USB1 which use different pins, and the latter offers USB 2.0 High-Speed (480 MHz). Is USB HS available, or are the connected pins for the USB0 device (LS/FS only)?

defragster · Jun 16, 2016

RTC Crystal installed - RTC takes the time and time survives RESET under power - Anyone see a pad labeled VBAT?,- that interior pin group seems not present Beta board? <edit> Time also maintained/recognized and works keeping time uploading prior compiled sketch when power maintained, when power lost it puts in the old compile time.

manitou said:
Did you patch kinetis.h as indicated? (Serial1 was for running at 180mhz)

Of course not . . . it works when I do that

- Thanks. I was looking to do the RNG, I'll use your code to finish reading, maybe I'll learn ...

Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps

Prepped a Prop_LC and a pluggable AdaF Perma-Protoboard for an SSD-1306 ... ESP8266 ...

Win 10 IDE 1.6.9 with TeensyInstall 1.29b2 working fine with K66_Beta board. Good results with TeensyDuino and SerMon - except [NOT NEW to K66] on button or Power cycle or Reset - SerMon gets orphaned.

Paul should do a Kickstarter for these!

Unless there is a pending fix for this? BOARDS.TXT:: line 77 :

Code:

teensy35.menu.speed.180opt=180 MHz optimized  [B](No USB)[/B]

BenS: Perhaps your post #3 could list items tested to work? (links to posts)
> XPT2046_Touchscreen, RTC, ILI9341_t3, TFT_ILI9163C, RNG, SerialFlash, TeensyTransferTool as HI, OSC, PROP_LC

<edit> TeensyTransferTool works against K66 @192MHz as HID using PROP_LC 8MB Serial Flash:

Code:

C:...\teensytransfer>teensytransfer.exe -e
........................................
C:...\teensytransfer>teensytransfer.exe -i > 1.txt
C:...\teensytransfer>teensytransfer.exe -i teensy > 2.txt
C:...\teensytransfer>teensytransfer.exe -w 1.txt
.
C:...\teensytransfer>teensytransfer.exe -w 2.txt
.
C:...\teensytransfer>teensytransfer.exe -l
      71 1.txt
     164 2.txt
C:...\teensytransfer>teensytransfer.exe -r 1.txt
ID    : EF 40 17
Serial: D1 65 38 25 47 25 39 2F
Size  : 8388608 Bytes
C:...\teensytransfer>teensytransfer.exe -r 2.txt
Model : ?? (MK66FX1M0)
Serial: 327680
MAC   : 05:00:00:05:00:00
EEPROM: 4096 Bytes
F_CPU : 192000000 Hz
F_PLL : 192000000 Hz
F_BUS : 48000000 Hz
F_MEM : 27428571 Hz

>> And (of course) RAW_HID fails at 180MHz as well.

PaulStoffregen · Jun 17, 2016

defragster said:
Anyone see a pad labeled VBAT?

On the round 1 & 2 boards, the K66's VBAT pin is hard-wired to 3.3V.

defragster · Jun 17, 2016

PaulStoffregen said:
On the round 1 & 2 boards, the K66's VBAT pin is hard-wired to 3.3V.

Confirmed - Thanks, assumed that was the case given how it is working, and no apparent spare pads. 2 layers? Not much room - the big open bottom side is very full - as already noted good luck putting 2" of stuff inside .5 inches.

Except for needing to clear a bigger hole on my desk - it looks Very Good on the first pass! Very excellent 'Beta' "Proto" board to work with!

manitou · Jun 17, 2016

more pin tests:
PULLUP on all pins, respond to pull to GND, OK -- except DAC0 DAC1
measured pullup resistance on several pins 39Kohms
test PWM pins, OK 488hz

touchRead() hangs ????

ADC, see post #184 some ADC pins misbehaving??

DAC sine output to scope looks OK on A21 and A22

manitou · Jun 17, 2016

"Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps"

Ref manual says RNG generates 32 random bits every 256 ticks of the F_BUS clock

manitou · Jun 17, 2016

manitou said:
more pin tests:

touchRead() hangs ????

The touch (TSI) registers for the K66 are very different than the teensy 3 TSI registers. So additional logic will have to be added to hardware/teensy/avr/cores/teensy3/touch.c

Frank B · Jun 17, 2016

PaulStoffregen said:
If anyone wants to dig into the details, the K66 has a large 8K cache. I honestly haven't even looked into whether it's even enabled. I'm mostly focused on getting code working correctly.... so by all means, play with this performance stuff I haven't even touched.

EDIT: also curious whether FASTRUN makes a big difference?

- The value of LMEM_PCCCR is 3, which means writebuffer and cache are enabled
- Fastrun... ehm.. it is faster without it... ! (but I tested with only one little short sketch only)

Ben · Jun 17, 2016

defragster said:
BenS: Perhaps your post #3 could list items tested to work? (links to posts)
> XPT2046_Touchscreen, RTC, ILI9341_t3, TFT_ILI9163C, RNG, SerialFlash, TeensyTransferTool as HI, OSC, PROP_LC

I can do that, but to be honest I lost track of who is testing what. I fear if I take the job as a "human bug tracker" I can't satisfy your needs if I only update once or twice a day.
Maybe a list of all Libraries and all Shields/Adaptors with a short description of the current status can be put in Post 3? I'd try to update that dayly, and if I miss something you could PM me or post here? But for that I'd need that list as a start.

defragster · Jun 17, 2016

manitou said:
"Of course bit create clock varies with multiplier :: 96MHz, 144MHz to 192 MHz:: 6,106,870.00<< bps, but 120 MHz (like 180 MHz) :: varies 7,619,047.50 to 7,7294,68.50<< bps"

Ref manual says RNG generates 32 random bits every 256 ticks of the F_BUS clock

- yes, that was the 'of course bit create' part - I had scanned that

Ben said:
I can do that, but to be honest I lost track of who is testing what.

Yeah - posted that and realized it could be a big chore - not as easy as an unchanging pin list . . . at 8 pages and growing and so many topics and 8 folks turning in to 80 ...

... and the list - I wonder if Paul has one or the LC list to start with?

I put FASTRUN on the super short trng() code and - natural code management probably keeps all that.

Ran last 8hrs - 10 trng()'s and the still current RTC clock spewing serial

manitou · Jun 17, 2016

Another example of floating point hardware in float-intensive filters for prop shield IMU, (no sensor data collection). The NXP kalman filter is compiled with
#pragma GCC optimize ("O3")

Times are in microseconds

Code:

           Teensy 3.2   K64       K66     K66     mbed K64  stm32l4  F469NI  mega2560
             @120mhz  @120mhz   @180mhz @120mhz    @120mhz   @80mhz  @180mhz  @16mhz
NXP/kalman      3396    358       250     367        368      535     315    30272  us
madgwick         223      7         7      10          8        8       6     2628
mahony           125      5         5       8          6        6       4     1548

manitou · Jun 17, 2016

Ye old sdFAT SPI/FIFO sketch runs at 27.4 megabits/sec with SPI clock @ 30mhz. Good.

but some old teensy SPI DMA sketches seem to be hanging ... TODO

the default SPI library runs at 13.3 mbs with 30mhz SPI clock.

I2C scan works with prop-shield, but onehorse prophshield sketch won't compile (i2c_t3 lib ?)

NXPMotionSense orientation example OK with propshield

EEPROM sketch reads EEPROM, but hangs in write() ???? works on teensy 3.2

KurtE · Jun 17, 2016

I decided to try hooking up Dotstar leds, My first attempt failed as tried using same level shifter I used for Neopixel test (TXB0108). Did not work. So decided to instead
try using Propshield, so I jumper-ed the appropriate pins from this board to propshield, and then tried running, the Adafruit_dotstar libraries test program strandtest with a couple slight mods (pinmode(7, OUTPUT)... and also used the SPI contructor). Appears to run fine.

Next up trying the FastLed test app that is listed in the prop shield page. Fails to compile, now time to edit...

Ben · Jun 17, 2016

manitou said:
Another example of floating point hardware in float-intensive filters for prop shield IMU, (no sensor data collection). The NXP kalman filter is compiled with
#pragma GCC optimize ("O3")

Times are in microseconds

Code:

T3.2@120mhz K66@180mhz NXP 3396 285 madgwick 223 7 mahony 125 3

Are the filters using the "0x5f3759df" fast inverse square root? Maybe that speed-for-accuracy optimization can be omitted on the K66.

K66 Beta Test

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member