jmarsh

It's connected to the APX803 (voltage monitor). The problem is probably that adafruit intended it to reset the controller, but that's not what the Teensy's PGM signal does.

Look at the layout of the pins rather than the numbers... it appears pin 1 on the OLED board (labelled RESET#) connects to pin 16 (PGM) on the feather board.

This structure needs to be declared as packed ("__attribute__((packed))") else the compiler will add unexpected padding between the fields.

Pads default to having their keeper enabled unless you use pinMode() to reconfigure them, which causes problems with ADC (page 3407 of the reference manual mentions this).

In short: no. The code is stored in the flash but at startup gets copied into the ITCM memory and runs from there. It's still possible to execute code directly from flash (functions tagged with the FLASHMEM attribute don't get copied to ITCM and...

Try adding asm volatile("dsb"); to the end of the ISR function. The Teensy 4 CPU is so fast that it can finish the ISR before external hardware register writes have finished, which causes the ISR to immediately re-trigger. The DSB instruction...

There are two pads with a connection between them that you should cut if you're going to power the Teensy externally and use the USB connection at the same time. You can see it in this picture: In the bottom right picture (labelled USB Device)...

1us/div means you're sampling at 1MHz, half the specified SPI clock rate of 2MHz...

The short version is that loading/executing dynamic code without any sort of MMU available to remap memory is more trouble than it's worth. You've only got 1MB of RAM total to play with, already split into three separate regions (ITCM, DTCM and...

You would need to at least reprogram the MPU since the ITCM (the RAM where executable code lives) was recently patched to be read-only during regular operation.

I think I see a flaw with this testing. USB mass storage devices use Bulk endpoints, which transfer data whenever the host controller requests it. The host can stop and start the data transfer as it needs to, depending on how full or empty the...

The EHCI controller is a bus master, it can only access memory directly and can't use the CPU's cache. It has two separate buffers for transmitting and receiving (1KB each) but there are also settings for how it fills them e.g. how much of the...

Basic back-of-a-napkin maths says it simply can't work - USB2 runs at 480mbps while the PSRAM is quad SPI @ 88MHz; even with zero overhead that would be a maximum of 4x88 = 352mbps, not fast enough to keep up with the EHCI controller. The reason...

Did the F() macro get broken for Teensy4 somewhere along the line? According to https://www.pjrc.com/store/teensy41.html "F()" is meant to be able to place strings in PROGMEM (Flash). But because of this definition in WString.h: // Brian Cook's...

You could also compile the sounds into the actual program, e.g. by encoding it as a char array with the PROGMEM prefix. Then you can access the data directly without worrying about having to open a file and read it.

I only have a single 8MB chip on my Teensy 4.1 (ESP PSRAM64H) and it also maxes out at 120MHz, failing to identify at 133MHz.

The "memory support driver" is a physical hardware peripheral (FlexSPI), which only supports two devices per port. It's not a case of using an MMU to trap access and handle it in software.

Regardless of the spec details, performing octal SPI would require using the FlexSPI ports in parallel and you'd still only be getting the same amount of storage as two individual 8MB quad SPI chips, so there doesn't seem to be any net gain.

Probably it takes a certain amount of time for the interrupt outputs from the MCP23017 to update after the registers are read, for example the datasheet lists "Interrupt Pin Disable Time (tINTD) - 600ns". I'm not sure if this is actually the...

I don't have experience with the Teensy 3.2, only the Teensy 4.x (which has hardware RNG) but I think it can use the Entropy library (included as part of Teensyduino), or you can at least check that source code to see what it's doing.

Why do you have interrupts disabled when printing the 1 or 0? I don't think the code is freezing at all, you just have the output wrapped in a condition of nrot being less than zero but it only ever gets decremented, eventually it underflows to...

Try using LOW instead of FALLING? The Teensy might behave differently if the pins are already low when you attach the interrupt handler (no falling edge will occur if the output is already low).

Think you're better off using attachInterruptVector() (from imxrt.h) instead of accessing _VectorsRam[] directly.

I'm sure it would be possible if a dedicated PLL was used for a clock source (e.g. the video PLL).

That's erasing. I was talking about how the new data is programmed after the erasing is performed.

This is possibly caused by only one interrupt read transfer being queued at a time but 8000Hz requires polling at every microframe. So a read is queued, it completes and the USB controller raises an interrupt at the start of the next microframe...

Having dealt with a lot of flash devices, programming specific contents to specific locations can cause failures if the power supply isn't quite up to spec. Programming *can* be skipped for some locations where the erased value already matches...

I would suspect option 3 - something particular about that HEX causing part of the flash to be erased/written that is causing a brown-out.

For a case like this I'd simply use a diode (e.g. 1n4148) - configure the pin as an input with pull-up, connected to the diode's anode, with the cathode connected to the 5V input signal.

Hate to be that guy but is there any way to make the new forum use a dark theme? It feels even brighter than before.