T_3.6 acting oddly: Program Button doing a reset, no bootloader reprogram

Status
Not open for further replies.

defragster

Senior Member+
One T_3.6 of Six KS units:
> Program acting like RESET
> Five 20-25+ second 'Press to Blank' and no blanking was observed. UPDATE:: Any press longer than ~17 seconds is ignored by design ( see post #4 below )

I have marked this one now. When I did my first pass testing each of 6 KS T_3.6's one of them acted like this then worked right with same sketch . I did not mark it then - none of the others did this on same sketch - I can only assume it was perhaps this one - in any case it was the same behavior.

Same sketch for both of these issues - powers up and toggle blink LED on 1,000 count in sketch instance of systick_isr(). This same sketch has been run and reprogrammed many times on a 3rd T_3.6 with no issue.

Device still programs and runs properly.

> Program acting like RESET
Teensy Loader active - last try two presses and one .25 second long press. Teensy restarts and does Serial Spew of last loaded program, Verbose Teensy loader shows NO indication of a Teensy. When TYQT was active it captured the Serial spew - one line on startup. The button just declared it missing and it then (after reset) appeared as running.
--> 2nd T_3.6 :: same machine - same sketch - ten for ten a button click no matter how fast and the unit goes to bootloader.
--> Put 1st back on and it now:
> first four times it did 'Bootloader' next four times it did 'Reset', then bootloader, then 9 times 'Reset' and again 'bootloader'
--> I just programmed with "I:\arduino-1.6.11\examples\Teensy\Tutorial3\HelloSerialMonitor" and 20 of 20 button presses all resulted in reset sketch restart: "Hello World".
--> 2nd T_3.6 - same "Hello" sketch - unchanged programming environment and 6 for 6 button takes to 'bootloader'

> Five 20-25+ second 'Press to Blank' and no blanking was observed UPDATE:: Any press longer than ~17 seconds is ignored by design
On PC and twice on POWER ONLY cable and twice again on PC. Holding and not holding button on connecting with active sketch.
--> Note: this 'Press to Blank' behavior was reported in beta after update to bl_1.03 on all three beta devices.

I will leave this device in this state, perhaps you might want to see it.

<edit>: Nothing soldered to this device. Board looks clean - except a red mark on SDIO socket top to ID it. No sign of connectivity Reset to Program at 2000k ohms on my meter - pressed or not. Nor to the SD socket case where it looks like a Reset via comes up.

<edit 2>: BTW - first time I saw this behavior was my desktop machine with 1.6.12 - this repro is on my laptop with 1.6.11 - Both Windows 10x64_Pro of course.
 
Last edited:
I recall the erase option is 15 s button press (actually 13 to 17 s). I do not know if longer button press will also erase.
 
I don't know either - assumed it was better to go longer than shorter as it was not exact. I posted about this in beta as all three failed after bl_1.03 update on ~15 seconds and longer as noted and got no direction, though it eventually worked on all three ( and fixed an unknown issue on the PROTO after bl_1.03 update).
{I did just do the 2nd T_3.6 for ~exactly ~15 seconds and it came up blanked!}

Until I hear from PJRC I'm leaving it in the bag in case it will show the state of my device. I only attempted the 'Press to Blank' to see if it would clear up the 'reset not program' button issue. Press to Blank may fix it - but since 'Reset' is persistent I'm wondering if there is something out of wack that maybe worth seeing.

I also wanted to add that all three of my Beta devices are still 110% functional - as are all the other Teensy's I've touched since Feb 2015. And note that I have programmed all 6 of my T_3.6's at least twice and two others have been used much more than this one using the HSRUN drop/raise same code I'm working on.

NOTE:: There should be a good Teensy USB with Blink diagnostic sketch included that was unfound when I looked. The one I used above talks USB, but no blink. I found another [I:\arduino-1.6.11\examples\Teensy\USB_Serial\USBtoSerial] that only shows blink when USB is sent. I would suggest a simple setup with Serial that blinks fast and waits a few seconds to attach SerMon - but goes ahead then blinks slower so it could be run from a non-usb system or battery pack (or power only USB cable). I might suggest something like this: Can-t-communicate-with-Teensy-3-2-through-Teensyduino?

{ Also the USBtoSerial sketch writes the reset pin before setting it to output in setup(). Also that sketch should use LED_BUILTIN not a number with comments - assuming that is now standard on all devices for current TeensyDuino }
 
Longer than 17 seconds will not erase. This is meant as a safety feature, so your board isn't accidentally erased if the button is unintentionally pressed for a long time. For example, it you set a object on your Teensy or it gets wedged inside an enclosure, a lengthy but not intentional 15 second press is not supposed to erase.

To force a full erase, the button must be pressed for a time lasting between 13 to 17 seconds. Less than 13 or more than 17 seconds does not cause full chip erase. The idea is for only a deliberate, well timed 15 second press to access this feature.
 
Last edited:
Makes sense - give you time to say - opps I held it too long - hold it longer and it will be saved! When that was announced it was in a different post from when it was released and I didn't get the critical nature of that.

Question: Do you want to see my Button resetting Teensy, or will you be happy to know that it is fixed by 15 second Press to Blank if I try that?
 
Try the 15 second erase.

If the erase fixes it, keep an eye out for the problem to happen again. When/if it does, immediately make a backup copy of the code you used. Ideally, find the temp dir where Arduino compiled the code and make a backup copy.
 
Program Button does Reset persists

15 second Press to Blank done - it worked - came up blank.

Uploaded HelloWorld Examples sketch - first power up it went bootloader. Replugged and Press does Reset the next few presses.

Went with my FORUM_qBLINK.ino so I could run it on battery to take out the computer and 'see it'. The 'Button does Reset' persists when on battery, or computer.
>> It powers to fast blink, then slows blink if left alone 4 seconds (or when USB arrives).
>> I compiled to 'Export binary' and also zipped up the TEMP folder.
>> This zip is the FORUM_qBLINK sketch folder and the TEMP folder is zipped in that folder with EXPORT HEX and the INO

View attachment FORUM_qBLINK.zip

It does not repro on every power up (seems to be over 50-90% - but there is some variable), but often when it does go to bootloader a press or maybe two will Reset and start the qBlink.
> It always restarts or goes bootloader when button pressed (not a bad button)
> It never runs when powered with button pushed, until release [ as expected ]
> Usually first press after plug in pressed goes offline, but usually one more press and the sketch restarts
> Generally if blinking (fast or slow) a button press restarts to fast blink - 10 times in a row (when I stop) not uncommon

So many counted button presses, one too many - suddenly it went BLANKED - was not 13 seconds on press? - I uploaded the saved HEX in the above ZIP and it is in repro state again. Bagged and awaiting instructions.

Compiled T_3.6 at 180 MHz on 1.6.9 where I have only a fresh 1.31b1 install and no custom edits to eeprom.c or usb_desc.c.

Control case :: on second T_3.6::
Confirmed this build on my latest test EEPROM sketch - it comes up HSRUN and ZERO serial # and fails EEPROM writes.
Also loaded FORUM_qBLINK.ino and any button press goes to bootloader - repeated presses never restart the sketch.

FYI: Here was the spec post on Press to Blank: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=115336&viewfull=1#post115336
One new feature will be added. If you hold the program button for 15 seconds (actually, between 13 to 17 seconds) the chip is fully erased, including eeprom data.
I read this as 'at least' 13-17 as it wasn't specified but presented a 'range' I took as the minimum. And saw no clarification when I posted my issue, this was the same time the bl_1.03 update made the PROTO odd and the Press to Blank fixed it.

Here were release notes: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=115374&viewfull=1#post115374
 
Last edited:
Yes - one and only one of 8 T_3.6's ( counting 2 Beta ) and this one may be the one that showed this behavior on initial programming - but I was doing six and it seemed like a simple anomaly (that could have been caused by a PC bootloader program auto reprogramming on button press) and it didn't repro again on 2nd try so I didn't even mark it, but bagged it and moved on. I have used both Beta and Proto T_3.6's extensively with no problems and one or two of the KS T_3.6's for hours and no issues.

My main recent testing has been HSRUN USB/EEPROM related - but this unit saw it minimally - when I had the EEPROM write run during SDIO Yield calls in the Greiman SD code - and that worked on all six as my hardware test SD and EEPROM baseline - both at 120 and above - then only one was left out for testing - not this one. That one ran many hours no problem. In fact it was running overnight updating one EEPROM space every second - so writing +1 to every EEPROM byte each one hour and 8 minutes and 13 seconds.
 
If i remember correctly, there is a flash-command which tells if the flash is in a good condition or not (somewhere in the manual.. i used it when i wrote my flash-library). Maybe there is a way to check the flash.
The Teensy-EEProm is simulated only, so eventually, there might be some kind of correlation..??

But ok, would make more sense if it was the one which ran the whole night..
 
Last edited:
Maybe Paul can check that out if he takes it back.

This one did only a few minutes of EEPROM testing - reprogrammed only 1 to 3 times ? - with no failures - others have done many dozens of hours.
 
:) - I'm suspicious - I really expected the 15 Second Press Blanking to recover it - if that can't then it has some external issue ???
 
