K64 Beta Test :: Teensy 3.5

manitou · Sep 2, 2016

KurtE said:
Found the problem. DMA channel for SPI0 was improperly set in header file.

Fixed: Pull request https://github.com/PaulStoffregen/cores/pull/170

yep, i just saw that in k64 ref table 3-27

After editing kinetish.h, DmaSpi example works with SPI0 on K64

How do I test with SPI1, i tried replacing DMASPI0 with DMASPI1 (jumpered 0 to 1), src and dest don't match? non-DMA works with SPI1

EDIT: SPI1 and DMASPI1 with 0 to 1 works on K66

K64 DMA MUX table shows
16 SPI1 Transmit or Receive
17 SPI2 Transmit or Receive
that doesn't seem hopeful.

Frank B · Sep 2, 2016

defragster said:
...

Tim, i have a display that does not work anymore. It was in my drawer. Last time i used it - some weeks ago - it was working. When i tried it today, it was white too.. I took a new one, and this worked instantly.

KurtE · Sep 2, 2016

Hi defragster and Frank. As I mentioned I have had some of the cheaper ILI9341 displays not work unless I hooked up Reset. I know the PJRC version you need to either wire the pin up to 3.3v or you need to drive it by an IO pin, as it does not have an internal PU like the Adafruit one does. I also had an issue when I wired one up when I forgot to put the resister in, in between power and the backlight pin.

Manitou: I will also play some with the SPI1 and 2 as well. Yep see the same table. So looks like the header file needs to change, plus maybe changes to dmaspi. Or maybe define constants for both
DMAMUX_SOURCE_SPI2_RX and DMAMUX_SOURCE_SPI2_TX that both have same value likewise for SPI1...

I have defined:

Code:

#define DMAMUX_SOURCE_SPI0_RX		14
#define DMAMUX_SOURCE_SPI0_TX		15
#define DMAMUX_SOURCE_SPI1_RX		16
#define DMAMUX_SOURCE_SPI1_TX		16
#define DMAMUX_SOURCE_SPI2_RX		17
#define DMAMUX_SOURCE_SPI2_TX		17

Built like you mentioned and tried with SPI1/DMASPI1... Has lots of failures:

Code:

Hi!
Buffers are prepared
Time for non-DMA transfer: 234us
src and dest match

Press a key to continue

DmaSpi::begin() : DmaSpi::start() : state_ = eStopped
DmaSpi::beginNextTransfer: no pending transfer
Transfer @ 0x2001fee8
Testing src -> dest, single transfer
--------------------------------------------------
Transfer @ 0x2001ff20
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  real source
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001fee8
  state = eRunning
DmaSpi::beginNextTransfer: no pending transfer
Finished DMA transfer
src and dest don't match
 src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
dest: 0x63 0x63 0x63 0x63 0x63 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
==================================================


Testing src -> discard, single transfer
--------------------------------------------------
Transfer @ 0x2001ff3c
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  dummy sink
  real source
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001fee8
  state = eRunning
DmaSpi::beginNextTransfer: no pending transfer
Finished DMA transfer
last discarded value is 0x2f
That appears to be wrong, it should be src[DMASIZE-1] which is 0x63
==================================================


Testing 0xFF dummy data -> dest, single transfer
--------------------------------------------------
Transfer @ 0x2001ff58
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  dummy source
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001fee8
  state = eRunning
DmaSpi::beginNextTransfer: no pending transfer
Finished DMA transfer
src and dest don't match
 src: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 
dest: 0x30 0x31 0x31 0x31 0x31 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 
==================================================


Testing multiple queued transfers
--------------------------------------------------
Transfer @ 0x2001ff74
Transfer @ 0x2001ff04
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  real source
DmaSpi::registerTransfer(0x2001ff04)
  DmaSpi::addTransferToQueue() : queueing transfer
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001fee8
  state = eRunning
DmaSpi::beginNextTransfer: starting transfer @ 0x2001ff04
  this was the last in the queue
  real sink
  real source
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001ff04
  state = eRunning
DmaSpi::beginNextTransfer: no pending transfer
Finished DMA transfer
Finished DMA transfer1
src and dest don't match
 src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
dest: 0xff 0xff 0xff 0xff 0xff 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
src and dest don't match
 src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
