defragster
Senior Member+
In the past day I've had two anomalies uploading to my K66's. Actually both were on the Beta_3 unit and the same code was working or acted differently/recovered on the PROTO_b1 board.
This after the K64 not running display as the K66 has kept me distracted - I put that on hold and then making sure TYQT was working otherwise I ran into these. For now I've taken TYQT out as an IDE loader replacement for TeensyDuino.
ONLY odd factor is I was using TYQT for my uploads. This comes up later.
> I wrote some EEPROM test code to use the various the function interfaces to fill the 4KB. This sketch reads and writes at 120MHz, and can only read over 120 it seems.
Problem was same sketch to both K66's and the PROTO_b1 ran and the Beta_3 would do one part and then 'die in the weeds'. I got as far as putting a print statement in the code and it would complete one portion and then never print the next like the Beta_3 unit did.
Something else "shiny" popped up and I tried to put code in startup_early_hook();. I have yet to get that to work, but in the process the PROTO_b1 withstood my failed attempts, but the Beta3 unit went into a state where I could not get TYQT to put a couple other pieces of different code on it (this was the 'later' piece). Rebooting my machine and seeing it repro, I manually used TeensyDuino to push the same HEX and the Beta_3 K66 came back to working.
This served as a great distraction and in the end TeensyDuino seems to be doing the right thing but I'm not sure if this was an edge condition that caught TYQT but TD can handle, or if TYQT is just not getting something right?
Paul - does this in any way relate to the failure to program over 512MB of flash - or just seem like an issue for Koromix?
Also: My now retired USB HUB was causing some troubles - a new USB 3 hub not showing those issues in any similar way [so not questioning USB on this Win 10 desktop], perhaps those failures got something off in the K66?
Noteworthy SIDE NOTE: It seems that K66 EEPROM reads DO work at 180 MHz?, only writes are inhibited?
This after the K64 not running display as the K66 has kept me distracted - I put that on hold and then making sure TYQT was working otherwise I ran into these. For now I've taken TYQT out as an IDE loader replacement for TeensyDuino.
ONLY odd factor is I was using TYQT for my uploads. This comes up later.
> I wrote some EEPROM test code to use the various the function interfaces to fill the 4KB. This sketch reads and writes at 120MHz, and can only read over 120 it seems.
Problem was same sketch to both K66's and the PROTO_b1 ran and the Beta_3 would do one part and then 'die in the weeds'. I got as far as putting a print statement in the code and it would complete one portion and then never print the next like the Beta_3 unit did.
Something else "shiny" popped up and I tried to put code in startup_early_hook();. I have yet to get that to work, but in the process the PROTO_b1 withstood my failed attempts, but the Beta3 unit went into a state where I could not get TYQT to put a couple other pieces of different code on it (this was the 'later' piece). Rebooting my machine and seeing it repro, I manually used TeensyDuino to push the same HEX and the Beta_3 K66 came back to working.
This served as a great distraction and in the end TeensyDuino seems to be doing the right thing but I'm not sure if this was an edge condition that caught TYQT but TD can handle, or if TYQT is just not getting something right?
Paul - does this in any way relate to the failure to program over 512MB of flash - or just seem like an issue for Koromix?
Also: My now retired USB HUB was causing some troubles - a new USB 3 hub not showing those issues in any similar way [so not questioning USB on this Win 10 desktop], perhaps those failures got something off in the K66?
Noteworthy SIDE NOTE: It seems that K66 EEPROM reads DO work at 180 MHz?, only writes are inhibited?