K66 Beta Test

Status
Not open for further replies.
I came up with this in mspaint as a suggestion:
ks2016cardB.png

Removed the 'YOU ARE HERE' line at the top , took out 'please' and made one line for the bottom and gave the room to cut and paste in the colored label blocks with the central portion unchanged?

<edit> labels cut from T_3.1 card - no CAN bus or other detail updates made.
 
Last edited:
I think for now I'm going to leave the card to emphasize traditional computer requirements. I'm a bit conflicted about whether to really recommend such underpowered computing as a serious way to develop projects.
I understand especially since you only have so much room on the card: However it may depend on needs and which ARM you are using. Example Odroid XU4 with 8 cores, 4 of which run at 2ghz builds stuff not much slower than my main dev machine.

For me it is more of a secondary thing. It is nice to have the ability to VNC into the Odroid, bring up the Arduino stuff and reprogram a Teensy that is plugged into one of it's USB ports, without having to touch any of the cables.
 
The Teensy card measures 4.25 x 6 ". Perhaps make an ONLINE printable 5x7" card PDF that will print and fold to hold the version with the added details.

You could note that on the card and have it ready in time to ship - a larger size T_3.5/T_3.6 card at : www.pjrc.com/teensy/
 
I don't BSOD below has anything to do with what seems to be a HDD issue ...

BSOD::
I did what I suggested - I got blinks on power up. All was well. Then I just turned on the LED in pins_teensy.c [same delay(400)] and in setup made my while(!Serial) and it sat and waited, rather than timing out after the wait. Two T_3.6's cabled to desktop USB ports, no hub.

...

Quick update to my BSOD (win_10 style):

I unplugged my new USB_3 powered HUB ( that had nothing plugged into it) and my machine has booted - after two more reboots for Win_10 to clear cobwebs?
<edit>: that was the first reboot since I put that HUB on the computer

In my web search last night I saw this - that made me think the HUB might be doing something as it has a RED charge port of some sort:

"(program that it's used for Apple connections) which (based on the its website) is a USB power station for charges"

I have nothing Apple on this machine - and it may be co-incidence - but it suggests to me that USB not acting right can indeed mess stuff up.

More later - time to donate some blood . . . then I'll do the initial test again - tempting fate . . .
 
Last edited:
Teensy 3.6 pins are
not 5 volt tolerant.
Do not apply more
than 3.3 volts.

I think this part should be in red or at least this "Teensy 3.6 pins are not 5 volt tolerant." so this catches the eyes.
 
Quick update to my BSOD (win_10 style):
... More later - time to donate some blood . . . then I'll do the initial test again - tempting fate . . .

Okay got back tested FASTLED on TD 1.30b4 to work with T:3.1, 3.2, 3.5, 3.6.

Shutdown my machine per Koromix - plugged in the K66_PROTO to USB with LED on and Serial wait - machine did the BLUE SCREEN again (as above). Unplugged Teensy and it self restarted and came up working where I am now?

Same device - When not "while(!serial)" waiting caused no such problems in my small set of test cases. I built this machine Jan 2011 and it has never done this before.
 
Paul,
Back to the Cards: I think on both of them you could/should mark pin 45 as also CS0 as it is the only one that is SPI0_PCS5

In process of adding it to SPI library code as I add some additional SPI0 support for pins 39, 28, 27...

Kurt
 
And they look like???? Unchanged from the last post?

Cool, one more thing done! . . . a few thousand more to do . . .

120 new backer in the last 16 hours . . . at that rate there will be a doubling of backers too!

30 hours left I see 6,160 Teensy units requested!
> 2195 T_3.5's
> 3965 T_3.6's
 
Cool - I'll put these on the sticky posts:
KS_T_3.5f.PNGKS_T_3.5b.PNGKS_T_3.6.jpg

This PDF does not have the final correct T_3.5 card backside - subnote has error saying 5V on pins that cannot take over 3.3V
View attachment KS_Teensy_sm.pdf
Paul : Here is a combined SMALLER PDF of all four card sides. {390KB}
 
