K66 Beta Test

Status
Not open for further replies.
K66 'responsive' to ping messages on debug spew - now and in the prior post.

data in, len=62
flags 0x800
ARP Who is 192.168.1.85 from 192.168.1.74 (74:E5:0B:01:C3:64)
ARP Reply:
74 E5 0B 01 C3 64 00 00 00 00 00 00 08 06 00 01
08 00 06 04 00 02 04 E9 E5 00 00 01 C0 A8 01 55
74 E5 0B 01 C3 64 C0 A8 01 4A

It knows/shows its IP, and my phone with FING shows it with the assigned MAC and the name PJRC.com not from sketch - I see 'MACADDR1 0x04E9E5' is tied to your hardware license so FING is looking it up.

Oddly I've had it come up using a few addresses - my phone can see it - but the address won't show in my router table? So my router is not seeing something right to register it with its fixed IP and probably not forwarding the ping - even though it is on the same switch. But how the heck does FING get to it when it is coming in on WiFi? I just pulled my laptop cable and on WiFi it cannot get a PING back then either. I just added it to the bound and reserved list, no change: Won't ping, won't show active. I'll go grab another router.

I powered up my Pi0 - I can ping the Pi0 - Pi0 shows on router - but I cannot login to my Pi just now, it doesn't seem to be remembering my password as clearly written in front of me.
 
@Paul,
Due to custom issues, I was not able to send the K66 back yet (they always asked new documents), so I connected the K66 again to my laptop

Please have a look on the screenshot of my saleae LA of the RST,SWD,SWC pins
View attachment 7688
The picture is made after prog button pressed
The SWC pin is both digital and analog. (50 MHz digital 12.5 MHz analog)
It seems that SWC line exceeds some voltage (peak is 0.349V), which at least the LA recognizes as high. Could this also be with the K66, that is the K66 recognizes a high where none should be?
If this were the case, what could I do to clean up the signal? Would it help?
Or is this intended behavior?

It seems that the screenshot is correct and that the analog trace is not peaking up due to bandwidth limitation of the saleae I have.
inspecting careful the swc digital and analog trace I realize a pattern that could be interpreted as dialog

As I do not know who is talking, I call the devices as A,B
A clocks with narrow pulses (60 ns width) and B clocks with wide pulses (340 ns)

protocol is something line
B sends 3 bit header, followed by 0 or 4 byte payload and terminated with 2 bit trailer
If payload of B is 4 byte, A sends 2 bit header followed by 1 byte payload
If payload of B is zero, A sends 4 bytes data followed by 3 bits + 2 bytes

using '-' for long clock pulse and '.' for short clock pulse
the clock rhythm seems to be

(--- -------- -------- -------- -------- -- .. ........)
(--- -- ........ ........ ........ ........ ........... ........) (the second last dot sequence is 3+8 bit, last byte is separated by some delay)

Assuming this to be correct, I could now try to decode the data exchange, but I assume this to be very repetitive (as the T3.5 is not responding properly to USB enumeration)
 
Thanks Paul - Ping works from Pi0! Back to running 240 MHz - even though the initial confirm 'ID3' is wrong - it works on initial house router. May have to set up my Pi3. This works with both posted sketches: Paul and Manitou.

Before I went back to that I confirmed - some more failures::
Ethernet on a Netgear router - set it up and pulled off PC - net work is much quieter. Shows the IP in its connected table. Still no Joy ANDROID apps or WIN_10 - So: not just the router.
Went back to Pi0 on home router - apparently it reverts the password to factory default as that worked?
 
It seems that the screenshot is correct and that the analog trace is not peaking up due to bandwidth limitation of the saleae I have ....

So weird that you can't simply "return" an item 'for service to the sender' without so much paper and effort. Of course if it were that easy it would be an abused lie.