dest: 0x30 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 0x2f 
==================================================


Testing pause and restart
--------------------------------------------------
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  real source
DmaSpi::registerTransfer(0x2001ff04)
  DmaSpi::addTransferToQueue() : queueing transfer
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001fee8
  state = eStopping
Time until stopped: 492 us
Finished DMA transfer
DMA SPI appears to have stopped (this is good)
restarting
DmaSpi::start() : state_ = eStopped
DmaSpi::beginNextTransfer: starting transfer @ 0x2001ff04
  this was the last in the queue
  real sink
  real source
DmaSpi::rxIsr_()
  finishCurrentTransfer() @ 0x2001ff04
  state = eRunning
DmaSpi::beginNextTransfer: no pending transfer
Finished DMA transfer1
src and dest don't match
 src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
dest: 0x30 0x31 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
src and dest don't match
 src: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 
dest: 0x30 0x31 0x31 0x31 0x31 0x00 0x00 0x01 0x01 0x02 0x02 0x03 0x03 0x04 0x04 0x05 0x05 0x06 0x06 0x07 0x07 0x08 0x08 0x09 0x09 0x0a 0x0a 0x0b 0x0b 0x0c 0x0c 0x0d 0x0d 0x0e 0x0e 0x0f 0x0f 0x10 0x10 0x11 0x11 0x12 0x12 0x13 0x13 0x14 0x14 0x15 0x15 0x16 0x16 0x17 0x17 0x18 0x18 0x19 0x19 0x1a 0x1a 0x1b 0x1b 0x1c 0x1c 0x1d 0x1d 0x1e 0x1e 0x1f 0x1f 0x20 0x20 0x21 0x21 0x22 0x22 0x23 0x23 0x24 0x24 0x25 0x25 0x26 0x26 0x27 0x27 0x28 0x28 0x29 0x29 0x2a 0x2a 0x2b 0x2b 0x2c 0x2c 0x2d 0x2d 0x2e 0x2e 0x2f 
==================================================


Testing src -> dest, with chip select object
--------------------------------------------------
Transfer @ 0x2001ff90
DmaSpi::registerTransfer(0x2001fee8)
  DmaSpi::addTransferToQueue() : queueing transfer
  starting transfer
DmaSpi::beginNextTransfer: starting transfer @ 0x2001fee8
  this was the last in the queue
  real sink
  real source

Frank B · Sep 2, 2016

KurtE said:
Hi defragster and Frank. As I mentioned I have had some of the cheaper ILI9341 displays not work unless I hooked up Reset.

Hi Kurt, no, this display is broken.
The board I use connects reset to a teensy-pin, and the display is from the same batch (or, at least i bought them together) . I can't tell how this happended, and it i know that it worked last time i used it.

defragster · Sep 2, 2016

Frank - I had one go white just after I got it from PJRC - Robin replaced it ASAP. With nothing to lose I was going to use the SD portion and I jumpered the J1 per those directions and after that the display came back to life! Worth a try if you have that same style display as on the PJRC store with that jumper.

In the case of this 2.8" display it works on two T_3.6's, and a new 2.2" acts the same. Given the above posts I'm pretty sure I have a failing wire or connector - it got packed twice on my recent trip and there was enough pressure to bend over some of the jumper wire ends in the headers on the soldered Proto board.

Kurt - I have reset to 3.3V. I was going to run power direct to my LED and then jumper that to the VCC end connect to use my 8 connector plug.

Frank B · Sep 2, 2016

TIM: That closing J1 helped (?!?)- the display works now... thanks

Is that a voltage-regulator near J1 ? Maybe it is broken.

defragster · Sep 2, 2016

AWESOME - I shared my findings 2-3 times to others that 'saw white' and never got feedback that anyone else tried it at all.

I'll go solder that J1 on mine first - perhaps there is some factor causing that to work intermittently?

Voltage-regulator sounds like what I heard before with regard to that part that J1 bypasses.

Paul/Robin - did you consider moving this thread to Announcements from General Discussion for better visibility?

defragster · Sep 2, 2016

TYQT IS WORKING !!!!!!!! Both T_3.5 and T_3.6 !!!!
Current newest is TyQt-0.7.5-204-g33f592f-...