Last edited:
Cool: Will download and print my own one from it!

FYI - Going over the cards and the like found the SPI code did not have stuff in place for the new Miso/Mosi/SCK pins on SPI(0), So Took a pass through doing it, Which I hit a few different files:

Updated Cores (new Miso/mosi/sck pins): https://github.com/PaulStoffregen/cores/pull/173
Updated SPI (New CS pin): https://github.com/PaulStoffregen/SPI/pull/20
Updated ILI9341_t3: https://github.com/PaulStoffregen/ILI9341_t3/pull/31

I also updated my SPIN library: https://github.com/KurtE/SPIN

Which I use in my version of ILI9341_t3n library: https://github.com/KurtE/ILI9341_t3n
to be able to be used on all of the SPI busses and works OK with just on hardware CS. No changes needed here as the check for valid MISO/MOSI/SCK is done in SPIN. Actually would be nice to add it instead to SPI library like the is valid CS calls.

Anyway with all of these changes I was able to get my PJRC touch screen working with ILI9341_t3 library on the new pins:
Code:
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC, 6, 28, 27, 39);

I first tried it on my library with pins (11, 12, 13) then (7, 8, 14), and then 29, 39, 27
 
Paul my post 1312 has a <400KB single PDF of all four files as combined by ADOBE.

<edit> I'm swapping my sticky links. So you can delete you files and point to that post as you chose
 
Last edited:
Perhaps make an ONLINE printable 5x7" card PDF that will print and fold to hold the version with the added details.

Maybe a PDF print-it-yourself (on either Letter or A4 paper) pinout chart could show much more, but hopefully in a way that's not too confusing.

Honestly, after the last several days fiddling with the card, my appetite for more of this probably won't recharge for a while. Maybe someone else would like to take this on?
 
I can reliably prevent my Teensy 3.6 (round 3) from starting, with the Blink sketch loaded on the board, when I:
- shut down the computer and remove the power cord
- wait a bit for the capacitors to drain, until the plugged in Teensies stop blinking (and then wait a bit more)
- plug it back, and then start the computer

My Teensy LC and my 3.1 start as soon as I plug the power in. My 3.6 (round 3) does not, even after powering the computer. lsusb won't show anything. I checked and there's 5V at Vin / GND. Pressing the bootloader button loads HalfKay, as expected. I tried 180 MHz and 120 MHz, no difference.

I have seen it fail to start at least once when I plugged it in my MacBook, I think, but I cannot reproduce that.

Koromix:
With LED on as noted in pins_teensy.c I always see that light as soon as power is applied, even on my machine that goes to BSOD. I have a freshly formatted Win_7 machine upgraded to Win_10 that does the same with no side effects. My setup() toggles the LED OFF then ON twice so I know it got there as well and then the light stays on while waiting for a Serial client - TYQT - to open and start the connection and then it proceeds to print the alphabet from "A" as my sketch is designed.

Just put I:\arduino_16_11\examples\01.Basics\Blink onto the beta3 K66 and it comes up blinking on the 2nd virgin machine. With and without my edit to pins_teensy.c.

Just put on my USB_3 hub (on usb 2 port) and also my old USB 2 hub on that machine and no problems.

Both T_3.6 boards on that formerly virgin machine. At default 180 MHz Compiled a fresh blink and my Fastled CYLON to the boards with TD_1.30b4. Both come up running the instant power is applied.

Have you done the same upload using TeensyDuino as loader? Any change if you turn on LED early in pins_teensy.c?
 
Paul, can you say some words regarding your plans for SD-card support ?
I guess, for compability-reasons (Teensy 3.2, audiolibrary!, existing sketches) we still need a Sd.h.
Both existing libs (WMXZ and Bill) for sdio work, but both need some additional work to use them as replacement for Sd.h
 
Last edited:
Kurt - I'll get fresh copies of those and see what my T_3.5 does. {do I just need SPIN and ILI9341_t3n - or core edits too?}