I got my K66 'offline' once - interrupted during upload and it came back to reprogram after a held button press until and after connected, when the IDE was ready to upload. Maybe not this time but - TeensyDuino had turned off Auto and I had to click that.

In some cases of bad sketches <to a T_3.2> taking USB offline I had to do that - but between attempts I plugged in another Teensy and showed (windows) how a good one looks - put on a sketch - then right after went to my failing Teensy with the press connect and it worked.

If that works Paul won't know why - if not then it Paul really needs to see it.
 
Last edited:
So weird that you can't simply "return" an item 'for service to the sender' without so much paper and effort. Of course if it were that easy it would be an abused lie.
It is more naivity on my side assuming that you simply get a return label from PJRC and off it goes.
Yes, there were some explanation on the Web on how to fill out an invoice but the provided template does not match the explanation.
Now they wanted my fiscal code, and a declaration of origin (I guess that is an US import issue, as declaration of origin is not required for all countries)

when I'm again in Germany, I will try a different country.

Anyhow, this gives me some more time to learn the handling of a stuck protocol.
 
Ethernet board plugged in - unmodified K66 - two green lights with activity. On the network and picking up network traffic, won't respond to PING.

At 240 MHz I get ID3 mismatch with sketch PJRC k66_ethernet:


My phone with 'FING' shows PJRC.COM with MAC 04:E9:E5:00:00:01, but like my PC a PING is 100% packet loss?
My output below doesn't have line below in Manitou Configuration summary do I have the right sketch?
"PHY control reg 0x3100 100mbs, auto negotiate, full duplex"

ID3 looks better at 120 MHz with a match on PJRC and the Manitou sketch output here:

Re: "PHY control reg 0x3100 100mbs, auto negotiate, full duplex"
ooops, that was annotation i added, it was cut/paste from my electronic "note book"

I only tested at 120mhz.
my "extended sketch", a monolithic menagerie (== hack), is here. it has some hardwired pre-fab packets... good luck.

I just started configuring lwIP (1.4.0), but there is a lot to figure out -- joining lwIP logic with teensyduino logic and with the ether hardware. I have working mbed k64f lwip but it is using RTOS. results will continue to appear on #686
 
Last edited:
Manitou/Paul: etherraw.ino works for PING from PC and Android FING, when this is done: #define HW_CHKSUMS

as noted in post #686, I had some problems with hardware checksums. my hack to put in software checksums may not be robust? (works for me). Software checksums do NOT compute UDP checksums, sets checksum field to 0 which "bypasses" UDP checksums (RFC-approved, so should work ...)
 
Serial6-LPUART:

Working on the LPUART code, I think I have most of it in place ready for me to try, need to updated the Baud rate calculations, also first get the basics working before making sure code is correct for more advanced stuff, like 9 bit, not sure how/if to expose 10 bit, Parity...

But it is interesting, that at times, I am uncertain of some basic things, like:
a) Are the memory mapped registers big or little endian? Assumption is big?
b) Can I just read/write a single byte of a 32 byte register? Or as I suspect, it depends on the register?

