manitou
Senior Member+
sticky post: I will update this first post as new test results become available.

i.MX RT1050 == Teensy 4 ? Paul says initial Teensy 4 beta units will be 1052s, production units will be 1060.
Before the T3.5/T3.6 beta units were available, I did some testing of mbed K64F. In that spirit, mbed supports an NXP MXRT1050-EVKB evaluation board. I purchased the EVK board November, 2017, but for many months mbed did not support the board. The board did run its preloaded accelerometer/LED program, so presumably NXP's SDK worked, even though there was no support for the on-line mbed compiler/API. A month or so ago, mbed support appeared but I could not get a program to upload to my EVK board. Then I noticed there was a revised EVKB board that fixed some silicon problems with the 2017 board. In November, 2018, I purchased the revised board from digikey, and mbed compile/uploads worked on the new board. The stencil on the MCU says MIMXRT1052 DVL6B.
The mbed evaluation boards include various ARM processors (M0, M3, M4, and now M7) from various manufacturers. The mbed API based on CMSIS/HAL/RTOS is a lowest common denominator to support the varying peripheral architectures, and as such is not optimized. The on-line compiler uses the ARM CC (v5) typically with -O3.
MCU benchmarks:
As best as I can tell from the board schematic, the clocks are derived from an 24 mhz crystal (BOM 30 ppm). I measured the crystal drift to be about -7 ppm. Just spinning in a loop, the board consumes 128 ma (measured via hacked USB cable). The board has lots of devices (LEDs, SDRAM, codec, ethernet PHY, microSD, accelerometer/magnetometer, ...) that consume power.
Here are some results from coremark-like test and Dhrystone 2.1
Other anecdotal low-level benchmark data for various MCUs is available at
https://github.com/manitou48/DUEZoo/blob/master/perf.txt
and also see Teensy 3* coremark plots
The M7 has hardware floating point (FPv5) supporting both single and double precision. Here are floating point performance (megaflops) for linear-algebra linpack benchmark and from Teensy propshield sketches the update time for float-intensive Kalman filter, and ARM cortex DSP benchmark.
Here are some data rates (megabits/sec) for memcpy(). Often ARM-optimized versions of memcpy() are provided by the compiler (see slower memcpy thread). Memory-to-memory DMA can often be faster.
Using an example (trng_random.c) from the SDK, I was able to exercise the M7's hardware random number generator (TRNG). I think the unit can generate 512 bits of entropy. Requesting 512 bits takes only 4 microseconds, but if you request 1024 bits, it takes 211 milliseconds. Typically you might request 512 bits of entropy and then use a PRNG to generate additional random bits. I collected 1 MB of random data (15 hours) and ran NIST STS-2.1 statistical tests. Randomness was OK, a few too my 0 p-values for my taste.
The board has a FXOS8700Q accelerometer/magnetometer (I2C 0x3E) which is the same sensor as on the propshield and on the mbed K64F. I cloned my K64F program that reads the accel/mag and temperature, changed program to use A4,A5 for I2C, 0x3E for I2C ID (from i2cscan), and replaced mbed lib with mbed-os. Program is tracking board motion.
Ported SDK dcp.c to mbed. M7 DCP is hardware to accelerate crypto functions. Tests passed
The latest SDK uses the DCP to accelerate AES and SHA in both mbedtls and wolfssl.
The Teensy 3* has a programmable hardware CRC unit, the M7 only has hardware CRC32 in its DCP. Here are some results for FastCRC on M7
For the M7 the "FastCRC" are table-driven CRCs, the "builtin" is bit-bang CRC (ref Teensy FastCRC thread).
From the SDK, I ported an EDMA memory-to-memory example (edma_memory_to_memory.c). The buffers are in non-cacheable memory, and I have to cycle USB power to get the sketch to run. DMA for 256 32-bit words took 72 us.
Using mbed api, verified M7 RTC is ticking and drift is -52 ppm (BOM 20 ppm). There is a 32khz crystal on schematic. Compiler flag is -DDEVICE_RTC=1 and CCM_ANALOG->MISC0 = 0x24008080 indicates RTC crystal present. mbed API is reading SRTC (LPSRTCMR, LPSRTCLR).
I did some unconnected SPI tests and data rates were quite SLOW. The mbed SPI API is using LPSPI1 to do byte transfers. I used a scope to watch SPI CLK. When SPI frequency of 1 MHz, scope showed 961 khz. By calculation with prescale (LPSPI1->CCR) i would expect 32727271.5/33 = 991735 Hz. Requesting 32 MHz, scope shows 16.4 MHz, calculation is 32727271.5/2 = 16363636 Hz (max SPI speed). The trouble is the interbyte delay is 11.7 us, so a 1024-byte transfer takes 12.7 ms (0.65 mbs) -- pretty slow. Presumably DMA could speed things up, and there are other SPI drivers available on the MCU.
I used the SDK examples to test LPSPI3 with FIFO. Data rates are getting much closer SPI clock speed. From the scope, the max SPI clock seems to be 16MHz (LPSPI is being clocked at 32.7mhz, max SPI CLK will be 32.7/2). The CMSIS SPI DMA example is faster than FIFO after adjusting the DBT value in the SDK DMA sketch. DMA buffers are in non-cacheable memory.
For comparison, SPI perfromance on other MCUs.
I couldn't get the Ethernet SDK example (enet) to work with mbed libs/startup, but I was able to compile and run the raw enet broadcast example using MCUXpresso IDE. Example broadcasted 20 packets and logged any broadcasts it heard. No ether pins on T4 but probably on T4.1, ref. The mbed schematic shows that about 12 MCU pins (ENET_*) are connected the Ethernet PHY. Mbed lib and SDK use lwIP and polling (mbed uses RTOS) to provide the TCP/UDP/IP services. Using the IDE I ran the SDK udpecho example confirming that lwIP is working along with ARP, ping/ICMP, and UDP. The latency for an 8-byte UDP echo was 104 us. I also ran the SDK lwIP TCP echo example and the iPerf example (TCP rate: 71 megabits/sec). With the Ethernet/PHY running, the board consumes an additional 100 ma.
For comparative performance see K66 ether testing or
https://github.com/manitou48/DUEZoo/blob/master/wizperf.txt
Using a scope I measured the ISR latency (attachInterrupt) using the PWM source and pin toggle in the ISR. The fastest PWM rate was 333 Khz (period 3 us). This is much slower than Teensy 3 as seen in the following table. ISR overhead for ARM is about 50 cycles, so we might expect the 600 MHz M7 to have a latency of 83 ns (12 MHz).
I ran a low-level ISR latency test with the SDK gpt_timer.c with a D7 GPIO toggle in the ISR. With scope on D7, and no __DSB in ISR, latency was 197 ns (3.8 MHz). With __DSB enabled, latency was 260 ns (1.9 MHz). Here is errata comment in ISR:
To test power consumption at different frequencies, I ran the SDK power_mode_switch app, described here, with meter and hacked USB cable. At 600 MHz the app/board consumed 158.9 ma, @528mhz 150.3 ma, @132mhz 116.9 ma, and @24mhz 93.9 ma. The specs say the MCU should consume 0.11ma/MHz.
With a hacked USB cable i measured blink power at 110 ma to 138 ma, hello_word 170 ma (138 ma in initial debug pause), coremark 184 ma, wolfssl benchmark 246 ma, and mbedtls benchmark 200 to 281 ma, mostly around 265 ma.
The eval board has microSD, and SDK uses fatfs with 4-bit SDIO. SDK example read directory and write and read file worked. Here are some data rates for reading various buffer sizes (bytes).
For reference, some older T3.6 SD tests.
Some settings of MCU control registers:
Observations:
TODO:
References:

i.MX RT1050 == Teensy 4 ? Paul says initial Teensy 4 beta units will be 1052s, production units will be 1060.
Before the T3.5/T3.6 beta units were available, I did some testing of mbed K64F. In that spirit, mbed supports an NXP MXRT1050-EVKB evaluation board. I purchased the EVK board November, 2017, but for many months mbed did not support the board. The board did run its preloaded accelerometer/LED program, so presumably NXP's SDK worked, even though there was no support for the on-line mbed compiler/API. A month or so ago, mbed support appeared but I could not get a program to upload to my EVK board. Then I noticed there was a revised EVKB board that fixed some silicon problems with the 2017 board. In November, 2018, I purchased the revised board from digikey, and mbed compile/uploads worked on the new board. The stencil on the MCU says MIMXRT1052 DVL6B.
The mbed evaluation boards include various ARM processors (M0, M3, M4, and now M7) from various manufacturers. The mbed API based on CMSIS/HAL/RTOS is a lowest common denominator to support the varying peripheral architectures, and as such is not optimized. The on-line compiler uses the ARM CC (v5) typically with -O3.
MCU benchmarks:
As best as I can tell from the board schematic, the clocks are derived from an 24 mhz crystal (BOM 30 ppm). I measured the crystal drift to be about -7 ppm. Just spinning in a loop, the board consumes 128 ma (measured via hacked USB cable). The board has lots of devices (LEDs, SDRAM, codec, ethernet PHY, microSD, accelerometer/magnetometer, ...) that consume power.
Here are some results from coremark-like test and Dhrystone 2.1
Code:
coremarkish Dhrystone 2.1
iterations/sec DMIPS
M7@600mhz 2438 2033 ARM CC -O3
@528mhz 2146
@132mhz 536
@24mhz 97
T3.6@256mhz 659 1120 Fastest+pure+LTO
T3.6@180mhz 434 287 Faster
T3.6@120mhz 289 191 Faster
T3.5@120mhz 261 138 Faster
T3.2@120mhz 254 106 Faster
https://github.com/manitou48/DUEZoo/blob/master/perf.txt
and also see Teensy 3* coremark plots
The M7 has hardware floating point (FPv5) supporting both single and double precision. Here are floating point performance (megaflops) for linear-algebra linpack benchmark and from Teensy propshield sketches the update time for float-intensive Kalman filter, and ARM cortex DSP benchmark.
Code:
Linpack 100x100 mflops
double float
M7@600mhz 66.97 125.5 ARM CC -O3
T3.6@180mhz 2.13 28.4 Faster
T3.6@256mhz 2.85 41.1 Fastest
T3.2@120mhz 0.65 1.0 Faster no FPU
Kalman filter update time
microseconds
M7@600mhz 99
T3.6@256mhz 176
T3.6@180mhz 248
T3.5@120mhz 351
T3.2@120mhz 3396
mega2560@16mhz 30272
DSP FFT benchmark 1024 radix4 REVERSEBITS 0 (microseconds)
q15 q31 f32
M7@600mhz 74.5 126.9 95.6 ARM GCC -O3 arm_math.h v1.5.1
T3.6@180mhz 463.1 1215.2 703.7 Faster v1.1.0
T3.6@180mhz 414.7 1010.7 598.2 Faster v1.5.3
T3.5@120mhz 784.7 1947.9 1079.8 Faster v1.1.0
T3.5@120mhz 658.5 1577.9 919.5 Faster v1.5.3
K64F@120mhz 635.7 1273.8 827.2 ARM GCC -O3 arm_math.h v1.4.5
T3.2@120mhz 869.8 2498.5 18182.5 Faster v1.1.0
adaM4F@120mhz 701.3 1756.1 781.0 Faster v1.1.0 SAMD51
STM32L4@80mhz 917.3 1953.8 1150.4 Faster v1.4.5
Here are some data rates (megabits/sec) for memcpy(). Often ARM-optimized versions of memcpy() are provided by the compiler (see slower memcpy thread). Memory-to-memory DMA can often be faster.
Code:
memcpy() speed (16-byte aligned, 4096 bytes)
megabits/sec
M7@600mhz 2731
T3.6@180mhz 1214
T3.5@120mhz 800
T3.2@120mhz 780
LC@48mhz 42
Using an example (trng_random.c) from the SDK, I was able to exercise the M7's hardware random number generator (TRNG). I think the unit can generate 512 bits of entropy. Requesting 512 bits takes only 4 microseconds, but if you request 1024 bits, it takes 211 milliseconds. Typically you might request 512 bits of entropy and then use a PRNG to generate additional random bits. I collected 1 MB of random data (15 hours) and ran NIST STS-2.1 statistical tests. Randomness was OK, a few too my 0 p-values for my taste.
The board has a FXOS8700Q accelerometer/magnetometer (I2C 0x3E) which is the same sensor as on the propshield and on the mbed K64F. I cloned my K64F program that reads the accel/mag and temperature, changed program to use A4,A5 for I2C, 0x3E for I2C ID (from i2cscan), and replaced mbed lib with mbed-os. Program is tracking board motion.
Code:
rate 50 hz 1983284 us
22 C
ACC: X=000192d Y=-00137d Z=004273d MAG: X=-00319d Y=-00100d Z=000593d
ACC: X=000180d Y=-00137d Z=004253d MAG: X=-00317d Y=-00099d Z=000599d
ACC: X=000191d Y=-00138d Z=004258d MAG: X=-00308d Y=-00099d Z=000599d
ACC: X=0.0439f Y=-0.0356f Z=1.0430f MAG: X=-31.7f Y=-9.3f Z=60.0f
ACC: X=0.0449f Y=-0.0337f Z=1.0415f MAG: X=-31.4f Y=-9.9f Z=59.1f
ACC: X=0.0447f Y=-0.0356f Z=1.0435f MAG: X=-31.8f Y=-9.9f Z=59.1f
Ported SDK dcp.c to mbed. M7 DCP is hardware to accelerate crypto functions. Tests passed
Code:
AES ECB Test pass
AES CBC Test pass
SHA-1 Test pass
SHA-256 Test pass
CRC-32 Test pass
sha256 16384 bytes 270 us 485.451852 mbs
crc32 16384 bytes 183 us 716.240437 mbs
aescbc 64 bytes 26 us 19.692308 mbs
Code:
mbedtls benchmark GCC v7.3 -O3
w/ DCP
SHA-256 19197 KB/s 59125.32 KB/s
AES-CBC-128 15567 KB/s 57921.99 KB/s
The Teensy 3* has a programmable hardware CRC unit, the M7 only has hardware CRC32 in its DCP. Here are some results for FastCRC on M7
Code:
CRC Benchmark 16384 bytes
Maxim (iButton) FastCRC: Value:0xf6, Time: 247 us 530.656 mbs
Maxim (iButton) builtin: Value:0xf6, Time: 960 us 136.533 mbs
MODBUS FastCRC: Value:0x7029, Time: 145 us 903.945 mbs
MODBUS builtin: Value:0x7029, Time: 959 us 136.676 mbs
XMODEM FastCRC: Value:0x98d9, Time: 143 us 916.587 mbs
XMODEM builtin: Value:0x98d9, Time: 1506 us 87.033 mbs
MCRF4XX FastCRC: Value:0x4a29, Time: 149 us 879.678 mbs
MCRF4XX builtin: Value:0x4a29, Time: 276 us 474.899 mbs
KERMIT FastCRC: Value:0xb259, Time: 141 us 929.589 mbs
Ethernet FastCRC: Value:0x1271457f, Time: 166 us 789.590 mbs
Ethernet bitbang: Value:0x1271457f, Time: 2056 us 63.751 mbs
From the SDK, I ported an EDMA memory-to-memory example (edma_memory_to_memory.c). The buffers are in non-cacheable memory, and I have to cycle USB power to get the sketch to run. DMA for 256 32-bit words took 72 us.
Using mbed api, verified M7 RTC is ticking and drift is -52 ppm (BOM 20 ppm). There is a 32khz crystal on schematic. Compiler flag is -DDEVICE_RTC=1 and CCM_ANALOG->MISC0 = 0x24008080 indicates RTC crystal present. mbed API is reading SRTC (LPSRTCMR, LPSRTCLR).
Code:
crystal drift (ppm)
EVK EVKB specs 1060
24MHz -14 -6 30 -8
32KHz -54 -52 20 10
I did some unconnected SPI tests and data rates were quite SLOW. The mbed SPI API is using LPSPI1 to do byte transfers. I used a scope to watch SPI CLK. When SPI frequency of 1 MHz, scope showed 961 khz. By calculation with prescale (LPSPI1->CCR) i would expect 32727271.5/33 = 991735 Hz. Requesting 32 MHz, scope shows 16.4 MHz, calculation is 32727271.5/2 = 16363636 Hz (max SPI speed). The trouble is the interbyte delay is 11.7 us, so a 1024-byte transfer takes 12.7 ms (0.65 mbs) -- pretty slow. Presumably DMA could speed things up, and there are other SPI drivers available on the MCU.
I used the SDK examples to test LPSPI3 with FIFO. Data rates are getting much closer SPI clock speed. From the scope, the max SPI clock seems to be 16MHz (LPSPI is being clocked at 32.7mhz, max SPI CLK will be 32.7/2). The CMSIS SPI DMA example is faster than FIFO after adjusting the DBT value in the SDK DMA sketch. DMA buffers are in non-cacheable memory.
Code:
LPSPI3 data rate (megabits/s) 1024 bytes
SPI CLK scope FIFO DMA
4MHz 3.6mhz 2.7 mbs 3.1 mbs
8MHz 6.5mhz 4.5 mbs 6.1
10MHz 8.2mhz 5.5 mbs 7.5 mbs
16MHz 10.8mhz 6.8 mbs 9.4
20MHz 16.1mhz 9.4 mbs 13.1 mbs
32MHz 26.4mhz 17.3 mbs
60MHZ 53.2mhz 27.3 mbs distorted LPSPI CLK 105.6
I couldn't get the Ethernet SDK example (enet) to work with mbed libs/startup, but I was able to compile and run the raw enet broadcast example using MCUXpresso IDE. Example broadcasted 20 packets and logged any broadcasts it heard. No ether pins on T4 but probably on T4.1, ref. The mbed schematic shows that about 12 MCU pins (ENET_*) are connected the Ethernet PHY. Mbed lib and SDK use lwIP and polling (mbed uses RTOS) to provide the TCP/UDP/IP services. Using the IDE I ran the SDK udpecho example confirming that lwIP is working along with ARP, ping/ICMP, and UDP. The latency for an 8-byte UDP echo was 104 us. I also ran the SDK lwIP TCP echo example and the iPerf example (TCP rate: 71 megabits/sec). With the Ethernet/PHY running, the board consumes an additional 100 ma.
Code:
NXP1062 (SDK lwIP)
UDP latency(us) 104 8-byte UDP RTT
UDP send (mbs) 97 20 1000-byte packets
UDP recv (mbs) 95
UDP send 1000x8 137453 pps
TCP send (mbs) 87 100 1000-byte
TCP recv (mbs) 71
PING RTT(us) 108
https://github.com/manitou48/DUEZoo/blob/master/wizperf.txt
Using a scope I measured the ISR latency (attachInterrupt) using the PWM source and pin toggle in the ISR. The fastest PWM rate was 333 Khz (period 3 us). This is much slower than Teensy 3 as seen in the following table. ISR overhead for ARM is about 50 cycles, so we might expect the 600 MHz M7 to have a latency of 83 ns (12 MHz).
Code:
ISR latency (attachInterrupt) PWM frequency and period
T3.2@120mhz 1.2 MHz 835 ns FASTISR 2.6 MHz 384 ns
T3.6@180mhz 1.7 582 3.4 300
M7@600mhz 0.33 3000
Code:
/* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F, Cortex-M7, Cortex-M7F Store immediate overlapping
exception return operation might vector to incorrect interrupt */
#if defined __CORTEX_M && (__CORTEX_M == 4U || __CORTEX_M == 7U)
__DSB();
#endif
To test power consumption at different frequencies, I ran the SDK power_mode_switch app, described here, with meter and hacked USB cable. At 600 MHz the app/board consumed 158.9 ma, @528mhz 150.3 ma, @132mhz 116.9 ma, and @24mhz 93.9 ma. The specs say the MCU should consume 0.11ma/MHz.
Code:
Various clocks with MCU @600MHz
CPU: 600000000 Hz
AHB: 600000000 Hz
SEMC: 75000000 Hz
IPG: 150000000 Hz
OSC: 24000000 Hz
RTC: 32768 Hz
ARMPLL: 1200000000 Hz
with MCU @24MHz
CPU: 24000000 Hz
AHB: 24000000 Hz
SEMC: 24000000 Hz
IPG: 12000000 Hz
OSC: 24000000 Hz
RTC: 32768 Hz
ARMPLL: 24000000 Hz
The eval board has microSD, and SDK uses fatfs with 4-bit SDIO. SDK example read directory and write and read file worked. Here are some data rates for reading various buffer sizes (bytes).
Code:
buffer time(us) rate(mbs)
512 308 13.3
1024 333 24.6
2048 380 43.1
4096 485 67.6
Some settings of MCU control registers:
Code:
ArmPllClk 1200000000 AhbClk 600000000 RtcClk 32768 Usb1PllPfd0Clk 261818172 IpgClk 150000000 SemClk 163862064
Usb1PllClk 480000000 OscClk 24000000
XTALOSC24M->LOWPWR_CTRL 0x74f01
XTALOSC24M->OSC_CONFIG0 0x93033a73
XTALOSC24M->OSC_CONFIG1 0x2db002dc
XTALOSC24M->OSC_CONFIG2 0x800102d7
SCB->ICIALLU 0x0
SCB->CCR 0x70200
SCB->CSSELR 0x0
SCB->CCSIDR 0xf01fe019
SCB->DCISW 0x0
SCB->CCR 0x70200
CCM->CBCDR 0x18340
SNVS->LPCR 0x20
SNVS->LPSRTCMR 0x0
SNVS->LPSRTCLR 0x0
CCM_ANALOG->PLL_ARM 0x80002064
CCM_ANALOG->PFD_480 0xf1a2321
CCM_ANALOG->PFD_528 0x405d4040
CCM_ANALOG->MISC0 0x24008080
SysTick->CTRL 0x7
SysTick->LOAD 0x927bf
CCM->CCGR0 0xffffffff
CCM->CMEOR 0x7ffffff
Observations:
- pins 10-13 not connected to "arduino header"
- printf sometimes prints garbage with mbed lib, works better with mbed-os lib (mbed os 5?)
- PWM gets IO error (not supported) with mbed lib, but with mbed-os lib , PWM works 50hz. mbed PWM is using eFlexPWM (ch 28, 150 MHz clock) and the API limits you to max PWM frequency of 1 MHz. With scope, I hacked the PWM registers, testing it at 10 Mhz and 25 MHz. At 30 and 38 MHz signal is sawtooth with reduced Vpp (1.36v).
- with mbed lib, some mbedtls functions hang. mbed-os has mbedtls builtin, and tls functions seem to work
- GPS PPS works, crystal drift -7 ppm
- measured internal GPIO pullup at 47Kohm
- builtin LED is pulled HIGH, so write LOW to turn on
- I2C on A4,A5 ok @100khz, 400khz, and 1MHz I2C scan with scope (96.1khz, 357khz, 757khz), two devices found
- ran SDK app examples (ecompass.bin bubble.bin) to exercise accelerometer/magnetometer
- exercised M7 timers with SDK examples (pit, qtmr, gpt, SysTick)
- There are 4 6-bit DACs associated with analog comparator (ACMP, Ch 13). The DAC is used as a reference voltage for the CMP, but voltage is brought out on 4 pins (GPIO_AD_B1_12 - 15). On the eval board those pins are used for the WM8960 codec (SAI), so I can't test DAC voltages (maybe use XBAR?). SDK has an ACMP example (cmp_polling.c) that uses the DAC with the CMP. AD_B1_14,15 are Teensy 4 pins 26,27 (Paul's pin list).
- mbed-os lib sits atop a thread base and the default stack size is 4KB, so one may encounter stack overflows.
- Pin toggle (in mbed-speak mypin = !mypin) takes about 70 cycles, measured with SysTick->VAL. Using the GPIO hardware toggle with GPIO1->DR_TOGGLE = 1<<9; takes only a few cycles. There is a synchronization delay between the MCU and GPIO as exhibited by the following 8 toggles of pin 7 (169 cycles).
- PIT and GPT timers share the same base clock PERCLK. One can configure PERCLK for OSCCLK (24mhz) or IPGCLK (150mhz), ref Fig 18-2. If your program uses both PIT and GPT, you need to insure both are configured with the same PERCLK clock.
- ran SDK sai demo which exercised codec. I could hear sine wave through ear phones. Nothing from record/playback test. Demo does FFT on sine wave to calculate frequency.
- hooked up 272x480 RK043FN02H-CT LCD ribbon cables(reference) and ran a few SDK examples (424 ma).
- ran SDK and mbed ADC tests, ADC supports calibration, averaging, and various speeds and resolutions
- GNU GCC options of interest: -fomit-frame-pointer -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=softfp
- Update to SDK 2.5.0, ran SDK wdog01 example, WDOG ok. also ran SDK temperaturemonitor example, ok
- Using MCUXpresso to erase flash of 2017 EVK board, I was able to upload SDK examples. reference
- 2019 some 1060 testing MIMXRT1062 DVL6A
- Cortex M7 is superscalar
TODO:
- test EEPROM?
- ARM CC compiler bugs:
A couple of mbed sketches that work on other mbed evaluation boards, hang on the M7. If I export the program for building with GNU GCC 7.3.1, and build and load the GNU version on the M7, the program works. Also works if I use mbed-os lib rather than mbed lib.
References:
- mbed EVKB/M7 evaluation board
- eval board user guide
- evk vs evkb
- M7 SDK EVKB-IMXRT1050 MIMXRT1052
- EVKB review
- i.MXRT L1 cache
- EVKB lower power tests MHz: 600 528 132 24
- NXP 1050 vs 1060
- Teensy 4 speculation thread
- Teensy 4 pin assignment thread
- Teensy 4 core symbols
- 12/26/18 Teensy 4.0 First Beta Test 1052, 4/22/19 1062
Code:
SDK examples
boards/evkbimxrt1050/driver_examples
adc/ cmp/ elcdif/ flexcan/ gpio/ lpspi/ pxp/ semc/ wdog/
adc_etc/ csi/ enc/ flexio/ gpt/ lpuart/ qtmr/ snvs/
bee/ dcp/ enet/ flexram/ kpp/ pit/ rtwdog/ src/
cache/ edma/ ewm/ flexspi/ lpi2c/ pwm/ sai/ trng/
boards/evkbimxrt1050/demo_apps
bubble/ hello_world/ led_blinky/ sai/ shell/
ecompass/ hello_world_virtual_com/ power_mode_switch/ sd_jpeg/
Last edited: