defragster

This may be the reason it won't start with that battery on? That keeping the RTC part alive with 3V is good to help power on in some cases noted by PJRC. But that pin like others is 3.3V limited and having higher voltage may be blocking startup...

Follow up. Here is the output after a bootloader update. It does NOT report Connected until the bootloader update is fully complete, satisfying my requirements. Connected [History] -> {empty} -> usb:0/140000/0/5/3/4/2 hid#vid_16c0&pid_0486...

With a Teensy 4.x there is a RED LED by the USB connector. Only the bootloader can power that RED LED. Anytime the RED LED is on the PJRC bootloader chip is in control of the Teensy MCU/Processor. > This includes any non-solid blink patterns that...

Very cool recovering and reading that old data! Especially being able to use it again. Teensy 3 USB uses 64B blocks. If you can tolerate/arrange read delays as needed put a delayMicroseconds(100) between 64Byte writes. That is only 12 blocks for...

Good find on 48MHz testing. The USB Hardware on Teensy is the processor itself. Perhaps there is a place where a small delayMicroseconds() slowing the output stream would prevent the corruption? Is this printing just for debug testing? I ran...

Note: The Teensy has no Reset Button. It is a Program button where the bootloader halts the Teensy inviting an upload as occurred. When the Bootloader is in control it presents as a valid USB HID device to facilitate the upload. Try again with a...

Odd, this is not a common problem. Can a simple sketch be posted that demonstrates the issue? With USB Serial, PJRC has implemented a true USB device using true USB hardware on the Teensy MCU that conforms to the Windows 10&11 built in driver...

Using link from defragster post #42 - they are GONE - Thanks.

Reading above Priority came to mind - and scanning the linked thread : could be awesome or could be a time sink. Could there be a 'priority' flag of some sort? > Pri 1 - run this every time ... down to run in turn every '# event' turns (as it is...

This looks like a spammer? On: https://forum.pjrc.com/index.php?whats-new/

Sounds like a usable solution. PJRC allocates USB buffers in RAM2/DMAMEM and that works taking from that 'less commonly used/filled' memory. Example code above when non EXTMEM used both DTCM/RAM1 and DMAMEM/RAM2 and they showed same completion...

Yes ... They just get placed in the INO file and they are called with each yield() - nothing else required. this looks helpful: https://arduinogetstarted.com/reference/serial-serialevent

Yes, that was the concept ... On forum.arduino.cc it looks like this - the paper copy in the corner.

Once the .begin() is done there should be no problem calling this if the comment is complete:

Added this on two T_4.1's: {1 with and 1 without} PSRAM and there are no chars printed here - added in setup() to current p#2 code: int c; while ( (c = Serial8.read()) != -1) { Serial.println(c, HEX); } Funny - read right over that...

yield() is weak and easy to replace in sketch. It is more efficient these days. It mainly polls any present serialEvent() functions and then returns. It doesn't actually delay() or waste much time before returning. If no serialEvent() code is...

Old forum allowed BOLD and formatting within code blocks - though it also evaluated SMILIES :) ;) in code output unless that was manually turned off per post. I supposed those two are tied together here in XenForo and their CODE formatting...

RE p#4 wondering if DMA in use and {FULL SPEED} CACHE gets flushed? {though shouldn't touch this area?} Or if alternate buffers consume more of the cache and 16KB half of cache gets swapped? Reduced to 4KB and still fails to complete: Reduced...

Quick test for this: With 16KB on BUFFSIZE this should be retained in 32KB DATA data cache? memset(EXBuffer, 0xDF, BUFFSIZE); int jj = 0; for ( int ii = 0; ii < BUFFSIZE; ii++ ) jj += EXBuffer[ii]; Serial.println("Writing buffer in EXTMEM...

Some websites offer a 'copy button' for code blocks grabbing everything within to the clipboard. Is that an option? - rather than having to manually drag select code text start to end to copy. Note: good for the forum - my bad - just came back...

Noted p#29: SR+ could close threads and post on closed threads - that allowed the noted closed thread to only issue 'future release notes' > also catching dupe threads as was done today Other thing was edit of 'user posts' - where that was...

Something odd for sure - nothing like that seen here at default 600 MHz - even without the recurring Serial8.print()'s in loop(). If not connected there should be nothing coming for Serial8.available() - unless it is picking up noise from the non...

Thankyou sir !

Not sure what 'of import' changed in the code below {added some intermediate printing} - but with a JUMPER on Serial 8 Rx<>TX, i.e. pin 34 and 35 this code. The Serial8 Jumper is providing known proper UART Serial8 connectivity and data for sure...

Can confirm it fails to return - even after some random edit efforts. Moving from compile alloc to extmem_malloc() also failed but works with standard DMAMEM malloc() // EXBuffer = (uint8_t*)extmem_malloc(BUFFSIZE); // also fails to complete...

Indeed, they are rare and one time events performed only by the PJRC Teensy.exe. That is a change to software on the bootloader chip and is very rare with non in recent memory - but will be done when Teensy.exe performs an upload and detects old...

the current clock speed is found using: F_CPU_ACTUAL

I should have led with that it seems :) Bad solder seen to affect other things - not noted it as causing such issues on SD before - but noted now!

