Need help from code 43 problem

I've try to manual update driver to the teensy it got like this
still unusable. the loader still doesn't detect my teensy.
Is the teensy broke? the first time program (Brink LED) still work though.
Untitled.jpg
 
Last edited:
I wish I knew how to solve these difficult Windows problems.

Odds are very good the Teensy hardware is ok. Your screenshot shows the correct name, "USB Serial (Communications Class, Abstract Control Model)", which is a very good sign the Teensy is correctly communicating information, but some configuration problem exists in Windows.

Please press the pushbutton on Teensy. When the button is held down, the Teensy should disappear from the device manager, the same as if the cable were unplugged. When you release the button, it should reappear as a HID device. The ID numbers in the "advanced" tab should be 16C0 and 0478.
 
nothing happen when i pressed and hold the button
same goes after released it. as if my teensy 3.0 doesn't communicate to os at all.

I've tried to move to another computer (win7) but result is the same.
 
Last edited:
I've been experiencing some odd problems (and getting worse today) with my Teensy 3, including device not recognised errors and code download failures. A couple of things you can try:
* Use a different USB port on the computer. Sometimes Windows seems to lose the ability to properly use individual usb ports...a cold boot of the computer seems to be needed to resolve this.
* Hold the reset button on the teensy down while plugging it into the usb port. That stops it running any code on the teensy, to give you a chance to reprogam it. If the code on it is crashing on boot, you'll get unrecognised device errors in Windows when it crashes.
* Are you using the spi ports on the Teensy? My experience has been that if anything goes wrong with the spi config, the teensy often needs the spi devices disconnected from the teensy pins before it'll let you reprogram it. Seems to cause a hard-lock - I had to do all 3 of change usb port, disconnect spi and plug in with reprogram button down to recover it when this happened (which caused me to give up on trying to make my touch screen interface work alongside sdfat, because the lockups were ... frustrating).

All that said, today I've been through 6 usb ports & 2 different cables...though I haven't rebooted the computer yet. I'm having issues with downloading code to the teensy - by the end of the day one out of every two downloads was hanging 1/2 way through and then failing, with the next download immediately after it working perfectly (same hex even!). I'm suspicious that Windows itself is being a pig and needs a reboot, and both cables were cheap usb cables so it's possible that they're both faulty, but I've been getting worried today about the large number of reprogramming failures I've suddenly started seeing - probably 20+ so far, and I hadn't seen any of those before.
 
nothing happen when i pressed and hold the button


When you say "nothing happen", does that mean the "USB Serial (Communications Class, Abstract Control Model)" remains in the Device Manager while you're holding the pushbutton? That seems extremely unlikely....

When the button is released, a new HID device should appear. You may need to expand the Human Interface devices section to see it. The name will be very generic. The only way to see if it is Teensy is the advanced properties tab.
 
Last edited:
I'm having issues with downloading code to the teensy - by the end of the day one out of every two downloads was hanging 1/2 way through and then failing, with the next download immediately after it working perfectly (same hex even!).

Can you post the Verbose Info log? It's in the Help menu. Maybe that verbose info will show what's going wrong?
 
I hadn't known about the verbose log - thanks!

Here's an excerpt from the log covering part of the time when I was getting the regular program download failures. I was debugging at the time, so I had been updating frequently with Serial.print statements to trace what was happening (which is why there were so many attempted uploads in such a short time period).

Interestingly, after being left to sit unplugged & idle for 4 hours the teensy doesn't seem to want to fail programming again now.
 

Attachments

  • Teensy3Log.txt
    87.1 KB · Views: 189
I think it might be broken.
I've tried to connect with 3 computers (win8 and win7). none of them work
they have the same respond, no hardware change when pressed-hold or release. loader doesn't detected the teensy

asdsad.jpg
 
I think it might be broken.
I've tried to connect with 3 computers (win8 and win7). none of them work

It very well may be damaged. We do fully test every single board here. In fact, the default LED blink is written to the board by the USB, so if the board blinks, the USB did indeed work when it was tested here.

It's rare, but sometimes boards do get damaged in shipping.

Please email me and Robin (paul@pjrc.com and robin@pjrc.com) about arranging a replacement. Please put your order number in the subject.


they have the same respond, no hardware change when pressed-hold or release. loader doesn't detected the teensy

Can you check which version of the loader you're running? Use Help > About to see the version number.
 
Here's an excerpt from the log covering part of the time when I was getting the regular program download failures.

Thanks. That really helps. Or at least helps me see there's some sort of timing problem.

Is there some other software running on this machine that might really slow it down occasionally? I noticed a 5 second pause before each failure:

20:59:48: HID/win32: waiting for device
20:59:53: HID/win32: waiting for device
[/code]

That's highly unusual. Teensy Loader is supposed to sleep for 15 ms and retry. But here a full 5 seconds elapsed. If Windows had been running the loader program during those 5 seconds, this "waiting for device" line should appear 33. It times out after 2.5 seconds, so actually 16 should appear. No matter how long the time, one final attempt is made after 5 seconds with no response. Even that is failing, so it seems whatever went wrong on your machine that caused Windows to not run the Teensy Loader at all for 5 seconds also disrupted the communication with the Teensy 3.0. Perhaps the USB drivers reset internally? I just don't know. It's impossible to tell why it's happening, but clearly something very strange is happening.....
 
Thanks. That really helps. Or at least helps me see there's some sort of timing problem.

Is there some other software running on this machine that might really slow it down occasionally? I noticed a 5 second pause before each failure:
That's harder to answer...it's my main machine, so it's generally running a ton of stuff. Sandybridge i7 (4 core) with 16Gb ram, would have had Netbeans, Firefox, Arduino, Skype, Steam, Thunderbird, Avast, and some other stuff active.

However, I *think* an error in the usb descriptors I was using late Sat caused things to seem to work *until* you tried to do anything with the serial interfaces...serial would become horribly slow to connect (and lock up the whole computer for a few seconds), which I'm guessing now caused the pause->upload failure. :( :embarrased: I was trying to patch in an additional/alternative keyboard report interface for more-than-6-key reports. I've spent yesterday/today debugging this, and once I fixed a couple of issues in the usb descriptor, serial access returned to normal - and I've not seen any download failures since. I've attached a patch file for what those changes are now (for teensy 3), so that I can check that I haven't missed anything else.
 

Attachments

  • teensy3_nkro.patch.txt
    13.6 KB · Views: 248
Last edited:
It very well may be damaged. We do fully test every single board here. In fact, the default LED blink is written to the board by the USB, so if the board blinks, the USB did indeed work when it was tested here.

It's rare, but sometimes boards do get damaged in shipping.

Please email me and Robin (paul@pjrc.com and robin@pjrc.com) about arranging a replacement. Please put your order number in the subject.




Can you check which version of the loader you're running? Use Help > About to see the version number.



Paul,

this is when i have observed getting "code 43" problems:

NOTE: I have been developing my own firmware for serial communication protocol, kind of like the Firmata protocol

1. Too many "const static string" variables in classes.
- Making them non-static fixes the "code 43" problem. (This is definitely not a "running out of memory" problem)

2. When recovering structures from the EEPROM, if not done correctly, it gives a "code 43"

3. Teensy program "crashing" or "running out of memory" causes any program that's connected to it through the Virtual COM port to freeze until the Teensy 3.0 is unplugged.
 
If you want me to look at any of these issues, you MUST post complete code and any other info necessary to exactly reproduce the problem.

I should mention I can only spend a limited amount of time on code where you're rewriting the USB stuff. Certainly Teensy is a platform that lets you do that. But I can't provide a lot of support if you're hacking there.
 
Back
Top