jmarsh

I don't remember any issues with continuous mode, only when suspending erase/program operations and having interrupts enabled (which requires disabling continuous mode to issue commands other than read).

Maybe try replacing the body of nonblocking_flash_test() with while(1); or other construct that stops it from ever returning, so the suspended program operation never gets resumed? It's possible I inadvertently ended up working around it by...

With FreeRTOS the stack may be elsewhere. But in that case there's really no reason to create more free RAM1 since nothing will use it.

malloc (which is the newlib allocator) calls _sbrk_r when it needs more heap space so they both allocate from RAM2. The C++ keyword "new" is also just a wrapper around malloc. So I don't see how it's possible for anything to do dynamic allocation...

I think it's fine here, it's still DMA related since that's how the FIFOs get filled (and DMA being preoccupied is why the watermark should be higher).

Because you're dealing with DC signals, not AC.

About that, when I was testing auto-suspending flash writing I quite often ended up getting the flash stuck in a state that the bootloader couldn't seem to handle - likely a suspended program operation was active when the bootloader took control...

It was based on the code comment in the T3.x configuration block: I2S0_TCR1 = I2S_TCR1_TFW(1); // watermark at half fifo size If that is incorrect then yes, T3.x is broken too.

A value of 1 means there's no wiggle room at all - once a sample is sent, DMA must deliver the next sample within 1/f else an (unrecoverable) underrun will occur. This easily happens if DMA is busy doing anything at all besides waiting around for...

Perhaps opto-isolators would be a better option. Not sure if their speed is fast enough to run LEDs but at least they provide constant isolation.

I don't understand what you mean by "overruns RAM1 with dynamic allocation" - dynamic memory allocation uses RAM2. You have to be very careful moving entire objects and stacks into RAM2, quite often if any code uses DMA or other hardware-based...

There's one more thing to consider when weighing up the performance of integer math vs floating point: registers that get saved when an exception (aka interrupt) occurs. The T4's CPU has a mechanism that mostly avoids the penalty of saving the...

That sets the speed of the ESP32's UART, not the CP2102. The CP2102 is controlled by the USB host that it gets connected to, Because the Arduino IDE is setting the baud rate of the CP2102. If you connect the ESP32 to the Teensy instead, it has...

It's obviously not ok - it's using the default 115200 baud, which is why all the characters are corrupted. You need a call to userial.begin(460800); to set the correct baud rate on the CP2102.

One is the version with the Ethernet chip, the other is without. For the pinout card, "front side" and "back side" refer to the actual photo card that is packaged with each Teensy, not the photos contents. If you want a photo of the underside...

No mention of how you've connected VCC on the WS2815s. If I infer that you've connected it to the 3.3V output on the Teensy, that would explain why it looks like the voltage regulator has shorted in your thermal images. I'd also question where...

Nobody is going to be able to say, without any information about how anything is being connected.

You had the right idea here, but it should be __attribute__((section(".progmem"))) instead. Otherwise just #include <avr/pgmspace.h> to make the PROGMEM keyword work.

Just out of curiosity, does it show up when powered by 3.3V if you run an I2C scan?

Sometimes it's enough just to set the I2S watermarks to sane levels, rather than the incorrect Teensy3 settings that were reused for Teensy4.

No. They're completely separate. Setting the speed of Serial doesn't actually do anything at all because it's an emulated UART. Your "USBSerial userial(myusb)" object is a driver to talk to some sort of USB-to-UART chip on the ESP32 - it'll be...

You're setting the baud rate of the Teensy's USB port, not the userial object (which is the USB serial converter used by the ESP32). But why connect them via USB anyway, when you could connect the UARTs of the ESP32 and Teensy directly?

You should be able to, but you may need to initialize SD after you set up SPI2 to use the alternate pins.

Is FLEXSPI2_CLK_SEL(2) PFD1 rather than PFD0? 1.60 initializes FLEXSPI2 at a slightly higher multiplier than before. So it may just be more important to gate it properly before modifying.

I don't think this is doing what you want it to.

I had a look at the HD44780 repository on github, I hope you took note of this warning: It seems this library does not allow use of any I2C interface except Wire, it isn't possible to use it with Wire2 unless you edit the code yourself.

The TwoWire library that ships as part of Teensyduino already supports 3 interfaces (Wire, Wire1 and Wire2) for Teensy 4.0.

Silicon generating a static charge?

It depends on the specific device. Most should be fine with it. For safety I would power the device without connecting SCL/SDA to anything and measure them, to ensure the device does not have its own internal pull-ups to VCC (5V). If it doesn't...

I would add external 3.3V pull-ups for any more than one device, assuming none of them incorporate their own pullups (and if they did, that they were not connected to 5V because the Teensy's not going to like being directly connected to those...)

In most cases it's as simple as changing old references to the sdfat object to "SD.sdfs".

No, it means the MKL02 has already been used to initialize an IMXRT chip but it does not match the one currently connected.

The MKL02 is not a "bootloader". It is involved in the power-up sequence and takes control of the CPU when requested, but it does not take part in the boot process. The steps you're talking about (configuring clocks, peripherals etc.) are done by...

Model numbers usually reference the number of bits, not bytes. APS6404 is 64 megabits = 8 megabytes.

No, they registered to spam a link to a supposed pirated android game that's probably just malware.

So you only need 3.3v ->5v conversion? Pretty much any 5v logic chip will work for that, as long as it reads a 3.3v input as high (and doesn't have internal 5v pull-ups). Bidirectional shifters are notoriously unreliable, TXBs are "ok" for 1:1...

But the MMU is only used by the CPU - half of the processing on an MCU is done by the peripherals, which bypass it. So there's no protection there and you have to manually translate every time you want a physical memory address. You're not going...

What good would an MMU be for such tiny amounts of RAM? How are you going to remap anything when you don't even have enough space for page tables?

The wav file you are trying to load is probably not using the correct audio format.

Because one is the device name, the other is the volume name. A device can host multiple volumes.

No. As stated at https://www.pjrc.com/store/ic_mkl02_t4.html: The "Q" chips only work in quad mode, which makes them incompatible.

But then the board effectively turns into a micromod, which can mess up the pin numbers and other software behaviour...

If it were that simple everybody would be making their own Teensys instead of buying them...

When the reference manual talks about SNVS_LP having "Zeroizable Master Key", which DCP key is that? I'm assuming it's not really a one-time programmable key but rather a key that lives in the battery-backup powered memory and gets wiped when...

DMA channels do not run concurrently though, at least on the Teensy. Fixing the incorrect I2S TX watermark levels used in the Audio library helps significantly, so that the hardware buffers more than one sample..

If a library is written to use a GPIO as CS then it's not going to matter which pin is used. The only advantage of using the hardware CS pins is that the SPI hardware can control them automatically when a transaction happens (so no need for...

That looks weird. USB device addresses are only 7 bits wide so 128 isn't a usable value. Unless linux just "works that way" by storing addresses internally by mashing the hub address and device address together.

Which OS are you using? The USB VID/PID is configurable and can vary between the default blink sketch, prog mode and regular sketches. If you're using a linux-based OS the default teensy udev rules file should include all of them, but maybe that...

The micromod works the same as the regular Teensys, it still has the helper chip attached to the JTAG port.

I'm confused, if you're trying to work out why the Teensy won't recognize your mouse why do you have anything else plugged in? Just remove it all and run the sketch with only the mouse connected.