Search results

Splashes near the on/off pin would be unlikely to happen, since that among the 5 pins below the SD card slot, we only use/solder the VBAT pin, which is as far away as possible from the On/Off pin. I also think it unlikely that this is the cause for two reasons: 1 - The datalogger with this...

I'm also considering some issues regarding the Teensy LDO regulator NCV8186AMN330TAG, which is present on all my current Teensy 4.1 that failed somehow. In addition to the issue described on this thread (regarding VBAT preventing boot), which happend to me around 3 times, I've also had around 10...

@sicco I agree that the possibility of water entering the equipment's enclosure, as you describe, is valid and can indeed happen. However, in the cases we've had, the equipment was opened for verification and the inside was completely clean and dry, with no sign of water or insects. In the two...

@sicco You're absolutely right about the environment and climates where those systems operate. However, the Teensy and all other electronics are placed inside a IP66 enclosure, so no water or insects can contact the electronics. Regarding condensation, it also doesn't happens because the...

Hi @defragster, thanks for your input. It seems weird to me that the floating On/Off pin would have been triggered, specially when its so uncommon with our Teensies. In any case, considering that I don't need the functionality of the On/Off trigger in my project, VBAT pin is always around 3V due...

We are facing the same issue (or very similar) with some of our Teensy 4.1 boards. Just for a quick context, we have hundreds of Teensy 4.1-based dataloggers/signal acquisition systems with custom PCBs. These dataloggers operate continuously and often in remote locations, powered by batteries...

That's great info. I'll check that out and see what I can do to improve my current circuit. Thank you all for the help!

Honestly, I have never tough about this problem before and am now concerned. Considering a scenario were I can't change the plug for a newer one specifically designed for hot plugging, is there any easy solution to protect the circuit from this situation (12V pin and data pin connected before...

Nice! So far we have been using just normal 3.3V UART TTL over those 10m wires and it was working normally, while I agree that RS232 or RS485 would be more suitable for the job. The cables are just regular multiconductor cable, unshielded and not twisted. We have been having success with this...

Thanks for the support! I will try to incorporate RS-232 on my next circuit design. Right now, it doesn't have the space or connections for the needed RS-232 transceiver, like the MAX3232. I will try to solve the issue with the diodes and the resistor in the current circuit board version.

No, it doesn't. Most of the times, all of them will connect the same time. Depending on the inclination of the plug or if any of the pins are loose, any of them could connect first than the other. That's a very interesting take. Haven't tough of this before . Nice ideia! Would it be something...

Hi Paul! The connector has a specific orientation that prevents it from being plugged in any other way. Check the image below: Even so, after the first Teensy was damaged, I took extra care to plug and unplug the connector the right way and without jiggling. The new Teensy 4.0 still suffered...

I have an application where one Teensy 3.5 (main module) communicates with a Teensy 4.0 (remote module) over a 10 meter wire. This wire carries the TX and RX signals from Teensy 3.5 Serial6 to Teensy 4.0 Serial1, GND and 12V that powers the remote. The 12V line goes to a step-down to convert to...

ericscottf, another option would be to use TeensyThreads library and have one thread be your main (with the code you currently have inside loop) and other thread keeps checking the USB Serial for available data. Keep in mind that TeensyThreads is buggy and unmaintained. I also don't recommend...

Thank you all for the replies and suggestions! Ok, now I got the general idea. I will try this out in the future depending on the outcomes of my current test setup. So as far as I understand, in order to achieve this I would need to have an external oscillator and an external clocked...

Hi mborgerson and Paul! Thanks for the insightful replies as always. I ended up ordering two different external oscillator: Pletronics 1ppm VCTCXO and Connor Winfield 5ppb OCXO My first attempt was to remove the standard Teensy 24 Mhz crystal and connect the output of the external Pletronics...

That's great advice, Paul! If a TCXO has enough temperature stability for my use case, what would be the specs I should look for when selecting the part? For example, input voltage, output signal form and voltage. Maybe if you could provide the exact part number of the current 24 MHz crystal...

I'am working on a project using Teensy 4.1 where I read the frequency of a Quartz Crystal Microbalance (QCM) using the FreqCount library. My goal is to be able to detect very small changes on the QCM frequency (natural frequency around 5 MHz) caused by deposition of material (added mass) over...

Doesn't seem to be your case, because you are using Arduino IDE, but I had the same problem when using VSCode + PlatformIO and the solution was to include the compilation flag "-g" when compiling the sketch. Make sure Arduino IDE is including this. Another thing to keep in mind is that you may...

I just stopped using pin 48 and moved to another pin. I am not planning on changing the default startup code, and would have to do this every time we update Teensyduino. It seems like adding a pulldown resistor to pin 48 wouldn't help either, because it is being actively driven high. Thanks...

@jmarsh Applying this patch solved the issue for me! Many thanks. Now if the crash happens inside the thread, the correct place is show in addr2line and the .lst file.

Thanks jmarsh! I decided to change from pin 48 to other pin and this fixed the issue for me. As for pin 36, I placed a pull-down using a 1K ohm resistor and was also able to solve the issue with this pin. Still not able to understand why it only happens with certains pins, thou.

Great post! Helped me a lot when I was getting started with CrashReport functionality :D

I am currently facing a similar issue but with different pins: 36 and 48 (back) on Teensy 4.1. My situation is very similar to the one from @mwolters. I have chosen 8 different digital pins to control 8 relays, and pins 36 and 48 always started HIGH during Teensy startup, even if it was just a...

My final solutions - still using those As this thread became long, I will add to phorton1 solution above and try to summarize my final solution to both problems related with TeensyThreads (non-reentrant code and malloc/new). I hope that someone finds this useful. Problem: malloc() does not...