Update: I posted on the TYQT thread images showing multi devices, and I stopped using the HUB below.

Other Note: Something is still messing with the (long used) powered USB HUB - it may be tired - but it keeps going offline, mostly using TYQT RESET feature? Maybe it isn't responsive enough for the USB/HID/Program loop and is confusing something - then it is removed from the system and the HUB pilot light goes out. It is even weirder when TeensyDuino is active - it tried to program on reset - FLASH gets WIPED - then hub goes offline and the device is empty. I saw this on my Laptop before - but the hub didn't go away, now on my desktop it is. Tried with a T_3.1 and it really went weird - I had USBView running and that terminated . . . asking Koromix.

I soldered J1 on the 2.8" and 2.2" ILI9341 - still nothing but white on T_3.5 but works well on T_3.6 . . . ?

Though on handling and swapping the plug in board one more time back to 2.2" - the T_3.6 is a bit touchy - but either works or at least tries. It does show some failure of solid electrical connections.

I'll get back to wiring up the KurtE SD display adapter and diagnose this later as I know the 2.2" display works.

KurtE · Sep 2, 2016

DMASPI - For now I am punting on SPI1 and SPI2. I am not sure if there is an answer that will work here.

I did some searching and found things like: http://cache.freescale.com/files/soft_dev_tools/doc/support_info/MQXTWRK64RN.pdf
Which states:

Because the DMA TX channel and DMA RX channel for SPI1 and SPI2 are the same, SPI1 and SPI2 do not use the DMA driver

And from: https://community.nxp.com/thread/330972

Described issue with the same DMA for TX and RX channel is caused by hardware configuration directly on chip.

Unfortunately there isn’t any workaround except don’t use DMA for SPI1 and SPI2 and potentially complete rework of SPI driver and linking change (currently it is not on TO-DO list).

Frank B · Sep 3, 2016

I tested some things with pre-production 3.5 and 3.6 and must say that they work great.
I could not find any problems that weren't mentioned already.

manitou · Sep 3, 2016

I assume snooze will need some K64 mods. I tried duff's K66 mods at https://github.com/duff2013/Snooze_V6_Beta and got the sleep example to work on K66, but example doesn't compile on K64.

KurtE · Sep 3, 2016

manitou said:
I assume snooze will need some K64 mods. I haven't tried duff's K66 mods at https://github.com/duff2013/Snooze_V6_Beta

I have never used snooze, but thought I would download the V6 stuff and see if it builds and the like. And at least some of the Examples will probably need a little TLC.

Example I tried to build sleep_all_wakups, it builds fine for 3.6, but fails on 3.5, in this case probably because the 3.5 does not have any touch pins...

Code:

Build options changed, rebuilding all
In file included from C:\Users\Kurt\Documents\Arduino\libraries\Snooze/Snooze.h:38:0,

                 from C:\Users\Kurt\Documents\Arduino\libraries\Snooze\examples\sleep\sleep_all_wakeups\sleep_all_wakeups.ino:9:

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeTouch.h: In constructor 'SnoozeTouch::SnoozeTouch()':

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeTouch.h:73:5: error: expected identifier before '{' token

     {

     ^

In file included from C:\Users\Kurt\Documents\Arduino\libraries\Snooze/Snooze.h:39:0,

                 from C:\Users\Kurt\Documents\Arduino\libraries\Snooze\examples\sleep\sleep_all_wakeups\sleep_all_wakeups.ino:9:

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h: In constructor 'SnoozeCompare::SnoozeCompare()':

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:53:13: warning: 'SnoozeCompare::SIM_SCGC4_clock_active' will be initialized after [-Wreorder]

     bool    SIM_SCGC4_clock_active;

             ^

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:47:13: warning:   'uint8_t SnoozeCompare::CR0' [-Wreorder]

     uint8_t CR0;

             ^

C:\Users\Kurt\Documents\Arduino\libraries\Snooze/utility/SnoozeCompare.h:62:5: warning:   when initialized here [-Wreorder]

     SnoozeCompare( void )  :

     ^

sleep_all_wakeups: In function 'void setup()':
sleep_all_wakeups:87: error: 'class SnoozeTouch' has no member named 'pinMode'
     touch.pinMode(0, touchRead(0) + 250); // pin, threshold

           ^

Multiple libraries were found for "Snooze.h"
 Used: C:\Users\Kurt\Documents\Arduino\libraries\Snooze
 Not used: C:\arduino-1.6.11\hardware\teensy\avr\libraries\Snooze
'class SnoozeTouch' has no member named 'pinMode'

Note: I cloned the beta into C:\Users\Kurt\Documents\Arduino\libraries\Snooze

The line that the system showed the error for:

Code:

    touch.pinMode(0, touchRead(0) + 250); // pin, threshold

KurtE · Sep 3, 2016

Did some Analog testing. Using the test program I posted in other thread. So far so good. That is I tested the pins out of the Table in my test program:
uint8_t analog_pins[] = {A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12
, A13, A14, A15, A16
, A17, A18, A19, A20, A21, A22, A23, A24, 44, 45,

And so far it found all of the Analog pins.
Note: A23 and A24 code relies on my pull request: https://github.com/PaulStoffregen/cores/pull/167
Currently using the simple version which just added another case, not the version that which used a full populate lookup table.

Next, I may try reading the one out of the pins that are used for USB Host on T3.6

KurtE · Sep 3, 2016

KurtE said:
Next, I may try reading the one out of the pins that are used for USB Host on T3.6

For the fun of it I did create a new fork based on the other fork, that add A25 and A26 on the Teensy 3.5. They use the D+ and D- pins the 5 pin connector that is used on the T3.6 for USB host.

These pins are Analog only so I would assume NOT +5v tolerant.

https://github.com/KurtE/cores/tree/T3.5-Also-Add-A25-A26

They are on pin J1 which is ADC0_DP1 and K1 which is ADC1_DP1

Tested by again adding them to my Analog test program. Might be good if someone else also tested it...

Again not sure how many would be interested, but it does add two more Analog pins that you don't need to surface mount...

Paul: I have not done any testing on the Are the +5v and GND pins connected up to the other three pins. Wondering are they connected to Other GND +5v pins or are they connected up to other IO pins on the K64/K66. Example: on K66 pin K2 is USB1_VSS. If so K2 on K64 is ADC0_DM0/ADC1_DM3

Thanks
Kurt

KurtE · Sep 4, 2016

KurtE said:
Paul: I have not done any testing on the Are the +5v and GND pins connected up to the other three pins. Wondering are they connected to Other GND +5v pins or are they connected up to other IO pins on the K64/K66. Example: on K66 pin K2 is USB1_VSS. If so K2 on K64 is ADC0_DM0/ADC1_DM3

First step I did was to hook up Logic Pro 8 to all 5 pins and turned on both digital and analog reads of the 5 pins.
I Know from before D+ and D- are hooked up to IO pins.

But again not sure of other
What I am seeing is: +5v pin is showing voltages somewhere in the range .025 to .031...
The two ones marked G are very much close to 0 (likewise one on another GND pin). +- .0001

Now maybe experiment, a little bit. Want to make sure I don't short anything out!

defragster · Sep 4, 2016

Kurt - not sure if I'm following. But you are on K64 looking at the internal USB connector 5 pin holes? Those that on K66 give the 'T3.6 for USB host'?
If that is where you are the GND are (I assume) on the GND plane, the 5V and D+ and D- are floating with those components left off the K64 PCB.
Or have you gone upstream to where the empty component pads get their signal?

KurtE · Sep 4, 2016

Hi Defragster:

Yes looking at internal USB connections.

First pass looked at D+ and D- pins as these do connect up to pins J1/K1 (USB1_DM and USB1_DP) on the K66 and on K64 these are ADC0_DP1 and ADC1_DP1. At first I thought that they may not be connected, but if you look at posting #23, that the pins were connected, the missing part is actually an ESD device but that the pins are connected in an internal layer...

So far that works fine. As I mentioned I pushed up a fork that has these defined as IO pins.

Then it made me wonder what are the other three pins connected to.

Example: G pin are they directly connected to other GND pins? Or maybe is one or more of them connected to an IO pin on the K66, like the one marked USB1_VSS? My Ohm meter measured a few ohms between ground and these pins. USB1_VSS is on pin K2 on K66, which K2 pin on K64 is: ADC1_DM1. So this morning I tried defining this as an analog input. So far I don't think this is connected to any of these pins and/or some other stuff is on these pins as well as I get a constant value...

Hope that makes sense.

defragster · Sep 4, 2016

Good, I assumed - you looked more closely - I saw post 23 - my electronics understanding assumed the ESD was fed through - not already connected internally with ESD to bleed off D+/D-.

Makes sense - carry on

Have you tried the GND checks on beta1 Proto board - at least there the MCU pins are exposed to look for GND connect pins? Maybe even see the traces on the underside of not on ground plane?

PaulStoffregen · Sep 5, 2016

I've been working with the ADC0_DP1 and ADC1_DP1. Earlier I saw "strange" problems, but until now I assumed it was something wrong with my code.

It's looking like the K64 has a hardware bug with ADC1_DP1 when used in single ended mode. It seems to work, but the range is inverted. Zero volts reads 1023 (with analogRead default 10 bit config) and 3.3V reads zero.

On the connections, K66 pin USB1_VSS (K64 pin ADC1_DM1) is shorted directly to GND. So are the 2 ground pins on the USB host port.

manitou · Sep 5, 2016

manitou said:
I re-ran the tests, and the K66 numbers were actually a little lower at higher frequencies. i updated the table. Not sure why K64 is consuming more power. Measured with multimeter and hacked USB cable.

In post #11, k64 seems to be consuming more power than K66?? loop() with delay(5000); runs at 53.6 ma. Anyone else confirm this? Another data point is loading the BigNumber library Factorials example. if the monitor is not activated (spinning on !Serial), k64 consumes 46.1 ma. once monitor is activated, 58.1ma.

Here are some power numbers incrementally adding Ether things to the k64:

Code:

      blank sketch 53.7 ma  
      ether shield  89 ma (no LEDs)
      +e cable     140.3 ma  LEDs
      load etherraw  141.6 ma
      monitor on   159.6 ma

KurtE · Sep 5, 2016

PaulStoffregen said:
I've been working with the ADC0_DP1 and ADC1_DP1. Earlier I saw "strange" problems, but until now I assumed it was something wrong with my code.

It's looking like the K64 has a hardware bug with ADC1_DP1 when used in single ended mode. It seems to work, but the range is inverted. Zero volts reads 1023 (with analogRead default 10 bit config) and 3.3V reads zero.

On the connections, K66 pin USB1_VSS (K64 pin ADC1_DM1) is shorted directly to GND. So are the 2 ground pins on the USB host port.

Thanks Paul,

Good to know. I tried doing an Analog read on ADC1_DM1 and it was a constant value so assumed probably not viable.

So the question that probably only you can answer is does it make sense to add ADC0_DP1 and ADC1_DP1 as "A" pins, knowing one of them is inverted. Will update my version of it be based of current code...

EDIT: Looks like you added those pins as part of the last code delta :

PaulStoffregen · Sep 5, 2016

I added them both in the code.

The bigger question is whether to print A26 on the pinout card....

PaulStoffregen · Sep 5, 2016

D'oh, it was just a mistake in my test circuit. Looks like A26 does work properly.

KurtE · Sep 5, 2016

PaulStoffregen said:
D'oh, it was just a mistake in my test circuit. Looks like A26 does work properly.

Great! Looks like time to download next beta version and start testing again

KurtE · Sep 5, 2016

Decided to do some I2C testing and see if my SSD1306 would work on the T3.5... I know it has been done before, but I hacked up
a version of the Adafruilt_SSD1306 library that I replaced the including of Wire.h with i2c_t3.h. I also then added an optional parameter at the end of the I2C constructor with a reference to which I2C object to use. I did some rudimentary testing For Wire, Wire1, and Wire2 on the T3.5 (using default pins for each).

I uploaded the changed library, maybe should create new Library like SSD1306_I2C_T3, and rip out spi stuff... As there already is a good SPI version...
I only updated the 128x64 I2C display example and I selected the non standard I2C address for device (at least by Adafruit) as that is what my display has. Also changed reset pin to 6 as to not conflict with Wire2.

Again I pushed these changes up to new branch
https://github.com/KurtE/Adafruit_SSD1306/tree/I2C_T3

K64 Beta Test :: Teensy 3.5

Senior Member+

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Well-known member

Senior Member+

Senior Member+