Paul - post 7 above has results - and the CODE/HEX/TEMP zip of all files for qBlink sketch. The RESET on PROGRAM button behavior persisted across the Press to Blank and is in that state again with that code.

AFAIK - There is something about the hardware - or internal non sketch bits - as that same software goes fine on other T_3.6's and from other PC's - It repro's the behavior when on a battery - and other sketches on that ODD unit act the same way. And that T_3.6 was not programmed with any code that didn't go on at least 1 or 2 or 5 or 7 other T_3.6's. Probably 5 as I only assembly line proof tested it like all the other KS units (with SDIO and EEPROM test sketch). And as noted I saw this behavior exhibit during that process on 'one', but dismissed it.

I just gathered my 5 other KS T_3.6's and put the above qBlink code on each. All went to bootloader on PC and stayed there on presses - except one once - but did not repeat. All 5 with that code were then plugged into USB Battery and blink tested with 5 button presses - all went offline and stayed dark. That was repeated a total of three times on all 5 units and once the button was touched the first time the blinking never restarted.

Let me know if you have a test sketch/hex or other steps to take.
 
Not hearing back - I pulled it cold from the ESD bag - it plugged in and immediately repro'd the button behavior. It went to program about 2 in 30 pushes. And usually one more push takes it out - even long presses.

