jmarsh's latest activity

Get rid of the second begin method, add format parameter to the first method with a default value so it doesn't have to be explicitly given? That should work with all existing code...

There's quite a few ways it can be done depending on how you plan to connect them together. GND + one wire? Two or three wires? One Teensy connected to the other Teensy's USB Host port? Via ethernet?

No? As long as it's actively running a program auto-uploading should work. If it doesn't work the program has crashed, in which case it won't be able to trigger a GPIO anyway.

For automatic uploading (no button press required) to work, the Teensy has to be running a program based on the Teensyduino core library. This is because it includes special background code to detect when the host PC want to upload a new program...

I was talking about OP's code. It looks like it uses a simple heap allocator to reserve space for the executable code, that may cause problems with the cache management functions since they can only operate on complete cachelines (will need to...

PSRAM is cached by the CPU. The data cache is separate from the instruction cache. I don't see any code to flush the data cache / invalidate the instruction cache after copying the executable code to PSRAM.

Can't make an informed guess without seeing any code or proper description of the fault.

Cache lines are 32 bytes.

Just to confirm, the MKL02 is one you bought from PJRC and not just a random one from somewhere else?

There is no reset pin. It reboots when the program crashes. If it didn't, it would just hang indefinitely so disabling the reboot function won't achieve anything. Add the code that Kurt posted above to see where the crash is happening so you can...

Can you run "uname -m" to show what the OS architecture is (32 or 64-bit). "file not found" is a typical error when trying to run a 32-bit app on a 64-bit OS when a 32-bit library dependency is missing.

This could be an arduino IDE issue: if a library is included in a previous compile but you then remove it (or comment it out), the old object files don't get removed from the build directory and still get linked. So at some point you had the...

What exactly did you do?

Maybe. You might need an external power supply for all of this. It's hard to say because the specs for the wifi board say it may require up to 450ma @ 3.3V. So you can't just connect it to one of the Teensy's 3.3V pins without risking overloading...

Why does that sample target the gateway rather than a well-known public NTP server? I don't think I've ever owned a router that implements NTP - most of them don't even seem to allow manually setting the date, which would make NTP a bit pointless.

USB data pins carry significantly less voltage than 5V (~3.3V for low/full speed, 400mv for high speed). Regardless those pins aren't GPIOs so they don't have to follow the IO pin electrical specs, they're designed specifically for direct USB...

It's doubtful that a USB drive would have pulled too much current because there is a protection IC that limits the host port to 500ma, and also a fuse that prevents the Teensy from pulling more than 500ma from its USB device port. The problem was...

The flag and count variables are in RAM2, any minor change to your program may end up placing them in an unsafe area that isn't preserved across reboots. Using the eeprom instead would solve this problem once and for all.

This still relies on undependable RAM2. If you have a reliable method for distinguishing a cold boot, why not use it to set a counter in the eeprom to 0? Also this use of logical AND (instead of bitwise AND) looks incorrect:

It sounds like using a USB ethernet adapter (e.g. https://github.com/vjmuzik/TeensyASIXEthernet) would be a lot simpler.

It doesn't. Write the entire contents of RAM2, perform a "warm" reboot and then check the entire contents. You will see it has not all been preserved. Then realize that your static variables can be allocated anywhere in DMAMEM (by the linker)...

Yes it is inaccurate because presssing the button doesn't trigger a reboot. It puts the Teensy into programming mode. If there is no USB cable connected, or the teensy loader program isn't currently running on the PC to automatically upload the...

See my reply in your other thread which I made before you created this duplicate...

This really isn't a good way of doing it (relying on memory contents staying constant between reboots) since it invokes undefined behaviour - static variables are meant to have a defined initial value (0 in your example sketch) or the compiler...

With Fig 2. save yourself some trouble and use pinMode to configure the Teensy input pin as INPUT_PULLUP, then you don't need the 470R.

So lengths of 32 are available? I assumed 28+4 was used because the run of pins was shortened (from ~40 or whatever the earlier boards had) and those were the only lengths available to make up the required size.

The DMA library for the T4.1 is specific to the IMXRT chip used, it is not a feature of the M7 core.

I don't recall posting a modified linker script for the devboard. Your linker script is missing .ARM.extab.text*.

The .arm.extab and .arm.exidx relocation issues aren't related - that looks like Kurt has them in the wrong memory section in the linker script.

It's because both the threading library and the sdram library use startup_middle_hook. I submitted a PR for this (to allow multiple hooks) and was told libraries shouldn't use the startup hooks at all, but there is no other feasible option to...

It's not clear what your question is. Do you mean they DO light up even though they're disconnected (which would be odd) or you want to know if they are possible to use if you connect something to them?

Did you post this same question using a new forum account? https://forum.pjrc.com/index.php?threads/having-problems-with-battery-monitoring-on-off-and-power-control.75520/

Bit 6 of the SNVS_HPSR register is meant to indicate the power button's current status, but I'm not sure how you expect to act on it when it turns the system off...

CORE_PIN4_CONFIG = 3; // ALT3

You'd have to dig down into Python's implementation to see where it's getting the information from, since it's obviously not from the USB descriptor. (Each Teensy should already have a unique serial number, no need to change anything else.)

I think this thread is getting invaded by AI bots.

The teensy pin number definitions are not the same as the crossbar pins. Not every physical pin is suitable for a crossbar output. Pin #4 is, but it's XBAR_INOUT08. You will have to set the pad mux for pin #4 to XBAR1 (ALT3), calling pinMode() is...

Nearly all of the quad timer input/output pins can be remapped using the crossbar. You just need to read the reference manual to find the crossbar assignments and write the code, because there's no library support for it.

Only since C23.

The workaround you've already found is probably the "best" solution. You could try passing "-fno-short-enums" to the compiler to force it to use 32-bits for every enum, but it's still not guaranteed (the C standard says the compiler is free to...

It's not so much of a "bootloader" as a "bootstrapper"; it handles the power-up sequence (rather than loading code) and the SoC won't power-on correctly without it. So it can't just be removed/replaced with a J-Link. (Also if it was, the product...

AFAIK this is already how it works; teensyloader only erases the flash area required for the sketch. LittleFS uses the highest portion of unused flash (below the area reserved for EEPROM emulation) so as long as the new sketch doesn't intrude on...

That is not what the "250ma max" is referring to. It means you can tap 250ma max from the 3.3V supply pin to power other devices besides the Teensy.

Like the previous comment said, you have while (!Serial); in your code (which even has a comment after it saying it will wait for the serial connection). It will wait forever at that line if there is no USB connection.

Which D+/D- lines, the ones from the existing micro usb port or the host port?

A run of 10,000... when there's less than 500 in stock?

Yes, bridge the center to the pad near the other USB to power it from the 5V supply, or to the other pad to power it from the PD chip (which requires external power).

If it's only 1 or 2 pins, I use a diode (pointed towards the 5V source) with the pin configured in pullup mode.

You only need to add pullup or pulldown resistors if you're going to have a "dumb" USB-C port (without any voltage negotiation). When using a controller like the IP6520 you just connect the lines directly to the IC.

What do you mean by "using Teensyduino"? It's the core library that provides all the board support code, not a tool... The only difference between hitting compile and choosing "export compiled binary" is the destination folder and which output...