Thanks @defragster and @jmarsh for the tips! I will modify my code to start using the CrashReport.breadcrumb functionality to help better track the crashes. Also, just a quick question: Is the location where CrashReport stores information to be displayed when Teensy reboots different than the...

The breadcrumbs functionality seem very nice. However, I am still not sure which strategy to use to help me pinpoint unknown crashes that I have no idea where could have happened (think a 40000+ lines program that crashes intermittently, with 4 cooperative threads). Maybe if I at least knew...

Hello all! Sorry for commenting on this old thread but I am facing a very similar issue regarding debugging a crash in a Teensy sketch that uses threads (TeensyThreads library). I have noticed that every time the crash occurs inside a thread, the crash report will report the "yield()" function...

The main thread is usually thread ID 0. You can check it by running threads.id() function. To create other threads, you will use threads.addThread(thread_function), which creates the thread and will return the thread ID of the created thread. There are many ways to use TeensyThreads, as it...

Not exactly the answer for your specific problem, but I do have my two cents related to the issue with TeensyThreads, which may or may not be helpful to you. I have a very large program (30k + lines of code) which use dozens of different libraries, none of them directly thread safe. In the...

That's great! Thanks for sharing the results. That's exactly my case, a code port from a Teensy 3.5 to 4.1 and this ADC pinMode config change was going completely unnoticed. Glad I read this post out of curiosity while scrolling through the forum.

Hi lokki, were you able to fix the problem adding pinMode(xx, INPUT_DISABLE) to setup()? I was not aware of this issue and will probably need to fix all my T4.1 projects if that's the case.

1+ for using QNEthernet. It uses more RAM, but it's more stable and has more options than NativeEthernet. I had better luck with QNEthernet in my projects. Also, it's more actively maintained.

Just a quick update. I have tested with the last version which integrates the "buffers-in-RAM2" modification and everything seems to be working great. Gained extra 15K bytes of RAM1 space, which is precious for my application. Many thanks!

That's amazing! Thanks again shawn and Paul for all the support. Looking forward to the next QNEthernet release :D

Hi Shawn, I built with the later compiler and it did in fact help. The RAM1 usage went down by 40kB. As for reducing the lwIP pre-allocates, I didn't have much success. Setting LWIP_MDNS_RESPONDER to 0 did not affect my RAM usage. Changing MEMP_NUM_UDP_PCB to 2 instead of 8 and MEMP_NUM_TCP_PCB...

Hello @shawn, first of all, thank you for creating and maintaining this awesome library! I had better luck with QNEthernet than the NativeEthernet library and recently started using it on my project. However, I noticed that in my case, the RAM1 consumption for this library is 100 kB higher than...

@KurtE and @defragster thanks for all the info! I have tried many things and I think I managed to "solve" my issue regarding slow USB Serial initialization times. I just need to remove the Serial.begin() function. Than magically everything starts up fast again, both MTP and SERIAL. The other...

Wow, I didn't know that it was possible. Thanks for showing me that thread! For Teensy 4, would the procedure be similar? And also, in that example, the EEPROM was checked right after the startup, so the desired behavior was to just delay the USB initialization to be able to choose which...

@KurtE , first of all, thank you very much for developing this library, it's super useful! :D I have been using the latest version from the repo and TD1.57. I would like to be able to only activate the MTP functionality when the user sends a specific "Switch MTP ON command", which would begin...

Ecodrone, I have also written a very basic and incomplete "library" based on the dcptst.ino code by Manitou. So far it seems to work when I use the same settings as the example function do_aes(); When I tried to explore some other options, like using a different kind of key such as OTP key or...

Hello guys, it's been a while... If I used the OTP key or Unique key options, which are factory defined, stored inside the processor, unchangeable and unreadable from software as far as I know (I do not have access to the security manual of the processor), would it be more secure? I ended up...

Thanks again, Paul! I will study this possibility and try to improve my current security scheme.

Thanks again, Paul! I've read the Teensy Code Security page some months ago and found the information really useful. I agree that a lockable Teensy would be the best option for me in this use case. Unfortunately, I already have a stock of standard non-lockable Teensy 4.1 bought in high quantity...

Thanks a lot defragster, Paul and manitol for the help! Paul, without a lockable Teensy (which is my case), would any encryption library be vulnerable to an attacker with a JTAG and access to the non-encrypted flash memory or it is just the case of dcptst.ino? The reason why I am using AES is...

I think https://github.com/manitou48/teensy4/blob/master/dcptst.ino was just a test that manitou48 performed, but it is not yet developed into a functional library. With time, I think that I might me able to convert this code to an easy to use lib. However, my use for the cryptography functions...

I am currently adapting a huge application which was originally developed on Teensy 3.5 to the newer Teensy 4.1 platform. So far, I was able to find a replacement for almost all the libraries which I used and were exclusive for Teensy 3.x. Unfortunately, I couldn't find an substitute to the...

Yep, I think not only malloc(), but also the other shared resources I was protecting with locks such as Serial, EEPROM, SD and the command queue don't need to be protected anymore, as one thread always starts and concludes the operation before the other starts. I have checked my code and there...

I was using 5 ticks (5 ms) for the main thread and the comm thread. For the led blink thread I was using just one tick. I wasn't aware that the SPI and I2C communication was non-reentrant, so my reasoning for those short timeslices was that the user would feel more like it's three parallel...

Just an quick update. I currently have 3 different Teensy 3.5 running my full application (with huge slice times for each thread and the threads stack placed on the main thread's stack). No crashes or reboots yet! :)