In particular, Registers for UARTS, we have the registers defined to match the registers defined in spec like:
Code:
typedef struct __attribute__((packed)) {
	volatile uint8_t	BDH;
	volatile uint8_t	BDL;
	volatile uint8_t	C1;
	volatile uint8_t	C2;
	volatile uint8_t	S1;
	volatile uint8_t	S2;
	volatile uint8_t	C3;
	volatile uint8_t	D;
	volatile uint8_t	MA1;
	volatile uint8_t	MA2;
	volatile uint8_t	C4;
	volatile uint8_t	C5;
	volatile uint8_t	ED;
	volatile uint8_t	MODEM;
	volatile uint8_t	IR;
	volatile uint8_t	unused1;
	volatile uint8_t	PFIFO;
	volatile uint8_t	CFIFO;
	volatile uint8_t	SFIFO;
	volatile uint8_t	TWFIFO;
	volatile uint8_t	TCFIFO;
	volatile uint8_t	RWFIFO;
	volatile uint8_t	RCFIFO;
	volatile uint8_t	unused2;
	volatile uint8_t	C7816;
	volatile uint8_t	IE7816;
	volatile uint8_t	IS7816;
	union { volatile uint8_t WP7816T0; volatile uint8_t WP7816T1; };
	volatile uint8_t	WN7816;
	volatile uint8_t	WF7816;
	volatile uint8_t	ET7816;
	volatile uint8_t	TL7816;
	volatile uint8_t	unused3;
	volatile uint8_t	C6;
	volatile uint8_t	PCTH;
	volatile uint8_t	PCTL;
	volatile uint8_t	B1T;
	volatile uint8_t	SDTH;
	volatile uint8_t	SDTL;
	volatile uint8_t	PRE;
	volatile uint8_t	TPL;
	volatile uint8_t	IE;
	volatile uint8_t	WB;
	volatile uint8_t	S3;
	volatile uint8_t	S4;
	volatile uint8_t	RPL;
	volatile uint8_t	RPREL;
	volatile uint8_t	CPW;
	volatile uint8_t	RIDT;
	volatile uint8_t	TIDT;
} KINETISK_UART_t;
So for the LPUART, I defined a new structure, to match the registers as defined in the document:
Code:
typedef struct __attribute__((packed)) {
	volatile uint32_t	BAUD;
	volatile uint32_t	STAT;
	volatile uint32_t	CTRL;
	volatile uint32_t	DATA;
	volatile uint32_t	MATCH;
	volatile uint32_t	MODIR;
} KINETISK_LPUART_t;
What my question is (maybe to myself) is in the other Serial objects, we set the C2 (8 bit register) to the state we want, which,
is basically setting/clearing the TIE bit and TCIE bit. The C2 register of other UARTS Corresponds to bits 16-23 of CTRL, so can I simply set this one byte like we do in C2 for other UARTS, or should I instead, always manipulate the whole 32 bit register?

Secondary, If I can not simply set the value of logical C2 in the write function, which is atomic, but instead, need to Read/modify/Write, do I need to make this atomic...

In particular I am assuming I need to protect code in putchar like:
Code:
  LPUART_CTRL |= LPUART_CTRL_TIE;
Not sure if better to break into multiple statements (read, update, write), like some are in the code or not.

But also wondering in Interrupt handler, if I need to protect the code, example when no more characters are available to output. Need to do something like:
Code:
  LPUART_CTRL &= ~LPUART_CTRL_TIE; 
  LPUART_CTRL |= LPUART_CTRL_TCIE; // Actually wondering if we can just leave this one on...
Again these are not atomic. Do I need to worry about a higher priority interrupt happening, that updates this register in the middle of this? Then again, if worry about higher priority interrupt, current code may not work right. We enter interrupt, TX queue empty, and so we clear the TIE interrupt, but what happens in between our test for empty queue a higher priority interrupt fires and adds stuff to our queue...
 
Last edited:
as noted in post #686, I had some problems with hardware checksums. my hack to put in software checksums may not be robust? (works for me). Software checksums do NOT compute UDP checksums, sets checksum field to 0 which "bypasses" UDP checksums (RFC-approved, so should work ...)

Yes, I saw your notes - so when I looked at the code that's why I enabled that. With HW_CHKSUMS works on the ping packets as noted - only rPi_Linux likes the software checksum version for some reason. FING ping batches as low as 9ms avg

Running and answering pings ~8 hours.:: rPi_0 ping every 15 seconds - no errors overnight and Win_10 ping every 13 seconds. With net traffic in 5 minutes I just captured the passage of 653 messages. 130 per minute - all with serial spew (lots of 'who is' and broadcast IPv4 w/type=17). Seems like a stable hardware base to build on. I'll put the spew to a display and power them up here.

