K66 Beta Test

Status
Not open for further replies.
I'm still getting 'Crashes' at 24 and 48? Upload and then BUILTIN_LED it just ON.

FrankB - did you test to work? If so then I haven't gotten everything right on my end.

Closed IDE, I got the updates to Cores (as best I could**) and the new 'crashes??' Boards.txt.

**I've hesitated saying this for some time again - but Github and I do not get along!
 
manitou said:
I2C scan works with prop-shield, but onehorse prophshield sketch won't compile (i2c_t3 lib ?)
Click to expand...

I hacked up i2c_t3 .h and .cpp files, adding defined(__MK66FX1M0__) everywhere there was a defined(__MK20DX256__). That allowed me to compile onehorse's propshield sketch (https://github.com/kriswiner/Teensy_Prop_Shield) and run it on K66 (madgwick with invSqrt()).

Code: 
             teensy3.2    K66   K66    dragonfly
              @120mhz    @120  @180      @80
rate (hz)       1195     2580  2664      2223
madgwick(us)     208        7     4        17
Rate is dominated by the I2C queries and data fetch in the loop.
 
Last edited:
Frank's patch fixed 24 & 48 MHz here.

Within the next 24 hours I'll create a 1.29-beta3 installer that rolls up all these and other fixes.
 
sumotoy said:
Nevermind. SPI1 and SPI2 for KINETISK are currently not present inside SPI.cpp
Trying to update SPI library...
Click to expand...
I was wondering about that, it was something else I was wanting to take a look at.

I am also wondering about Strategy of using these as well.

Example suppose I wish to use an ILI9341 display on SPI1. Actually probably won't work as from my Excel document: I see
for SPI1 You can choose SOUT=0 or 21, SIN=1 or 5 SCK=20 or 32 and CS0 = 6 or 31

As I think there is only one CS pin (actually 2, but since both labeled as: SPI1_PCS0 I think they are the same signal.

But suppose that 6 and 31 are different.

Should we for example change the ILI9341_T3 constructor (ILI9341_t3(uint8_t _CS, uint8_t _DC, uint8_t _RST = 255, uint8_t _MOSI=11, uint8_t _SCLK=13, uint8_t _MISO=12);)
if you pass in something like: ILI9341_TC(6, 31, rst, 0, 1, 20);
It detects that all 5 of these IO pins are on SPI1 object and code is changed to use SPI1 object instead of SPI object?
 
Updated my 'Only_qBlink' example to take input to see it work and write in loop() with adjustable 'delay()' between writes.

Not sure if this means I lost the battle with GitHub - or if there are missing bits on GitHub?
<edit> - it must be GitHub on Windows ??? . . . I see this on the web which GitHub Windows won't give me (GUI 'Sync' or 'Git Pull'?):
#if F_CPU == 240000000
1551 uint32_t n = usec * 80;
1552 #elif F_CPU == 216000000
1553 uint32_t n = usec * 72;
Click to expand...

UPDATE - I pulled the ZIP of CORES and dumped it and all is well :: 240, 24, 48 MHz!!!! Thanks FrankB and Paul! I think you can take off 'crashes??' in boards.txt.

View attachment Only_qBlink.ino
 
Last edited:
manitou said:
Re: RNG register addresses

@Paul et al, my "bug" (post #179) for RNG register addresses in kinetis.h needs to be revisited. As it turns out (who knew? -- actually Paul may have known from comments in kinetis.h) there are TWO ways to enable the RNGA peripheral, one using SIM_SCGC3 and one using SIM_SCGC6. The first maps to the original RNG addresses in kinetis.h, the 2nd (which I used in example sketch) maps to the 0x40029000 addresses. So if i had used SIM_SCGC3, all would have been well! (I have since tested both mappings).

Paul, I fear the recent fix you applied to kinetis.h based on my assertion has put things askew, because you have commented out the SIM_SCGC6_RNGA. So I would be tempted to return things as they were, and I should update my example to use SIM_SCGC3 and your original register addresses.
Click to expand...

Let's standardize with using SIM_SCGC6_RNGA

https://github.com/PaulStoffregen/cores/commit/7c963d5269787499ccec430a5f286129ab82cb3c

When/if we get a chip with the superior RNGB, it'll probably use SIM_SCGC3, based on the other chips which have RNGB.
 
defragster said:
**I've hesitated saying this for some time again - but Github and I do not get along!
Click to expand...
I know the feeling!... :lol:

Warning I am absolutely no GIT expert! But thought I would mention what I do on the off chance it might help.

Not sure which OS you are working on, but on windows using github for windows does make life a little easier, although I bypass it for certain things. I also use the MAC version from time to time. I also had to learn some tricks when I was working on some of the libraries associated with the Intel Edison...

Things like: When I am making changes like this to Cores project, I actually have two clones on my development machine. One that is directory cloned from Pauls github project, such that I can do a sync and see what he has. I also forked his project so up on github is KurtE\Cores, which I also cloned to my development machine.

When working on projects like this, I never make the changes on the Master branch. I create a new branch, where I upload my changes. Some of the other projects want you to create new branches for every change so they can pick and choose. When ready, then issue a pull request, to Paul's master. When the changes have been merged, you can then delete your temporary fork. (Actually if Paul does the merge and close the pull request, the system can automatically delete your fork, but...)

Then when desired I sync my master branch back to what Paul has. The new github for windows version has some stuff in there to do that, which I have tried, but then it creates one big delta, and then it will say you are one +1 change to Paul's master. So instead I use my sledge hammer approach and run a script which does:
Code: 
cd \Users\Kurt\Documents\GitHub\Cores
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
But warning if you are on a different branch than master and/or have local changes still on your machine that have not been checked in, this script will completely wipe out anything that is not checked in, or if there were other modifications made by you in master branch. This also assumes you have setup the git remote upstream before.

Again not sure if this helps, but...
 
UPDATE - I pulled the ZIP of CORES and dumped it and all is well :: 240, 24, 48 MHz!!!! Thanks FrankB and Paul! I think you can take off 'crashes??' in boards.txt.

I have my posted sketch working at 24 and 48 MHz.

Thanks KurtE - I'll look into applying your process on my windows machine.

Now I have to figure out why my Prop_LC amp is GOING HOT so I can get back to testing.
 
manitou said:
UPDATE
The problem i had with my SDHC sketch was wrong GPIO pin setting for test pin in my driver (pin 12 on mbed not same as pin 12 on teensy K66). So I was able to correctly read a 512-byte sector from microSD card, took 305us (13.4 mbs):D

(this is low-level sector-read testing -- no FAT file system. FAT file system would utilize the sector read/write stuff) == proof of concept

From the URL to the mbed K64 testing, a lot of the "IO time" is spent waiting for DLA to become inactive. With analyzer on K66, the 2nd DLA wait time was 252us, and actual sector transfer time was 43us (= 97mbs) for 4-bit SDIO. F_CPU=96mhz

using SanDisk 8GB microSD
Click to expand...

Any chance you could post this code? I'd love to give it a try here. ;)
 
manitou said:
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.
Click to expand...

Any comments or corroboration on the misbehaving ADC pins? I also fed DAC at 1.6 v into each ADC pin, A0-A9 reported 512, the other ADC pins did not change their value?
 
PaulStoffregen said:
Any chance you could post this code? I'd love to give it a try here. ;)
Click to expand...

It's a hack, see https://github.com/manitou48/teensy3/tree/master/sdhctst
Commented and ifdef'd some things out. DO_ORIGINAL and DO_FIFO work about the same speed. DO_DMA does not work.
the first file on my microsd was raw.dat with bytes in ascending sequence, and the sketch does an error check based on that, and i hard coded the sector number. but it's something to start with. i used pin 12 with the logic analyzer to see where time was spent. i never got multi-sector reads to work.

it's based on brtos, see https://forum.pjrc.com/threads/24633-Any-Chance-of-a-Teensy-3-1?p=103556&viewfull=1#post103556

utasker also has a more robust driver (timeouts and retries)

good luck
 
manitou said:
Any comments or corroboration on the misbehaving ADC pins?
Click to expand...

I'm working on analogRead right now. A0-A9 work. All others are currently broken. I plan to have this fixed later today....

My current test sketch:

Code: 
void setup() {
  for (int i=0; i<=39; i++) {
    pinMode(i, INPUT_PULLDOWN);
  }
}

void loop() {
  for (int i=14; i<=23; i++) {
    Serial.print(analogRead(i));
    Serial.print(" ");
  }
  Serial.print(" ");
  Serial.print(analogRead(A10));
  Serial.print(" ");
  Serial.print(analogRead(A11));
  Serial.print("  ");
  
  for (int i=31; i<=39; i++) {
    Serial.print(analogRead(i));
    Serial.print(" ");
  }
  Serial.print(analogRead(A21));
  Serial.print(" ");
  Serial.print(analogRead(A22));
  Serial.println();
  delay(75);
}
 
About SPI, just a placeholder for testings....
Code: 
    #if defined(__MK64FX512__) || defined(__MK66FX1M0__) //Teensy 3.4/3.5
        if ((_mosi == 11 || _mosi == 7) && (_miso == 12 || _miso == 8) && (_sclk == 13 || _sclk == 14)){
            // SPI
        } else if (_mosi == 9 && _miso == 1 && _sclk == 32){
            // SPI1
        } else if (_mosi == 45 && _miso == 44 && _sclk == 46){
           // SPI2
        }
    #elif defined(__MK20DX128__) || defined(__MK20DX256__) //Teensy 3.0/3.1/3.2
        if ((_mosi == 11 || _mosi == 7) && (_miso == 12 || _miso == 8) && (_sclk == 13 || _sclk == 14)) {
           // SPI
        }
    #elif defined(__MKL26Z64__) // Teensy LC
        if ((_mosi == 11 || _mosi == 7) && (_miso == 12 || _miso == 8) && (_sclk == 13 || _sclk == 14)) {
           // SPI
        } else if ((_mosi == 0 || _mosi == 21) && (_miso == 1 || _miso == 5) && (_sclk == 20)) {
            // SPI1
        }
    #endif
 
Hi Paul,

here's a pullrequest for 180MHz USB

https://github.com/PaulStoffregen/cores/pull/141

It works for me, but pls try carefuly and look at the timing, esp. the divisors - it's too late here ..

Good night .-)

Edit: forgot..maybe whe have to tune the linker-file - i got errors during development and moved

startup after flashconfig:

Code: 
/* Teensyduino Core Library
 * http://www.pjrc.com/teensy/
 * Copyright (c) 2013 PJRC.COM, LLC.
 *
 * Permission is hereby granted, free of charge, to any person obtaining
 * a copy of this software and associated documentation files (the
 * "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sublicense, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * 1. The above copyright notice and this permission notice shall be 
 * included in all copies or substantial portions of the Software.
 *
 * 2. If the Software is incorporated into a build system that allows 
 * selection among a list of target devices, then similar target
 * devices manufactured by PJRC.COM must be included in the list of
 * target devices and selectable in the same manner.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 * SOFTWARE.
 */

MEMORY
{
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1024K
    RAM  (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 256K
}


SECTIONS
{
    .text : {
        . = 0;
        KEEP(*(.vectors))
        
        /* TODO: does linker detect startup overflow onto flashconfig? */
        . = 0x400;
        KEEP(*(.flashconfig*))
        *(.startup*)
        *(.text*)
        *(.rodata*)
        . = ALIGN(4);
        KEEP(*(.init))
        . = ALIGN(4);
        __preinit_array_start = .;
        KEEP (*(.preinit_array))
        __preinit_array_end = .;
        __init_array_start = .;
        KEEP (*(SORT(.init_array.*)))
        KEEP (*(.init_array))
        __init_array_end = .;
    } > FLASH = 0xFF

    .ARM.exidx : {
        __exidx_start = .;
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
        __exidx_end = .;
    } > FLASH
    _etext = .;

    .usbdescriptortable (NOLOAD) : {
        /* . = ORIGIN(RAM); */
        . = ALIGN(512);
        *(.usbdescriptortable*)
    } > RAM

    .dmabuffers (NOLOAD) : {
        . = ALIGN(4);
        *(.dmabuffers*)
    } > RAM

    .usbbuffers (NOLOAD) : {
        . = ALIGN(4);
        *(.usbbuffers*)
    } > RAM

    .data : AT (_etext) {
        . = ALIGN(4);
        _sdata = .; 
        *(.fastrun*)
        *(.data*)
        . = ALIGN(4);
        _edata = .; 
    } > RAM

    .noinit (NOLOAD) : {
        *(.noinit*)
    } > RAM

    .bss : {
        . = ALIGN(4);
        _sbss = .;
        __bss_start__ = .;
        *(.bss*)
        *(COMMON)
        . = ALIGN(4);
        _ebss = .;
        __bss_end = .;
        __bss_end__ = .;
    } > RAM

    _estack = ORIGIN(RAM) + LENGTH(RAM);
}
 
Last edited:
K66 Beta board working with USB at 24, 48, 180, 216, 240 MHZ. [runs at 16 MHz - with no USB as expected]

Running the original manitou RNG sketch and the read/write Only_qBlink.ino with the last pulled GitHub ZIP, and updated p#271 mk20dx128.c and kinetis.h !

RNG bit speeds at 240 match those at 180 so that clock is right. If I read posts right that is the kinetis.h register 'name' set (from manitou) you plan to work with.

Talkie may be a bit scratchy (haven't hooked up T_3.2 to compare)? Susan Vega Diner clearly not going well - ( with first-PJRC-Version TALKIE or as shipping ). Talkie plays almost as well or better at 16MHz as 240 MHz now, some clock changes may have altered that? 16 MHz it seems was noted as bad last night - where pitch/speed was off - same now.

Paul: I ran wires to my headered Beta Prop_Wit (5V, 3.3V, DAC/33, GND, pin 5) and it sounds similar and the AMP does not go HOT. Is there a reason my good looking Prop_LC would hit 120° in 10-15 seconds after powering Pin 5 AMP? Defective or user damage? I ordered two - I could try the other?
 
A brief test indicates that all of these work:
delay
delayMicroseconds
millis
micros
elapsedMillis
elapsedMicros
Keyboard.print
IntervalTimer
analogWrite
pulseIn
 
Last edited:
jonr said:
A brief test indicates that all of these work:
delay delayMicroseconds millis micros elapsedMillis elapsedMicros
Click to expand...

Cool - I was wondering about testing them against an external clock. Felt bad for using delay() instead of elapsedMxx()'s. The Talkie is timed so internal timing important for sample rate output.

Is there a way to get second or subsecond interrupt timing feedback from the independent RTC time crystal hardware? My glance at the FM didn't suggest there was.
 
Status
Not open for further replies.
Back
Top