I updated the T_3.5 post #1 with card image: K64-Beta-Test-Teensy-3-5

And the T_3.6 post #8 with card image: K66-Beta-Test
To use the standard ILI9341_t3 on Standard SPI (and not SPI1 and SPI2) with two hardware CS pins, and you wish to use some of the new SPI0 pins that were missed, you will only need, my updated copy of ILI9341_t3 library as well as the changes to cores.

You might pick up the updated SPI library as well, but this simply ads the new "errata" ;) SPI cs pin 45

As for SPIN... This may be semi off topic, but will try to explain:

You don't need Spin and my corresponding version display library ILI9341_t3n. I created them to allow me to use the code on the other SPI busses. To do this I create a virtual base class for SPI objects:
Code:
class SPINClass {
public:
    // Initialize the SPI library
    virtual void begin() = 0;
    virtual void usingInterrupt(uint8_t n) = 0;
    virtual void usingInterrupt(IRQ_NUMBER_t interruptName) = 0;
    virtual void notUsingInterrupt(IRQ_NUMBER_t interruptName) = 0;

    // Before using SPI.transfer() or asserting chip select pins,
    // this function is used to gain exclusive access to the SPI bus
    // and configure the correct settings.
    virtual void beginTransaction(SPISettings settings) = 0;

    // Write to the SPI bus (MOSI pin) and also receive (MISO pin)
    virtual uint8_t transfer(uint8_t data) = 0;
    virtual uint16_t transfer16(uint16_t data) = 0;
    virtual void transfer(void *buf, size_t count) = 0;

    // After performing a group of transfers and releasing the chip select
    // signal, this function allows others to access the SPI bus
    virtual void endTransaction(void) = 0;
    virtual void end() = 0;

    virtual void setBitOrder(uint8_t bitOrder) = 0;
    virtual void setDataMode(uint8_t dataMode) = 0;
    virtual void setClockDivider(uint8_t clockDiv) = 0;

    // Teensy 3.x can use alternate pins for these 3 SPI signals.
    virtual void setMOSI(uint8_t pin) = 0;
    virtual void setMISO(uint8_t pin) = 0;
    virtual void setSCK(uint8_t pin) = 0;
    // Added ones that are not part of SPI (yet)
    virtual bool pinIsMOSI(uint8_t pin) = 0;
    virtual bool pinIsMISO(uint8_t pin) = 0;
    virtual bool pinIsSCK(uint8_t pin) = 0;

    // return true if "pin" has special chip select capability
    virtual uint8_t pinIsChipSelect(uint8_t pin) = 0;
    virtual bool pinIsChipSelect(uint8_t pin1, uint8_t pin2) = 0;
    virtual uint8_t setCS(uint8_t pin) = 0;

    // Add helper functions from ILI9341, which manage SPI FIFO
#if defined(KINETISK)
    virtual KINETISK_SPI_t *kinetisk_spi (void) = 0;

    virtual uint8_t sizeFIFO() = 0;
    virtual void waitFifoNotFull(void) = 0;
    virtual void waitFifoEmpty(void) = 0;
    virtual void waitTransmitComplete(void)  = 0;
    virtual void waitTransmitComplete(uint32_t mcr) = 0;
#endif
};
A lot of the base class is straight out of SPI classes. Somethings I added included pinIsMOSI... like functions that SPI class has for testing pinIsChipSelect. So that all of the classes that use it don't have to replicate the testing. Would be nice to add it to base SPI code.

The other things I added to the class was some FIFO functions, from the ILI9341_t3 library. These were added as I saw other code bases copy this stuff, plus it needs to be changed depending on which SPI buss you are on, as SPI1 and SPI2 have a queue of only 1 item. So was able to get code to work on SPI1 which only had 1 hardware CS pin (now can have more with SDcard pin). Works pretty well with only 1 used on DC pin...

Again you don't need these two libraries, although I wonder if any of this should be merged into mainline code...

Hope I answered the question