PHY Shield about 90°F I found a processor spot at 100.9°F - running etherraw at 144 MHz. Temp actually lower under 100°F going to 240MHz.
 
Last edited:
I am having issues trying to access the registers associated with LPUART0... If I am reading document correctly,
The registers should be at the address 0x400C4000

Here is a test program that hangs/crashes when I try to access the Baud register. (Also hangs on write to it).
Code:
typedef struct __attribute__((packed)) {
  volatile uint32_t BAUD;
  volatile uint32_t STAT;
  volatile uint32_t CTRL;
  volatile uint32_t DATA;
  volatile uint32_t MATCH;
  volatile uint32_t MODIR;
} XKINETISK_LPUART_t;
#define XKINETISK_LPUART0  (*(XKINETISK_LPUART_t *)0x400C4000)


void setup() {
  while (!Serial) ;
  Serial.begin(115200);
  delay(250);

  Serial.println("Try to access LPUART0 registers");
  Serial.print("BAUD: ");
  Serial.println(XKINETISK_LPUART0.BAUD, HEX);
  Serial.print("STAT: ");
  Serial.println(XKINETISK_LPUART0.STAT, HEX);
  Serial.print("CTRL: ");
  Serial.println(XKINETISK_LPUART0.CTRL, HEX);
 
}

void loop() {
  delay(250);
}
If you run the program the print showing BAUD:
is output to terminal, but not value...

Suggestions? Did I read manual wrong?
Thanks!
 
I haven't looked much at the LPUART yet, but I was under the impress it's very similar to the one in Teensy LC. Is any of the code in serial1.c for LC usable?
 
K66 ethernet and lwIP
first step, K66 lwIP recognizes ARP request and replies.:) but no ping reply ... yet

progress recorded in post #686
 
As far as I can tell UART0 on the TeensyLC looks like it has very similar registers and the like to UART1/2, except maybe an extra C5 register or the like.

On the 3.5, The Register set is completely different as you can see in posting #838. Unless I am going off of something completely wrong (Chapter 62).

EDIT: Figured out I need to turn on the appropriate clock before the memory map will allow me to access the slot:
SIM_SCGC2 |= SIM_SCGC2_LPUART0; // Turn on the clock
With this added to test program above I now get,

Code:
Try to access LPUART0 registers
BAUD: F000004
STAT: C00000
CTRL: 0

So hopefully tomorrow will get some real output on the LPUART :D
 
Last edited:
I am having issues trying to access the registers associated with LPUART0... If I am reading document correctly,
The registers should be at the address 0x400C4000
....
Suggestions? Did I read manual wrong?
Thanks!