UPDATE: FIXED So basically I redid the solder, and it seems like that fixed the issue. Both my SD cards are being detected now, and I am able to play WAV files. Hopefully it stays this way until my presentation next week :) Thank you for the...

With Serial2.begin( baud ) pin 7 will then act as RX and pin 8 will be set for TX. It should make no changes to pin 9 or other. Both of those pins will be found to be resting at 3.3V after the .begin() and ready for 'baud' rate UART I/O.

Seems like it was failing to act as intended - posted some weeks back attempts to demo in a sketch ...

Would have to look at the ADC LIB code. Guess was it would wait internally for isComplete - but reading observed 15X sample speed it may just return the last reading - or ... https://github.com/pedvide/ADC/blob/master/ADC.cpp#L700

What version of TeensyDuino is in use? 1.59 beta 4 should release soon - the beta 3 version has some changes that may not relate or help. Were both cards reformatted with the sdCard Formatter? In the past that has worked for proper formatting...

There are many components on the bottom side that could be disturbed or displaced if hit with enough heat exposure.

SR+ had some extra housekeeping abilities on the old forum that aren't present. Another noticed today, with the pending release of TD 1.59, the ability to post from a closed thread is gone - so sending out the notice on...

I had encountered an issue with the USB connection of my Teensy 4.1 which manifested as a blinking Monitor window following the upload, during which no activity occurred in the monitor window. Today I updated with the Teensyduino (1.59 beta 3)...

I'll package up 1.59-beta4, so we can have a week of testing just to make sure everything is looking good.

probably a good time - Gotten a few changes that have been tested/shown to work and nothing drastic recently.

T_4.x not only runs much faster than a T_3.6 - but the USB connection is 480Mbps instead of 12Mbps and can overwhelm a PC. Be sure to select Teensy_Ports as it provides a PJRC optimized SerMon that can better keep up.

Have seen an interrupt like LED BLINK continue after loop stops, so that isn't the best measure. Maybe if the blink was altered based on processing by loop() funning - or other interrupt code - to do double blink or switch from off/on/off blink...

Here seems good - it will be seen. Details presented so far don't describe an issue noted before. Added detail needed. Almost seems the Teensy going offline or having trouble staying connected. Start with a simple Blin kand add USB output and...

The 3.3V T_4 has a limited specified tolerance of perhaps 10% over 3.3V toward 3.6V - well below 4V. So, with luck at hand only one pin is dead, and the reminder of the chip will continue to work as designed for a long usable life.

Opps - too quick a look - scanned those as LOCAL vars even though there was wonder about interrupt changing them.

Not clear what "Sometimes the output just freezes for a few seconds" means? SerMon output or blinking LED? Note two of these pins are the same #13 as that is what LED_BUILTIN resolves to. #define N_PINS 3 const int pins[N_PINS] = { 13, 14...

Teensy 3 is slow compared to a T_4.x - but for that PJRC refined the IDE SerMon using Teensy Ports to be more faithful. Give that a try instead of TerraTerm and see if the same loss occurs. The problem is doubtfully the Teensy sending, but...

That last used here file : boards.local.txt Looks like this {handy to drop in after Updates without needing to change the actual boards.txt each time}: As @luni notes TyCommander adds great features so I use it often with multiple Teensys...

Awesome to see it drop in and working shawn!

I agree with @defragster. It looks like you're still including NativeEthernet.h and/or NativeEthernetUdp.h somewhere. Also, please attach the INO file.

Including the lines where Arduino IDE shows the LIBRARIES USED is important if Verbose is on those lines should be present. All the lines are warnings ... Looking at: The first two would be found in the unshown INO file and easily corrected...

@Megatree_de: The library is here: https://github.com/ssilverman/QNEthernet And these lines in an included example show usage noted in p#4...