Correct -mmcu for Teensy 3.5

Status
Not open for further replies.
I'm trying to get started with a Teensy 3.5 that landed in my mail box yesterday. I did this by following the instructions.

The CPU is an ARM based mk64fx512.
The cpu types listed in the example programs do not include that.

Blinky Makefile:
#MCU = at90usb162 # Teensy 1.0
#MCU = atmega32u4 # Teensy 2.0
#MCU = at90usb646 # Teensy++ 1.0
#MCU = at90usb1286 # Teensy++ 2.0

Passing -mmcu=mk64fx512 to avr-gcc does not lead to happiness:

# make

-------- begin --------
avr-gcc (Fedora 4.9.3-1.fc22) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: blinky.c
avr-gcc -c -mmcu=mk64fx512 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./blinky.lst -std=gnu99 -MMD -MP -MF .dep/blinky.o.d blinky.c -o blinky.o
avr-gcc: error: unrecognized argument in option '-mmcu=mk64fx512'
avr-gcc: note: valid arguments to '-mmcu=' are: at43usb320 at43usb355 at76c711 at86rf401 at90c8534 at90can128 at90can32 at90can64 at90pwm1 at90pwm161 at90pwm2 at90pwm216 at90pwm2b at90pwm3 at90pwm316 at90pwm3b at90pwm81 at90s1200 at90s2313 at90s2323 at90s2333 at90s2343 at90s4414 at90s4433 at90s4434 at90s8515 at90s8535 at90scr100 at90usb1286 at90usb1287 at90usb162 at90usb646 at90usb647 at90usb82 at94k ata5272 ata5505 ata5790 ata5790n ata5795 ata6285 ata6286 ata6289 atmega103 atmega128 atmega1280 atmega1281 atmega1284 atmega1284p atmega128a atmega128rfa1 atmega16 atmega161 atmega162 atmega163 atmega164a atmega164p atmega164pa atmega165 atmega165a atmega165p atmega165pa atmega168 atmega168a atmega168p atmega168pa atmega169 atmega169a atmega169p atmega169pa atmega16a atmega16hva atmega16hva2 atmega16hvb atmega16hvbrevb atmega16m1 atmega16u2 atmega16u4 atmega2560 atmega2561 atmega26hvg atmega32 atmega323 atmega324a atmega324p atmega324pa atmega325 atmega3250 atmega3250a atmega3250p atmega3250pa atmega325a atmega325p atmega328 atmega328p atmega329 atmega3290 atmega3290a atmega3290p atmega3290pa atmega329a atmega329p atmega329pa atmega32a atmega32c1 atmega32hvb atmega32hvbrevb atmega32m1 atmega32u2 atmega32u4 atmega32u6 atmega406 atmega48 atmega48a atmega48hvf atmega48p atmega48pa atmega64 atmega640 atmega644 atmega644a atmega644p atmega644pa atmega645 atmega6450 atmega6450a atmega6450p atmega645a atmega645p atmega649 atmega6490 atmega6490a atmega6490p atmega649a atmega649p atmega64a atmega64c1 atmega64hve atmega64m1 atmega64rfa2 atmega64rfr2 atmega8 atmega8515 atmega8535 atmega88 atmega88a atmega88p atmega88pa atmega8a atmega8hva atmega8u2 atmxt112sl atmxt224 atmxt224e atmxt336s atmxt540s atmxt540sreva attiny11 attiny12 attiny13 attiny13a attiny15 attiny1634 attiny167 attiny22 attiny2313 attiny2313a attiny24 attiny24a attiny25 attiny26 attiny261 attiny261a attiny28 attiny4313 attiny43u attiny44 attiny44a attiny45 attiny461 attiny461a attiny48 attiny84 attiny84a attiny85 attiny861 attiny861a attiny87 attiny88 atxmega128a1 atxmega128a1u atxmega128a3 atxmega128a3u atxmega128a4u atxmega128b1 atxmega128b3 atxmega128c3 atxmega128d3 atxmega128d4 atxmega16a4 atxmega16a4u atxmega16c4 atxmega16d4 atxmega192a3 atxmega192a3u atxmega192c3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256a3u atxmega256c3 atxmega256d3 atxmega32a4 atxmega32a4u atxmega32c4 atxmega32d4 atxmega32e5 atxmega32x1 atxmega384c3 atxmega384d3 atxmega64a1 atxmega64a1u atxmega64a3 atxmega64a3u atxmega64a4u atxmega64b1 atxmega64b3 atxmega64c3 atxmega64d3 atxmega64d4 avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 m3000
Makefile:549: recipe for target 'blinky.o' failed

The CPU in that chip is an ARM. Not an AVR. So I suspect the documentation is leading up completely the wrong path.

What am I missing to compile the most basic light blinker for a Teensy 3.5?

I'm using the command line on Fedora. That's all happening - I can make and compile and download to the teensy 3.5, but it then doesn't work, because as far as I can tell, compiling for a Teensy 2.0 is completely wrong, given that it's a different CPU.

# teensy_loader_cli -mmcu=mk64fx512 -v -w blinky.hex
Teensy Loader, Command Line, Version 2.1
Read "blinky.hex": 1788 bytes, 0.3% usage
Waiting for Teensy device...
(hint: press the reset button)
Found HalfKay Bootloader
Read "blinky.hex": 1788 bytes, 0.3% usage
Programming..
Booting <--- and this is where the Teensy 3.5 sits impassively, not blinking anything.

Any advice is appreciated.

Thanks,
David Johnston
 
The Teensy 3.x ( and LC ) Family is ARM 32 bit not AVR like Teensy 2 family.

Best start and to get all the tools is with Arduino IDE and then install TeensyDuino - that gives a local copy of all the PJRC specific code.

That will provide a way to build and upload programs. in the process it will show the build tools used and the command lines used. There is a makefile that can be setup to use that toolchain.

it seems like you are skipping that step - perhaps by design - but there is a wealth of tools and help starting on that path - and is the basis of Forum and other support for the Teensy.
 
Hmm.
I'm not completely sure how I run an Arduino IDE on a headless linux box from the command line.

I'm doing it from the command line because that's how I've done it for 30 years. If installing the IDE and TeensyDuino is the fastest path to getting the right library, I'll give it a go.

Thanks. I may be back here shortly :)

David
 
As a Windows user - I can't help with that - though others can and there are threads around covering aspects given the above it may help find the needed direction.
 
What I have done with my Headless UP board, is to install a VNCServer, which from time to time I will tell it to start in a command line. I then use a VNC client program on my PC to talk to the server... There I can do all of the things like install Arduino and Teensyduino...

Once you have that working, you have several options, which include:

You can continue to use the VNC stuff when you are working with your board.

You can setup make files to build your Teensy stuff using the appropriate ARM compilers that Teensyduino installs.

You can try using the Arduino command line to build the program and create a Hex file. The Teensy program to upload will fail as it does not have a GUI to launch in. But you can either live with this and do it manually (Build the Teensy command line program), or you can hack up the installed programs to use this command line version of the install program. I did this awhile ago for an ARM linux setup (ODroid)...
 
Thanks. That all makes sense. I wrestled the firewall squid and got a vnc login working and can run arduino.

However the absence of documentation for the Linux version of the Teensyduino installer is a roadblock. It asks for a location of the arduino code and won't proceed until it is given one. The location for the arduino IDE is /usr/bin for the executable and /usr/share/arduino for the other stuff. Neither of these locations satisfies the installer.

Do you remember where you pointed the Teensyduino installer?

David
 
What version of the IDE and TeensyDuino did you start with? May not be the problem - but TD will only install on specific release versions as it needs to make internal mods to known code.

IDE 1.8.5 and TD 1.40 are the current versions.

I had a Pi out and Linux install of Arduino vexed me so I can't say what should go where.
 
What ever the package manager deemed to be the one..

The arduino IDE reports 1.0.6.
I don't think there is source.

I'm sensing one of those "compile everything from scratch" moments. Just so the installer has something to find.
 
It probably depends on how you install Arduino. If you installed it using something like: sudo apt-get install arduino...

Yes that won't work with Teensyduino. If however you install it using the Arduino way:
You can download it from https://www.arduino.cc/en/Main/Software

Once you download it and uncompress it. Mine currently is on the desktop... You can run the install script that puts an icon on your desktop to run Arduino... You can then download Teensyduino and install it when you uncompressed the Arduino install.
 
Well that helped. I got rid of the package manager IDE. Installed 1.8.5. Got the Teensyduino installer to work and can compile a sketch and throw it at the board. The LED still doesn't flash, but at least it's broken with the right compiler :)
 
And with a little more hacking I found the pin for the led was on pin 13, so it's now it's flashing the LED and so showing the compile and download chain is working.

I can now move on with what I intended to do, which is test the RNG. My primary area of expertise is designing and testing RNGs.
Thank you for all your help.
 
Interested to see anything you can post about the RNG. There is at least one thread on getting the RNG running - perhaps in last years BETA K66 thread. Should point to a Github sample on getting it running. Looks like Manitou did that here

Awesome I spotted the problem with Arduino version - headless as it were :) Yes #13 is :: #define LED_BUILTIN (13), not sure if that #define crosses to Arduino - or just PJRC?
 
The Teensyduino installer puts a sample Makefile in Arduino's hardware/teensy/avr/cores/teensy3 folder.

For a fully command line only workflow, you might also wish to use the command line version of Teensy Loader.

https://www.pjrc.com/teensy/loader_cli.html