Lots of LPUART details! Not sure which you read? And most of this is unfamiliar to me - but maybe this list shows a missed item::
* LPUART Functional when using clock source which is active in Stop and VLPS modes [p92
* 0x400C_4000 68 LPUART0 [p113
* LPUART0 Bus clock LPUART0 clock [p126
pg_132:: 6.7.12 LPUART0 clocking
The LPUART0 module has a selectable clock as shown in the following figure.
NOTE -- The chosen clock must remain enabled if the LPUART0 is to
continue operating in all required low-power modes.
... After set the clock divider in SIM_CLKDIV3, need to disable LPUART clock(set
SIM_SCGC2 LP_UART0 bit =1 ) to enable the clock divider, then to clear SIM_SCGC2
LP_UART0 bit to output this divided clock to LPUART0
* SOPT2 contains the controls for selecting many of the module clock source options on this device.[p238
* 13.2.6 System Options Register 5 (SIM_SOPT5) [p244
* This register should only be written when the LPUART, and TPM modules are disabled. [p275

Quick scan finds those notes - maybe you missed setting up a valid clock for the current mode?

* If LPUARTn is used to connect to the flashloader, [p317
* The LPUART remains functional in debug mode. [p2151
> I don't suppose Paul uses this device for flash loading or as a debug pin

* Programmable baud rates (13-bit modulo divider) [p2419
> Is this the same clock rate math as the other UARTs?
 
Last edited:
EDIT: Figured out I need to turn on the appropriate clock before the memory map will allow me to access the slot:
SIM_SCGC2 |= SIM_SCGC2_LPUART0; // Turn on the clock
With this added to test program above I now get,

Hey we cross posted - That was my first speculation on scanning the FM!

@Manitou - good luck with ping - I'll just re-add : watch the checksum, if that is wrong it doesn't work.
 
PHY Shield about 90° I found a processor spot at 100.9° - running etherraw at 144 MHz. Temp actually lower under 100° going to 240MHz.
I think worthwhile to indicate if that is degrees F or degrees C. It's an international group here and both are plausible, but 100 C might be cause for concern.
 
The 12 extra ethernet PCBs arrived.

Anyone (who's already got beta hardware) who wants to play with ethernet, speak up now and we'll solder one and send it to you.
 
K66 ethernet and lwIP
first step, K66 lwIP recognizes ARP request and replies.:) but no ping reply ... yet

progress recorded in post #686

ping reply is working (rtt min/avg/max/mdev = 0.127/0.135/0.231/0.021 ms).

lwIP has extensive debugging options, but it wants to use printf() from the core C programs. I take it there is no easy way to do printf() from teensy core C files???
 
...it wants to use printf() from the core C programs. I take it there is no easy way to do printf() from teensy core C files???
can you do something like (?)
Code:
#define printf(x,y) sprintf(sbuf,x,y); Serial.print(sbuf);
char sbuf[50];

printf("This variable is %5.3f\n",value1);
 
Last edited:
Hey we cross posted - That was my first speculation on scanning the FM!
I now have test app that can actually output stuff Serial6.print... and it shows up on the IO pin. However still trying to figure out BAUD rate setting.

Looking at section 6.7.1.2 - I see Clock selection can be set to MCGIRCLK, or OSCERCLK, or the setting in SIM_SOPRT2[PLLFLLSEL] which can choose from MCGFLLCLK, IR48MCLK, USB1PFDCLK, MCGPLLCLK. I believe the init code sets the SIM_SOPRT2[PLLFILLSEL] setting as part of setup, depending on what CPU speed.

I believe I set the LPUART to use the PLL Selection. I am not sure if there is some predefined thing like F_PLL, F_BUS, ... that I can use here for the baud rate calculations.

What I found so far for baud rate 115200, that to get the right baud, it looks like the LPUART0_Clock is running at 48mhz when I run at 180mhz and at 24mhz when the cpu is at 96mhz.

Will try more setting tomorrow to see if I can figure this out. At that time will push up to my fork of github (new branch) in case anyone wishes to take a look.

Kurt
 
Good luck Kurt. (I suppose you saw p2169 and the figure top of page 2170?) Also you wondered about 8,9,10 bit on LPUART
* 62.4.4.1 8-bit, 9-bit and 10-bit data modes [p2180
( that is a versatile port: Programming, auto baud detect, 62.4.4.4 Single-wire operation, 62.4.5 Infrared interface )

Duff have you done a PDF find on "LPUART"? In my scan I saw it can run in low power mode:
* LPUART is enabled in Doze mode. [p2163)
* LPUART Functional when using clock source which is active in Stop and VLPS modes [p92

Just looked this Duff post #462 up : it works using the USB crystal-less clock! Had to touch a lot of the USB code and add some new registers but I have the USB working down to 4 MHz. Should I add this to post 8 Known Work Items? Or is the method for this outside the normal scope of USB init?
 
.... I've been thinking of this recently while staring at so many PCB traces. It was suggested earlier to also make the last digit of the 5V tolerant version "5".

Sooo, Teensy 3.4 is going to become Teensy 3.45 ? :D

Ahh, all those comments that need to change...
 
Status
Not open for further replies.
Back
Top