Edit: P.S. - Earlier I had a test setup where I had 3 ILI9341 displays hooked up to the T3.6 board all running on different SPI ports.
 
Teensy 3.5 Card: "Do not apply more than 5 volts to A10, A11, A21, A22, A25, A26, AREF, Program or Reset".

Did you really mean to say 5 V here, or 3.3V ? If the card is correct, what is the voltage limit on the other pins?
 
DOH!!!!

I called the printing company just now and they're (probably) going to be able to get a revised file in to fix this.

Thanks for pointing this out so quickly. :)
 
DOH! - OUCH - I'll go update the many views I've posted given he updated T_3.5 PDF . . .

My small PDF is wrong as noted above - but I took the KS T_3.5 card faces for use where those were exposed on this thread and the K64 thread
 
Last edited:
Honestly, after the last several days fiddling with the card, my appetite for more of this probably won't recharge for a while. Maybe someone else would like to take this on?

Not as pretty as the card, but with a bit more information (I2S, Ethernet, Native Port)

screenshot.png

It's a LibreOffice Calc file (*.ods) which you can download here:
https://www.dropbox.com/s/23yl6hxqmp0h2u9/T3.6pinoutDiagram.ods?dl=0

So far I compiled the info from Pauls official card and what can be found in this picture in Post #8:
View attachment 7888


Ben
 
Noteworthy SIDE NOTE: It seems that K66 EEPROM reads DO work at 180 MHz?, only writes are inhibited?

Any progress on EEPROM Writes?

If I understand the code properly, it looks like the eeprom_initialize more or less maps all of the EEPROM into memory address.

Note sure when this is called. My guess is it first gets called by the constructor for the EEPROM class. Not sure if this constructor is called before the code that switches the processor into HSRUN mode? I never played around in this part of the code before.

Looks like lots of opportunities to learn :D
 
Any progress on EEPROM Writes?
...

that would be - negative. This is as far I've gotten 'in a very not specific hand wavy sort of way' - maybe there is a better solution?::

> throttle down the clocks - go to runmode=0 normal
> perform the EEPROM writes
> {optional} RESTART { or } repeat what PJRC does in mk20dx128.c to: Set runmode=3 HSRUN again, restore/bring up the needed clocks.

In the process any in progress I/O or bus work will be messed up, and the buses themselves may need restarted once back up to speed.

So the safest way would be to scrub the speed and leave HSRUN, as long as RAM stays intact, update the EEPROM from RAM values and restart fresh.

I'm not sure if pretending to do a DUFF SNOOZE to VLPR leaves RAM intact dropping to a some low speed? I saw Manitou has tested Snooze to work, but I've not gotten to that myself. Maybe just getting the CPU under 120 MHz and setting HSRUN(0) would work? To write 4KB safely at this point a few hundred ms would not be an issue as long as it works to get the right data stored for use on restart.

Then writing the needed EEPROM updates, and asking for an MCU restart to Normal HSRUN mode where the new EEPROM values would be ready for use?


This would be DRASTIC - but better than "going OFFLINE":: writing the data to SD card or USB_Serial to save it - load a low speed write sketch - program the EEPROM ( SD or data in from USB/HID like TeensyTransfer or manual transfer } then reload the target sketch. And as long as this can work for the 'end use' - it would allow some value in the EEPROM as long as the need to change it was RARE enough

Other wise it would involve duct taping an I2C EEPROM to the bottom of a T_3.6 and using SDA3/SCL3 pins - or similar solution maybe with SPI2 to have usable EEPROM space.

From the Serial# work in this code I learned that the MCU and PINS are not ready for use - so the device cannot pause before HSRUN is set - read the data from anywhere ( RAM is BLANK at best - from what I read/inferred the "C" startup for USER code has not even executed. ) and push the update to EEPROM and then got to HSRUN, because it isn't until the MCU hits HSRUN that the rest of the T_3.6 is initialized and brought online: Clocks/Interrupts/RAM etc.
 
Status
Not open for further replies.
Back
Top