If you run into problems, remember the "normal" way is using the Arduino IDE. Best to check if something problematic works in the IDE. In the IDE, you might also click File > Preferences to turn on verbose info while compiling. Then Arduino will show you all the commands it executes. Modern versions of Arduino do something similar to a unix "configure" script, mainly to discover which libraries your code needs, and then it actually builds all your code. Usually with a Makefile- based build, you'd put that info right into the Makefile.
 
Interested to see anything you can post about the RNG.

I got the RNG running after digging for some documentation. The documentation admits that there is a ring oscillator in there and also a PRNG. It doesn't give any more details. The output after brief testing looks 'random' as in I didn't find anything with the usual tools (djent, sp800-22 see my github for code, github id dj-on-github). This is what you would expect from the output of a PRNG. The performance is about 7.5 mbps, which given the RNGs in your desktop, is laughably slow (roughly 1000X slower).

What I'm interested in is the unprocessed output of the ring oscillators. I tried fuzzing the reserved bits in the CR, to find a setting that changes the speed (the oscillator output will be a different speed to the RNG output) but nothing exciting happened there.

A deeper cryptanalasys will have to wait on me having some spare time.

// RNGA Register addresses.
// From NXP K24 Sub-Family Reference Manual Rev. 3, Aug 2014. Pages 681-688.
volatile uint32_t *p_rng_cr = (volatile uint32_t *)0x40029000;
volatile uint32_t *p_rng_sr = (volatile uint32_t *)0x40029004;
volatile uint32_t *p_rng_er = (volatile uint32_t *)0x40029008; // We don't need this one.
// Extra entropy is dumb.
// Docs 32.3.3 imply that this is extra input to a PRNG.
// But the PRNG isn't described. 7.5Mbps is more
// than you can get from ring oscillators, so I
// assume there is a PRNG in there. 7.5MBytes/s is
// slow for a prng (mine does 6.4Gbps) so
// guesswork is in order. I've never met a ring
// oscillator based RNG that I didn't hate.
volatile uint32_t *p_rng_or = (volatile uint32_t *)0x4002900C;

// The secret gotcha. The clock enable is here.
uint32_t *p_scgc6 = (uint32_t *)0x4004803C;

uint32_t cr_go = 0x00000001;
uint32_t cr_ha = 0x00000002;
uint32_t cr_intm = 0x00000003;
uint32_t cr_clri = 0x00000008;
uint32_t cr_slp = 0x00000010;

uint32_t sr_secv = 0x00000001;
uint32_t sr_lrs = 0x00000002;
uint32_t sr_oru = 0x00000003;
uint32_t sr_erri = 0x00000008;
uint32_t sr_slp = 0x00000010;

// Wait on the OREG_LVL field being non zero.
uint32_t read_output_reg_busy_waiting() {
uint32_t x;
while (1) if ((*p_rng_sr & 0x0000FF00) != 0) {x = *p_rng_or; return x;}
}


void how_fast_is_it(uint32_t count) {
uint32_t t_start;
uint32_t t_end;
uint32_t span;
uint32_t i;
uint32_t j;
uint32_t x;
double period;
double mbps;

// Let's measure how fast it is.
// Loop overhead shouldn't matter because this RNG is sloooooow.
for (j=0;j<count;j++) {
t_start = micros();
for (i=0;i<100000;i++) {
x = read_output_reg_busy_waiting();
}
t_end = micros();
span = t_end - t_start;
period = (double)span/(double)100000;
Serial.print("To read 32 bits, it took ");
Serial.print(period,6);
Serial.print(" microseconds. ");
mbps = 32.0/period;
Serial.print(mbps,4);
Serial.print(" mbps. Last random value: x=0x");
Serial.println(x,HEX);
}
}

void lets_fuzz_the_cr_reserved_bits() {
uint32_t x;
uint32_t fuzzmask = 0xffffffe0;
uint32_t i;
uint32_t cr;
cr = *p_rng_cr;
cr &=~fuzzmask;
cr |= fuzzmask;
*p_rng_cr = cr;
Serial.print("Setting CR to ");
Serial.println(cr,HEX);
how_fast_is_it(1);

for(i=0;i<100;i++) {
x = read_output_reg_busy_waiting();
x = x & fuzzmask;

//Serial.print("Fuzzing CR with 0x");
//Serial.println(x,HEX);
cr = *p_rng_cr;
cr &=~fuzzmask;
cr |= x;
*p_rng_cr = cr;
Serial.print("Setting CR to ");
Serial.println(cr,HEX);
how_fast_is_it(1);
}
}
 
Using the "#" icon on posting puts HTML code markers that keeps code formatting.

Posted code seems to use the same process as the linked code as far as I looked - where PJRC has the register info in #define in kinetis.h for the Arduino sketch.

Running the linked post #12 code looks to get the same number of per second returns 7509974.00 if I'm reading it right.

