Search results

I don't think attachInterrupt ISR requires asm volatile ("dsb");. Teensy 4 core interrupt.c spins testing the ISR clear flag. I think the missing brackets { } (post #2) is the problem. Also, the declaration of timeSinceLastChange in encoder_shaft_moved() won't be seen outside that function...

Weird. Test it with a few non-UART pins, e.g. change the first argument of attachInterrupt(pin, ....) and attach GPX TX pin do you have another Teensy that you can try?

Here is a simple sketch to count rising pulses on pin 0. Connect GPS TX to Teensy pin 0. volatile uint32_t ticks; void ding() { ticks++; } void setup() { Serial.begin(9600); while (!Serial); attachInterrupt(0, ding, RISING); } void loop() { static uint32_t prev = 0; delay(1000)...

do you have a scope or analyzer that you can attach to GPS TX pin? Is there a GPS LED that blinks to confirm that GPS has sync'd with the satellites?

your photos suggest you are using 5v from Teensy to power ublox. Teensy 4.1 is NOT 5v tolerant. you may have damaged the Rx pin on the Teensy. You should power ublox from 3v3 pin I have NEO-M8U and NEO-M9N, and both work fine with Teensy 4.1. GPS's are powered from Teensy 3.3v

You have misplaced "{" in loop() should be void loop() { for (int i = 0; i <= 191; i = i + 1) { analogWrite(A21, sine_dataA[i]); //6.25 khz approx analogWrite(A22, sine_dataB[i]); // 13.66 Khz approx } } scope shows DAC0 3.52 kHz and DAC1 7.04 kHz...

Even with pinMode() commented out, i get sinewave (5.8khz on DAC0/A21 and DAC1/A22 is straight line at 1.6 v. If i comment out DAC0 write, scope shows DAC1 sinewave at 16.7 khz. same behaviour on T3.6, but faster sinewave :confused:

You might examine the NXP SDK source and examples .... Capture_Mode=0,MSTR=0,EEOF=0,VAL=0,FORCE=0,OPS=0,OEN=0 */ ./boards/evkmimxrt1060/demo_apps/mc_pmsm/mcdrv_evkmimxrt1060.c (TMR_SCTRL_EEOF(config->enableExternalForce) | TMR_SCTRL_MSTR(config->enableMasterMode))...

Yep, "known by some" -- During Teensy 4 beta tests (2019) I encountered the problem and found NXP forum discussions that pointed to the errata, see https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=199536&viewfull=1#post199536

Does your MCP4725 DAC have pullup resistors on SCL and SDA? I have an Adafruit DAC that works with T3* and T4*. The breakout has 10K pullups. (note: your if (WriteEEPROM) ... logic is reversed but probably not related to your problem)

Re: GPS PPS frequency with Rubidium 10mhz to pin 14 and a GPS PPS to pin 15, what response do you see? Do you have a GPS with external antenna and good view of sky?

You can paste in sketch with code tags (click on #) // Code to test Teensy 4.0 GPT2 Counter with External Clock void setup() { // Setup USB serial port so we can print the timer value Serial.begin(115200); // Configure GPT2 external clock on pin 14 (GPIO_AD_B1_02) pinMode(14...

another pendulum frequency thread: https://forum.pjrc.com/threads/65156-Pendulum-clock-accuracy-GPSDO-10Mhz-1Hz-pulse

here is small sketch to test GPT with external clock (pin 14) and and capture with pin 15 // GPT2 external clock (GPS 8 mhz) into pin 14, PPS captured to pin 15 //https://forum.pjrc.com/threads/54265-Teensy-4-testing-mbed-NXP-MXRT1050-EVKB-(600-Mhz-M7)?p=193217&viewfull=1#post193217 // CLKSRC...

Dang, though the question is mute, maybe using static volatile for a and b will avoid the compiler optimizations; static uint64_t cnt = 0; static volatile uint64_t a, b; void check(uint64_t x, uint64_t y) { if (x != y) { Serial.printf("ERROR %llx %llx cnt = %lld\n", x, y, cnt); } }...

No Teensy 4 compare failures with this sketch with arduino 1.8.19 and teensyduino 1.58 static uint64_t cnt = 0; void check(uint64_t x, uint64_t y) { if (x != y) { Serial.printf("ERROR %llx %llx cnt = %lld\n", x, y, cnt); } } void setup() { while (!Serial); uint64_t x =...

Please try and develop a small test code that demonstrates the problem.

Please provide a runnable sketch that demonstrates the problem. What IDE and OS are you using? what optimizations (compiler settings) are you using?

ping times from TN rtt min/avg/max/mdev = 39.860/42.676/52.315/2.578 ms

If signal generator was driving pin 22 at more than 3.3v, then maybe you fried pin 22 and other pins. You should be seeing only 3.3v on PWM output pins. :confused: you could try some pin tests, digitalRead() digitalWrite(), and measure voltage with meter on digitalWrite() do you have soldered...

In the 2nd column, it says when using T4 pin 22 as input, then you can't use pin 23 for analogWrite(). So choose another PWM pin, e.g. pin 12, for the PWM test example. Teensy 4 pins are NOT 5 volt tolerant, so you shouldn't drive pins over 3.3v.

actually, T4 pwm test should use pin 12 not pin 23 (see https://www.pjrc.com/teensy/td_libs_FreqMeasure.html ) ? if AC add blocking capacitor?

Do you have common ground between teensy and generator. Try this test with PWM (jumper pin 12 to pin 22) #include <FreqMeasure.h> void setup() { Serial.begin(57600); analogWriteFrequency(12,600); //jumper pin 12 to pin 22 analogWrite(12,128); FreqMeasure.begin(); } double sum=0; int...

Ethernt MAC address Each Teensy 3* and Teensy 4* comes with a unique number set in the OTP efuses. The teensy core uses those bytes to define the Ethernet MAC and a USB serial number. Teensy 4 uint32_t m1 = HW_OCOTP_MAC1; // T4 MAC uint32_t m2 = HW_OCOTP_MAC0...

I tried the Teensy 4.1 port with my T4.1 and home ethernet git clone --recursive https://github.com/mbed-ce/mbed-os-example-sockets.git in build/ cmake .. -GNinja -DCMAKE_BUILD_TYPE=Develop -DMBED_TARGET=TEENSY_41 ninja teensy_loader_cli...

So do TLS sockets work on the 1060 EVK and/or 1050 EVK? My earlier Ethernet testing on those EVK boards was using the lwIP library, and I only did standalone testing of the mbedTLS lib. CA certificates have an expiration date. Is that causing TLS parse error? I don't know if self-signed...

Pin tests on T4.0 with mbed CE: digital tests (D0 - D23): inpin[i].mode(PullUp) and then jumpering each pin to GND and confirming pin valuue 0 -- all ok PWM tests: only pin D22 worked with PWM (default 50 hz). all other flexPWM pins (D0-D9, D23) crashed the T4.0 Analog in (ADC): test with...

Re: Cortex M7 tests Over the years I've been using the mbed online compiler (RIP) for testing. Recently I've been using mbed cli and Keil Studio. I've also used NXP MCUxpresso with the SDK for the 1170 (M7@996MHz). It looks like mbed CE supports the 1170 and NUCLEO F767ZI (M7@216MHz). I...

you may need to add 2K pullup resistors on SCL/SDA to overcome the 10K pullups on each of the sensor PCBs -- I am NOT an EE :D

Yep, your recipe worked for me Hello world from Mbed CE! Hello world from Mbed CE! Hello World from inside usb_device_ehci.c, controllerId = 2 Hello world from Mbed CE! no USB tty device [346233.024806] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command [346233.232462] usb...

My limited experience with RPI pico cmake, you could set both uart and usb to "true" in the json file, but that doesn't appear to work on mbed ce. My morse code output works on pin 13, but my "decoder" measuring pulse widths on another teensy isn't that robust . maybe use sprintf() to build a...

600 mhz with -O3 also working ;) coremark 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 1222 Total time (secs): 12.220000 Iterations/Sec : 2454.991817 Iterations : 30000 Compiler version : 6.3.1 20170620 Compiler flags : Memory location ...

Thanks, target_compile_options worked, -O3 working now ;)

yes, i saw that and tried that. I've even tried hacking the git sources and changing all -Os to -O3 anywhere (e.g., .cmake and .json and ...), and trying things in other forums ... no luck. I have done optimization setting in RPI pico cmake builds. I can't believe it's that hard. Thanks for...

Great news on 600 MHz. Paul's core has set_arm_clock(frequency) in clockspeed.c that allows you to configure clock speed from IDE or under program control. There are threads on this forum discussing heat sinks for overclocking. Regarding -O3 optimization: I've been reading and learning more...

> target_compile_options(HelloWorld PRIVATE -O3) I added this to CMakeLists.txt and recreated build/ but there was no change in performance from -Os. Any other suggestions?? thanks for tip on "mbed-baremetal" another SystemCoreClock curiosity: if I count cycles around wait_us(1000000)...

I would like to run with -O3. It appears that it is running at -Os. -Os appears in CMakeCache.txt CMAKE_ASM_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG also CMAKE_BUILD_TYPE:STRING=Develop I haven't figured...

In cmake how do I change compiler optimization for builds? Would be nice to increase SystemCoreClock from 528 MHz to 600 MHz.

Some hardware registers for T4.0 under mbed os 6. SystemCoreClock 528000000 11:38:27 Feb 8 2023 ok ArmPllClk 1056000000 AhbClk 528000000 RtcClk 32768 Usb1PllPfd0Clk 664615368 IpgClk 132000000 SemClk 176000000 Usb1PllClk 480000000 OscClk 24000000 XTALOSC24M->LOWPWR_CTRL 0x74f01...

Update, I used the following for mbed_app.json { "target_overrides": { "*": { "platform.stdio-baud-rate": 115200, "platform.stdio-buffered-serial": 1, "target.console-usb": false, "target.console-uart": true } } }...

OK I updated mbed-ce-hello-world -- thanks Paul for the detailed git incantations. I built, loaded, and ran main.cpp. No mbed death flashing. ttyUSB0 showed up [1435205.021011] usb 1-3.4: new full-speed USB device number 37 using xhci_hcd [1435205.129127] usb 1-3.4: New USB device found...

D12 (GPIO_B0_01) is on QTIMER 1 CHN 1 and does PWM with Teensy core, also see T4.0 pin map i'll do some UART testing shortly ...

updated mbed_app.json, removed build directory and re-created with cmake etc. my build summary has no mbed_usb.a [234/234] Linking CXX executable HelloWorld.elf -- built: /home/dunigan/ssd/mbed-ce-hello-world/build/HelloWorld.bin -- built...

I deleted lines from startup_MIMXRT1052.S and added blink logic to main.cpp #include "mbed.h" int main() { DigitalOut myled(LED1); int p = 1; while(true) { printf("Hello world from Mbed CE!\n"); myled = p; p = 1-p; ThisThread::sleep_for(1s)...

So have you actually run your HelloWorld project on a T4.0? maybe add the HellowWorld.hex to your git repository. I believe T4.0's are in stock at pjrc.com

Paul, have you examined mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/TARGET_TEENSY_4X/bootdata.c Above my pay grade ... Seems like the mbed T4.0 code is derived from the 1050. I did some mbed testing on 1050 EVKB as part of pre-testing (2018) for the Teensy 4...

Tried but failed. :confused: on Ubuntu 18.04.06 with stock arm-none-eabi-g++ version 6.3.1, cmake looked OK, and ninja built HelloWorld.hex ninja [2/2] Linking CXX executable HelloWorld.elf -- built: /ssd/mbed-ce-hello-world/build/HelloWorld.bin -- built...

An active antenna (with long cable) on the windowsill is probably best, adding distance between the GPS antenna and RF noise of the MCU and other devices.

Does your GPS have an external antenna with a good view of the sky? Satellite lock may be intermittent and PPS erratic without external antenna. Some discussion of GPS PPS and Teensy crystal drift and frequency changes due to temperature (HVAC activity), see...

I have a quad timer PWM test sketch qtmrtst.ino from the Teensy 4 beta testing days. Particular tests can be enabled to test interrupts for timer, underflow, and overflow, as well as test functions for Teensy 4 PWM and for NXP SDK's PWM. I've added a test function for fixed frequency. Here...