jmarsh's latest activity

There's at least two methods I know of that are likely to trigger random faults that seem to be due to brown-outs / power issues: very heavy usage of FLASHMEM functions, or high rate of interrupts with WFI instructions in between.

It can run at that voltage... but it will also fault if stressed appropriately. The formula I used that never saw any random faults was 1.15V for anything over 24MHz plus 0.025V for every 25MHz multiple above 432MHz, e.g. for 528MHz: 1.15 +...

Done. Here's the updated boards.txt file. Just copy to Arduino15/packages/teensy/hardware/avr/0.62.3 to replace the old boards.txt.

The voltage adjustments for the industrial MCUs were reverted in the core though, so beware of random issues.

I think the maybe-uninitialized warning should be nuked. It's far too easy to trigger it by passing a variable by pointer to a function that writes to that pointer, i.e. it is intended to initialize the value. This has been a standard C...

The website says the resolution is 1440x2880@60Hz, there's no way a Teensy could drive this.

I'm getting an annoying "dangling pointer" warning that is a false alarm. The function in question is this one, I'll try to explain what is happening: - atomTimerDelay() is called to delay a thread for a set amount of time, during which it will...

That error happens when trying to link with a function that doesn't exist. If the function is never referenced the linker never has a reason to look for it.

But USB power is also used to power SNVS, which should be active before 3.3V power is connected. This doesn't happen if you directly connect a 3.3V supply (unless you have a battery connected to VBAT).

Teensy is simply not intended to be powered from 3.3V alone, there are some pins (on the MCU, not the PCB) which expect 5V.

This is why I asked you to look at it again, in the commit you changed ALL of the sections in the T4.1 linker script to rx. The changes for T4.0 and micromod are fine.

@PaulStoffregen not sure if you saw my github comment on your recent commit to modify the linker memory attributes (since I can't see the comment myself, it seems to have vanished into the void) but the changes for T4.1 seem to be an error...

That's generally not true any more due to requirements for position-independent code/ASLR support, 64-bit programs use 32-bit displacements relative to the switch's jump instruction.

From the Sketch menu in the IDE there is an "Export compiled binary" option that will build the .elf in a subdirectory of the sketch folder. Otherwise by default it will be in a temp directory somewhere, decided by the OS.

I'm curious how you think CrashReport squirrels away the information if you think catching a fault requires JTAG.

c++ version isn't the same as gcc version. gcc 15.2 is meant to fully support up to c++20.

Individual pin mux doesn't need to be set to FlexIO unless you want it to read/drive that physical pin, the FlexIO state register is the internal state.

Yes. The main problem is there's only a couple of shifters that can do parallel output to IOs (width >1) so using state mode is almost always necessary if you want to use both bidrectional output data and bidirection output enable.

If it's a receiver it should use input mode. Shifter 1 will have to use 8-bit width in order to control direction of all 8 lines. I would consider changing your pin definitions so the data pins are on FlexIO 0-7, so their direction can be...

You don't need any shield to use T4.1 as a USB host, just a cable to connect to the host pins...

Why does it reset? That would indicate it is not hanging, it is encountering an error. Use CrashReport to see what it is. You really need to include a complete sketch if you want anybody else to investigate the issue, things like the...

Call pinMode(x, OUTPUT) before using digitalWrite.

Not likely. The only issue with using USB and external power at the same time (without separating the VIN/VUSB pads) is that the 5V supply lines will be joined, causing voltage regulators to fight each other.

Noooo. Teensy's pins can only sink or source a certain amount of current (roughly 4ma). Without a resistor that limit would be exceeded, causing internal failure.

Is that going to cause issues with Teensy 3.x which also uses the classes in the audio library on top of its own core files?

You're missing another open() method in FatFileLFN.cpp, and yet another in FatFileSFN.cpp.

Clock it as slow as possible. Simple data logging shouldn't require a high clock.