On Battery:: I noticed I could press and hold the button - perhaps lightly - but enough to feel the button click and the BLINK kept running.

Left it sit and it seemed getting warmer made it react normally more often? But not so I pressed button - clicked - kept blinking - then pressed harder and harder and the blinking persists.

How hard is hard? I tare'd a kitchen scale and it clicks about 8 ounces? I was easily pushing a pound. Sometimes it clicks and another ounce does go to bootloader. It trying to repro I hit 15 seconds it seems? It got blanked.

It was then dead for a couple minutes - plugged/unplugged - button pressed or not - no entry on Teensy.exe as bootloader.

Minutes ended and it came online in bootloader and I flashed the above saved HEX and it is now back to where it was. Teensy.exe open - on button press Windows chimes out and back the USB device - Teensy Verbose shows "nothing".

This unit has some special issue - bad switch or other component or solder connection it seems? Should be back to Brook Ct in today's mail.

I just put the permanent red marker back on the SD top for the 4th time - it keeps wiping off.
 
Not hearing back - I pulled it cold from the ESD bag - it plugged in and immediately repro'd the button behavior. It went to program about 2 in 30 pushes. And usually one more push takes it out - even long presses.

On Battery:: I noticed I could press and hold the button - perhaps lightly - but enough to feel the button click and the BLINK kept running.

Left it sit and it seemed getting warmer made it react normally more often? But not so I pressed button - clicked - kept blinking - then pressed harder and harder and the blinking persists.

How hard is hard? I tare'd a kitchen scale and it clicks about 8 ounces? I was easily pushing a pound. Sometimes it clicks and another ounce does go to bootloader. It trying to repro I hit 15 seconds it seems? It got blanked.

It was then dead for a couple minutes - plugged/unplugged - button pressed or not - no entry on Teensy.exe as bootloader.

Minutes ended and it came online in bootloader and I flashed the above saved HEX and it is now back to where it was. Teensy.exe open - on button press Windows chimes out and back the USB device - Teensy Verbose shows "nothing".

This unit has some special issue - bad switch or other component or solder connection it seems? Should be back to Brook Ct in today's mail.

I just put the permanent red marker back on the SD top for the 4th time - it keeps wiping off.



Can you try to use the PROGRAM-PIN instead of the button?
 
FrankB: No, it is in the mailbox - I think I beat the mailman - first class mail w/2 stamps :) If the bed of nails doesn't show any oddity - that would be a good test for PJRC.

Brooks: The red rubbing off was just a gratuitous comment about my efforts :) Indeed - Nail polish is a great marker though, I've got quite a few bottles my wife thought 'looked good in the store' that are fine as a marker :)
 
I have a very difficult time understanding message #15.

Since the board is coming here anyway, I guess I'll just take a look at it later this week....
 
I have a very difficult time understanding message #15.

Since the board is coming here anyway, I guess I'll just take a look at it later this week....

:confused: - maybe you'll understand when it is in hand ... perhaps tomorrow

most all of the time [28/30 in one test] pushing the program button resets the running blinky sketch - it does not enter bootloader mode.

