K66 Beta Test

Status
Not open for further replies.
Thanks,

Just tested with alternate pin numbers
SPI1.setSCK(32);
SPI1.setMOSI(21);
SPI1.setMISO(5);
with EraseEverything and rawtest... :D

As for SPI2? I don't see any IO pins defined in table for SPI2... I see I2C2, but. Not sure about PTE... But will look.
 
KurtE said:
Thanks,

Just tested with alternate pin numbers
SPI1.setSCK(32);
SPI1.setMOSI(21);
SPI1.setMISO(5);
with EraseEverything and rawtest... :D

As for SPI2? I don't see any IO pins defined in table for SPI2... I see I2C2, but. Not sure about PTE... But will look.
Click to expand...

SPI2 would be back-pads if room (according to Paul's table)
44 MISO2
45 MOSI2
46 SCK2
47 CS2

PTB20-23 according to data sheet.
 
Re: analogRead(45)

It might be worthwhile to create symbolic names for the various internal ADC registers to hide the vagaries of pin numbering for the different MCUs.

#define ADC_TEMPERATURE 44
#define ADC_VREFOUT 45
#define ADC_BANDGAP etc.
 
manitou said:
SPI2 would be back-pads if room (according to Paul's table)
44 MISO2
45 MOSI2
46 SCK2
47 CS2

PTB20-23 according to data sheet.
Click to expand...
If I am looking over these pins, as well as the SD card ones I think the pin definitions are?
Code: 
On-board SD card (dedicated 4-bit SDIO)												
----------------												
	8	E2	PTE5	DISABLED		PTE5	SPI1_PCS2	UART3_RX	SDHC0_D2		FTM3_CH0	
	7	E3	PTE4	DISABLED		PTE4/LLWU_P2	SPI1_PCS0	UART3_TX	SDHC0_D3	TRACE_D0		
	4	E4	PTE3	ADC1_SE7a	ADC1_SE7a	PTE3	SPI1_SIN	UART1_RTS_b	SDHC0_CMD	TRACE_D1		SPI1_SOUT
												
	3	D1	PTE2	PTE2/LLWU_P1	ADC1_SE6a	PTE2/LLWU_P1	SPI1_SCK	UART1_CTS_b	SDHC0_DCLK	TRACE_D2		
												
	2	D2	PTE1	ADC1_SE5a	ADC1_SE5a	PTE1/LLWU_P0	SPI1_SOUT	UART1_RX	SDHC0_D0	TRACE_D3	I2C1_SCL	SPI1_SIN
	1	D3	PTE0	ADC1_SE4a	ADC1_SE4a	PTE0	SPI1_PCS1	UART1_TX	SDHC1_D1	TRACE_CLKOUT	I2C1_SDA	RTC_CLKOUT
												
If room for pads on bottom…												
40	138	B9	PTD9	DISABLED		PTD9	I2C0_SDA			LPUART0_TX	FB_A17	
41	137	C9	PTD8/LLWU_P24	DISABLED		PTD8/LLWU_P24	I2C0_SCL			LPUART0_RX	FB_A16	
42	14	G4	PTE11	DISABLED		PTE11	I2C3_SCL		I2S0_TX_FS	LPUART0_RTS_b	FTM3_CH6	
43	13	F1	PTE10/LLWU_P16	DISABLED		PTE10/LLWU_P18	I2C3_SDA		I2S0_TXD0	LPUART0_CTS_b	FTM3_CH5	USB1_ID
44			PTB23	DISABLED		PTB23	SPI2_SIN	SPI0_PCS5		FB_AD28/SDRAM_D28	CMP3_OUT	
45			PTB22	DISABLED		PTB22	SPI2_SOUT			FB_AD29/SDRAM_D29	CMP2_OUT	
46			PTB21	DISABLED		PTB21	SPI2_SCK			FB_AD30/SDRAM_D30	CMP1_OUT	
47	99	D10	PTB20	DISABLED		PTB20	SPI2_PCS0			FB_AD31/SDRAM_D31	CMP0_OUT
Note, I am really guessing on some of these, in especially 42 and 43

Also not sure if any of these pins are accessible on the initial test boards?
 
PaulStoffregen said:
Looks like some chips might not overclock all the way to 240 MHz.

The chip I have here on my desk seems to run well for many hours at 240 MHz, but it does get noticeably warm.
Click to expand...

Run my test again this night, and when i was @ work: Was still working when i arrived home again.

Audio:
Maybe there is away to solve the I2S Problems > 200MHz.
I think, the problem is the DMA. I added a asm("WFI") to my loop(){} (playing an .aac - file) , where it waits. Suddenly, it was *much* better and stable for 216MHz (which changed divisors)
So, with a bit luck and some experimenting... Perhaps the AXBS (+MUX?) are part of the problem - ("WFI" has positive influence)

But I'll pause this topic now, at least for some time, and try again later.
 
KurtE said:
Also not sure if any of these pins are accessible on the initial test boards?
Click to expand...

I don't think the PTB20-23 are accessible on beta boards -- though you could do "unconnected" SPI2 timing tests to show that SPI2 might be working :D

As for the PTE* tests, my thinking is to hack SD lib to use your SPI1, and do a SPI1 test with an external SD breakout and accessible SPI1 pins. If that works, then hack core_pins.h (and whatever else) and replace (for testing purposes) the SPI1 pin definitions with the PTE pins, and see if I can read from onboard microSD with SPI1

EDIT: see Paul's post #398, SPI2 pins are accessible on beta board, but not configured in core
 
Last edited:
you know Elm Chan's SD-Code ?
http://elm-chan.org/fsw/ff/00index_e.html

It has a liberal licence (like "MIT") and is easy to port-

[h=4]Features[/h]
  • Windows compatible FAT/exFAT file system.
  • Platform independent. Easy to port.
  • Very small footprint for program code and work area.
  • Various configuration options to support for:
    • Multiple volumes (physical drives and partitions).
    • Multiple ANSI/OEM code pages including DBCS.
    • Long file name in ANSI/OEM or Unicode.
    • exFAT file system.
    • RTOS envilonment.
    • Fixed or variable sector size.
    • Read-only, optional API, I/O buffer and etc...
Click to expand...
 
Last edited:
...likewise, LWIP (ip stack) is well known, used in many applications and very reliable. BSD License.

Why re-invent everything ?
 
Last edited:
Frank B said:
you know Elm Chan's SD-Code ?
http://elm-chan.org/fsw/ff/00index_e.html
Click to expand...

Yes. I still use the sdFAT lib logic in one of my SPI benchmarks (? or maybe that's different from FatFs?), and I briefly looked at it for my "curiosity experiment" to use SPI to access T3.5's microSD. It seemed using the simpler SDlib would be easier for my experiment. Ultimately, Paul will be using 4-bit SDIO, and I don't think sdFAT or FatFs does 4-bit SDIO. (I was only able to find a NXP SDHC/SDIO driver in BRTOS and uTasker -- if you know of others, that would be useful info.)
 
Somebody saw EEPROM working? Using what method? I'd like to find a working starting point to prove my EEPROM working.

I always see '255' when using example teensy\avr\libraries\EEPROM\examples\eeprom_clear when I run teensy\avr\libraries\EEPROM\examples\eeprom_read

I was trying to start a test sketch to verify all the EEPROM access methods/boundaries and it was failing the same way and I don't see why - of course I started with the class'y array like method EEPROM[ index ] only to finally try the simple samples to see them fail as well.
 
defragster said:
Somebody saw EEPROM working? Using what method? I'd like to find a working starting point to prove my EEPROM working.
Click to expand...

this is just a variation of simple Arduino demo. fix #if to write something the first time
Code: 
/*
  eeprom perf (cycle power to confirm)
*/

#include <EEPROM.h>


unsigned long t;
void setup()
{
  int i,val,errs=0;

  Serial.begin(9600); while(!Serial); delay(5000);
  Serial.print("EEPROM length: "); 
  Serial.println(EEPROM.length());
  Serial.println("initial read");
	for (i=0;i<100;i++) {
		val = EEPROM.read(i);
		if (val != i) {
			Serial.print(val);
			Serial.print(" should be ");
			Serial.println(i);
                        errs++;
		}
	}
  Serial.print("read errs "); Serial.println(errs);
#if 0
	t=micros();
	for (i=0;i<100;i++) EEPROM.write(i, i);
	t=micros()-t;
	Serial.print("write "); Serial.println(t);
#endif
}

void loop()
{
	int i,val;
	t=micros();
	for (i=0;i<100;i++) val = EEPROM.read(i);
	t=micros()-t;
	Serial.print("100 reads (us) "); Serial.println(t);
        Serial.println(val);  // reference val
	delay(2000);
}

when you do a "clear" (erase) it sets bytes to 0xFF

EDIT: the clear example, actually writes 0s -- not sure why that didn't work for you? speed problem?
 
Last edited:
manitou said:
this is just a variation of simple Arduino demo. fix #if to write something the first time
{...}
EDIT: the clear example, actually writes 0s -- not sure why that didn't work for you? speed problem?
Click to expand...

Yeah 0 != 255 very puzzling - none of my changes would take. Thanks for the code I'll try it. And adjust the speed, last was at 192.
 
Okay - never expected that will look at : static void flexram_wait(void) ?

<edit> it always reads 255 at high clock rates.
 
Last edited:
defragster said:
Okay - never expected that will look at : static void flexram_wait(void) ?

<edit> it always reads 255 at high clock rates.
Click to expand...

@180mhz, I inserted delay(1) in flexram_wait() but write's still didn't happen (took longer though ;) ), so it's not just a delay issue.
 
Last edited:
I saw LP mode write prohibited note in the FM but hadn't found HSRUN - of course just learning of HSRUN mode . . . Indeed I tried checking for missing waits or wait not working and went the wrong direction. At least reads work in HSRUN.

Paul - have you made a table for test areas like for the LC? This one needs columns for test speeds
 
manitou said:
40 on beta, 45 if there is room on production -- Paul knows best. see post #93
Click to expand...

does the K66 chip have 100 GPIO?
I frequently need a lot of IO lines, and arduino mega with 70 total works nicely. wish there was something closer to this in teensy.
if the board is 2.4in, then there is room to fit a second internal row of gpio pins on either side?

I see for K64, the smallest package has 66 GPIO. Even 66 GPIO is enough for all my needs. It's not the same to use IO expander.
On teensy 3.2, no pin is wasted, would it be the same for this?
 
Last edited:
KurtE said:
Also not sure if any of these pins are accessible on the initial test boards?
Click to expand...

The round 1 & 2 beta boards have these on a set of pin pads near the lower right corner of the board, just below the SD socket.


EDIT: I've updated the pinout info in #93 with the native port info for these 8 extra pins. Here's ascii art for the pinout of those extra pads on the beta test boards:

Code: 
 3.3V  [] ()  GND
   40  () ()  41
   42  () ()  43
   44  () ()  45
   46  () ()  47

At this point, these 8 extra pins aren't defined in the code. It's still questionable whether these will end up as bottom-side pads on the final design. When/if they appear in the code, you can take that as a sign I'm confident they'll be on the final board. Until then, I wouldn't recommend putting too much time into actually doing things with these extra pins.
 
Last edited:
doughboy said:
On teensy 3.2, no pin is wasted, would it be the same for this?
Click to expand...

Several pins will not be accessible. There's just no physical way all the pins can route from the BGA package on such a small board, and there isn't room for all the pins even if the routing were possible.
 
Status
Not open for further replies.
Back
Top