1N36B teensy 3.1 non working with USB

Status
Not open for further replies.

zachtos

Well-known member
I have a product we have been making for a few years now that we developed with Teensy. Has been working great, but now we somehow got an old batch of chips. This old batch of chips seems to only work if I compile in teensy with USB disabled. If I turn USB off, then I can get code to run, otherwise it hangs up on power up. I suspect it's from the chip maker errata. I do not know if anything can be done, but any ideas could help. All of our bins of past have been 2N36B or 3N36B.

http://www.nxp.com/docs/en/errata/KINETIS_K_1N36B.pdf

In the meantime, I have over 2000 units of a product that need chips removed and replaced with a newer bin, and just lost a ton of money...
 
Normally I don't investigate unless a complete program is posted, but this seemed simple enough. I dug out the original Teensy 3.1 prototype, which has the 1N36B revision chip.

DSC_0559_web.jpg

Since you didn't post code, I tried this program.

Code:
int led=13;

void setup() {
  pinMode(led, OUTPUT);     
}

void loop() {
  static int count=0;
  Serial.printf("count = %d\n", count++);
  digitalWrite(led, HIGH);
  delay(1000);
  digitalWrite(led, LOW);
  delay(1000);
}

I used Arduino 1.8.3 with Teensyduino 1.38-beta2, running on Linux 64 bit.

This program uploads, and when I open the serial monitor, it appears to be working properly.

sc.png

As nearly as I can tell, the very latest USB code is working perfectly with the oldest Teensy 3.1 board using the old 1N36B chip.

Now I'm trying to be sympathetic to your unfortunate situation, but I would like to remind you that you do not appear to have purchased 2000 of anything from PJRC. Still, I found this old prototype and tested it, to check whether the latest code really works on the oldest Teensy hardware.

I'm sure you know how things work here. We expect you to post a complete (and hopefully compact) program to reproduce the problem. Especially if you're going to claim there's a bug in the Teensyduino code, you *must* provide this sort of detail.

I hope you do manage to sort out what went wrong with those boards you made. It certainly doesn't look like it's the Teensyduino USB code as you initially assumed.
 
Thanks, yes the code was just the blink example. I compiled with USB serial, and the code would not run. If I disabled USB, it would run. If I swapped to another bin chip on the PCB, it would run either way. PCB schematic is pretty much the same as teensy with no bootloader chip. Code was loaded via JTAG programmer. The problem mystifies me now, as I was certain it had to be one of the errata on that bin, as any other chip has no problem.

Speaking of JTAG programming, several members have reached out to me over the last year or two talking about bootloader support. I think there is some money to be made for you here. Companies like myself, that only have a junior engineer and ambitions to make a quick product, can not afford to pay for a special bootloader chip on every unit, but would happily pay for a bootloader license that could be programmed via JTAG or teensy to the final PCBs. We love creating rapid prototypes with the power of ARM and simple arduino type interface, but after ready to go mainstream (big or small), teensy kind of leaves us hanging if you want to have a consumer product that can have it's firmware updated. I would migrate to the 3.6 teensy in another device, but same problem as mentioned.
 
Thanks, yes the code was just the blink example. I compiled with USB serial, and the code would not run. If I disabled USB, it would run. If I swapped to another bin chip on the PCB, it would run either way. PCB schematic is pretty much the same as teensy with no bootloader chip. Code was loaded via JTAG programmer. The problem mystifies me now, as I was certain it had to be one of the errata on that bin, as any other chip has no problem.

As PJRC's bootloaer chip handles the situation, maybe your JTAG approach needs some revision?
 
As PJRC's bootloaer chip handles the situation, maybe your JTAG approach needs some revision?

I am now getting word that 10% of our chips in the same bin 1N36B work correctly, and the other 90% do not. I wonder why some will program but not launch the applications, but others will? It is so frustrating dealing with intermittent issues like this. We are getting a refund from the vendor of the chips, but does not pay for repairs or lost shipment time.
 
Sounds like someone simply sold you bad chips.

If you keep any of them, I'd recommend running this test program on every board.

https://github.com/PaulStoffregen/k72memtest

On the subject of a hypothetical bootloader license, what do you imagine paying per piece? (I'm guessing much, much less than we would ever consider selling)

Thanks, I will try that test tool in the next week.

Per device is not really appealing to business owners. I could not make that work with our owner myself. He basically said, well if we ever sell 100K units, (very possible), then we end up paying $500K for bootloader chips, no way. So it just doesn't scale effectively over time. We could hire a full team to develop product from scratch in that case. A flat license fee based on per product, perhaps $1K-$2K per product, depends on the quality of service and support. I imagine a term limit on support. I would expect a simple bootloader that runs on any operating system, that could be 'branded' if needed (company logo on the app, or whatever it is, or just a USB MSD). If the price was too high, then users could just hire contractors to get it developed, or get a copy of Keil and get to work. Also could never be too high, because we are quite restricted on chip choices as is, NXP only. Enforcement is tough, not really sure how that works, but I imagine if reasonably priced, you would not encounter any issues. I imagine there are many others out there, maybe worth a thread to test the waters to see if worth the effort.
 
Yup, pretty much guess of a lowball price. Ain't gonna happen.

Even even the mentioned design support would need to be at least 10X, and *never* done on a flat fee basis! From my point of view, that's just begging to get endlessly bogged down in a high maintenance project.
 
Yup, pretty much guess of a lowball price. Ain't gonna happen.

Even even the mentioned design support would need to be at least 10X, and *never* done on a flat fee basis! From my point of view, that's just begging to get endlessly bogged down in a high maintenance project.

Thanks for your support, I would be interested if such an option came to fruition, similar to uTasker but better.
 
Status
Not open for further replies.
Back
Top