Without bootloader mode entry Teensy.exe Verbose never reports it arrive - because Windows see's USB leave and USB arrive - it never enters HID on a Program Button Press.

Even on a USB battery - with no computer interaction - the button does reset. T_3.6 resumes fast blink in setup() of the first 4 seconds before 1 second blink . . . see sketch

And sometimes it doesn't even see the button pressed.
 
Paul - any update on this unit?

No Defragster, there's no update, and to be a bit blunt, there may never be any update or resolution. It's still sitting on my desk, with the red dot and a hand written note on the bag that's from you. I even wrote this forum thread number on the bag, so I'll know to reply here if I ever actually do anything with it.

But it's unlikely I'll ever find the time to really dig into what went wrong with this particular board.

Look, please try to put this into perspective. It's just 1 bad board. There's maybe one or 2 others ever, out of many thousands, with mysterious unresolved problems that *might* be similar. Even then, the descriptions aren't necessarily similar. Every indication points to just a few random fluke failures that don't necessarily appear to have anything in common, other than something unknown went wrong, and the rarity of it all.

If we were seeing a high failure rate, or even a trickle that seemed like it might be a trend, I'd be all over this. But that's not what we're seeing. The unexplained failure rate is extremely low. While it'd be nice and satisfying to dig into every problem, even just 1 board affected, that's just not realistic. There's so much to do that I must prioritize.

Today's effort is going into getting caught back up with forum messages. That's taking priority over diagnosing 1 board.

Over the last couple days, you may have seen I put quite a lot of work into why the Ethernet library is so slow. Right now, I'm waiting on a network tap to arrive (hopefully early next week), and when it does, improving the performance of this very widely used code is a much higher priority.

I've also been spending time reading more about EHCI software requirements.....

Also on my immediate todo list are a few minor usability improvements. Just today I helped someone over the phone (taking quite a bit of precious time) and the problem ultimately turned out he had some other device connected to his PC which Linux recognized as /dev/ttyUSB0. He had that selected in Tools > Ports, and believed it was Teensy. Even though /dev/ttyACM0 appeared, it never occurred to him that it was really the one he should choose. Some time ago, the Arduino devs improved this (they also get such questions) with the ability to sometimes show the board name for ports. Updating Teensyduino so it also shows this info is a MUCH higher priority than diagnosing a single board.

Tons of day-to-day business stuff happens here. A meeting yesterday with a cardboard vendor about improved boxes was much higher priority. Things like labor taken folding those boxes and the amount of extra packing and how we manage our supply of buying these things (the vendor will warehouse the supply for us and schedule delivery, if we agree to buy larger quantity) are far more important than 1 bad board. So are improvements to how we label work-in-progress materials, so we can track questions and issues back to specific material purchases. So are tons of little business things, every day. Even how we handle orders with certain uncommon Unicode characters in their shipping addresses (currently a manual intervention) is a bigger issue than just a few randomly failed products.

But this one bad board is still on my desk. There's 2 more right next to it. That's a total of 3 "mystery" fails, and other than "doesn't work" theme, there's no reason to believe they're related. That's only 3 out of many thousands. I do save these, and there's a good chance I will someday look into what really went wrong. But unless there's reason to believe this is a reoccurring problem, rather than just a few unfortunate random failures, odds are slim these will ever seem as important as an endless stream of other stuff. I simply have to prioritize, and unfortunately very time consuming investigating into extremely low failure rates just isn't a priority.
 
Last edited:
Blunt or not - nice to see a reply - though you don't need to type so much - or be blunt - to convince me you are busy doing an awesome job consistently applying your time where it is most useful. That post #19 and Robin's October reply email set a time frame - I was just following up because it had been another month - and it may relate to another busy thread that reminded me.

That is one of my 6 KS units - wasn't sure if I might expect a replacement. Indeed it showed trouble before most KS units were delivered - and except for that one currently active thread (with what may be a similar button problem on a T_3.5) I've also seen no reason to suspect any larger failures, but there is indeed something compromised about it that made it less than useful.

Awesome to hear that the number of odd units includes only two others.
 
Thought I should chime in that I may be experiencing a similar problem with a KS 3.6. Problem started on Arduino 1.6.12 & 1.31 after programming maybe 30 times. So I updated the software. This is now MacOS 10.9.5 Arduino 1.6.13 & Teensy loader 1.32 beta1.

Can't get the Teensy to load, the button just causes resets. Tried the 15 second hold to no avail, the program just restarts. I think there may be some kind of faulty connection. On the rare occasion I can get it to load by tweaking randomly at the board or connector.

I'll try to investigate more.
 
Status
Not open for further replies.
Back
Top