defragster
Senior Member+
Yes a safe clean one, and my phone picked it up
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
@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 ....
It is more naivity on my side assuming that you simply get a return label from PJRC and off it goes.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.
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:
Manitou/Paul: etherraw.ino works for PING from PC and Android FING, when this is done: #define HW_CHKSUMS
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;
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;
LPUART_CTRL |= LPUART_CTRL_TIE;
LPUART_CTRL &= ~LPUART_CTRL_TIE;
LPUART_CTRL |= LPUART_CTRL_TCIE; // Actually wondering if we can just leave this one on...
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 ...)
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);
}
Try to access LPUART0 registers
BAUD: F000004
STAT: C00000
CTRL: 0
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!
* SOPT2 contains the controls for selecting many of the module clock source options on this device.[p238pg_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
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,
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.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.
K66 ethernet and lwIP
first step, K66 lwIP recognizes ARP request and replies. but no ping reply ... yet
progress recorded in post #686
can you do something like (?)...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???
#define printf(x,y) sprintf(sbuf,x,y); Serial.print(sbuf);
char sbuf[50];
printf("This variable is %5.3f\n",value1);
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.Hey we cross posted - That was my first speculation on scanning the FM!
.... 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".