Good the initial look shows it to be random'ish - if 'slow'.
 
I can now move on with what I intended to do, which is test the RNG. My primary area of expertise is designing and testing RNGs.

I'm really curious to hear whatever you discover.

Teensy 3.5 & 3.6 have hardware random number generators. The other boards do not.

All Teensy (and most Arduino) boards can use the Entropy library, which generates random numbers by looking at the jitter from a slow on-chip RC clock, relative to the fast & highly stable system clock derived from the crystal. In Arduino, click File > Examples > Entropy to get started. Or edit any of those and adjust your makefile to use the lib.

I believe we talked of this on Twitter some time ago. Here's the very simple test code which gives you the raw data (before whitening) of the Entropy lib.

https://gist.github.com/PaulStoffregen/965c0676ee34bd55b2f6c23e992a0ed3
 
Well the raw data seems to be slightly biased.

I spend a couple of days gathering 4 Mbytes of data.
It is very slightly biased. Chi-Sq TOR can't pick it up with single bit symbols, but it manages with multi bit symbols, since the difference between the all-ones and all-zeroes symbols are magnified.

$ djent -b trd.bin -l 1 | grep Chi
Chi square: symbol count=67746065, distribution=2.54, randomly exceeds 11.11 percent of the time
$ djent -b trd.bin -l 2 | grep Chi
Chi square: symbol count=33873032, distribution=19.36, randomly exceeds 0.02 percent of the time
$ djent -b trd.bin -l 3 | grep Chi
Chi square: symbol count=22582022, distribution=18.10, randomly exceeds 1.15 percent of the time
$ djent -b trd.bin -l 4 | grep Chi
Chi square: symbol count=16936516, distribution=62.08, randomly exceeds 0.00 percent of the time
$ djent -b trd.bin -l 5 | grep Chi
Chi square: symbol count=13549213, distribution=42.01, randomly exceeds 8.96 percent of the time
$ djent -b trd.bin -l 6 | grep Chi
Chi square: symbol count=11291011, distribution=122.06, randomly exceeds 0.00 percent of the time
$ djent -b trd.bin -l 7 | grep Chi
Chi square: symbol count=9678010, distribution=149.59, randomly exceeds 8.35 percent of the time
$ djent -b trd.bin -l 8 | grep Chi
Chi square: symbol count=8468259, distribution=1332.43, randomly exceeds 0.00 percent of the time

Consistent with that it fails the random excursion (number of crossings of the zero line), serial (string lengths) and approximate entropy (most common value) tests in SP800-22.

monobit_test 0.111096556291 PASS
frequency_within_block_test 0.270155284228 PASS
runs_test 0.0917160311609 PASS
longest_run_ones_in_a_block_test 0.185515416202 PASS
binary_matrix_rank_test 0.938723051738 PASS
dft_test 0.956610285741 PASS
non_overlapping_template_matching_test 1.00819422569 PASS
overlapping_template_matching_test 0.189215116909 PASS
maurers_universal_test 0.999965020915 PASS
linear_complexity_test 0.317213325905 PASS
serial_test 0.00320102555151 FAIL
approximate_entropy_test 0.0032057320016 FAIL
cumulative_sums_test 0.0462961221243 PASS
random_excursion_test 0.00979330529828 FAIL
random_excursion_variant_test 0.0159493261995 PASS

It's not very biased though. Entropy is safely above 0.9, so suitable for feeding into a 2X extraction ratio seeded entropy extractor, like CBC-MAC or HMAC.

$ djent -b trd.bin -l 1 | grep Mean
Mean = 0.499903
 
Manitou, DIEHARDER and SP800-22 are PRNG distinguishability tests. They test if the data can be distinguished from perfect randomness. The code from Paul collects entropic data that cannot be perfectly random and we are better off using a different class of test which measures the entropy and returns a number rather than a pass/fail. A number of algorithms for this are in SP800-90B.

The reason is that in a full RNG, the entropy source should feed an entropy extractor that squishes the data into perfect randomness. That extractor output may be used as a seed to a PRNG or directly as key material. So at the output of the entropy source, use statistical metrics. At the output of the extractor and PRNG, use distinguishability tests.

If you have unprocessed entropy source output (sometimes call raw entropy) that appears to be very high quality, then the SP800-22 tests are useful to determine what kind of deviation from perfect randomness the data has, because bias will cause certain tests to fail, serial correlation will cause other tests to fail, non stationarity will cause other tests to fail. So if you understand the inner workings of the tests, you can use them as a diagnostic tool like I did above.

In my tests above and with a few other tests I concluded the only measurable defect was bias. There might be serial correlation and I have a custom test for detecting weak serial correlation that that's described in my book on random numbers, so I won't be using that until the book is published in 2018.
 
Status
Not open for further replies.
Back
Top