Teensy 4? testing mbed NXP MXRT1050-EVKB (600 Mhz M7)

FWIW, Teensy will use similar copy code at startup. Supposedly NXP's boot ROM can do the copy to ram, but I can't figure out how to make it work. Looks like the mbed folks couldn't get it either. Not too surprising, since NXP's documentation is light on details and riddled with errors.

Paul, will there be an option in T4 to NOT copy ALL code to ram? I would like to keep most ram for data buffer and only copy FASTRUN code to RAM (e.g. FFT).
 
My emulator has more than 32kb code and const tables that need to be accessed fast. But there are parts where it is no problem when they are executed very slow (kind of "idle" loop) so... is it somehow user-configurable?



Likewise..all the boot code and setup() does not need to be in the ram.
 
If the 1062 is used … there are two parts to RAM … the no wait mapped on the fast track, and the other 512KB

Also reading through the FLEXCAN section - it was noted that RAM associated with CAN when not used … (RM1060::pg#2702: "RAM not used by reception or transmission structures can be used as general purpose RAM space"). So that must have a *ptrAddr, not sure I saw where - or the net size of them - where it buffers (Pg#2700: "The message buffers are stored in an embedded RAM dedicated to the FlexCAN module." ). Not sure if that applies to any other devices - perhaps only FlexCAN?

This? in RM1060::pg#38: 'Table 2-3. AIPS-2 memory map' shows 16 KB blocks {maybe rounded up?} and may not be contiguous? on 8 LPUARTS and 3 FLEXCAN::
Code:
Start Addr  End Addr    Size   NIC Port
401D_8000    401D_BFFF   16KB   FlexCAN3
401D_4000    401D_7FFF   16KB   FlexCAN2
401D_0000    401D_3FFF   16KB   FlexCAN1
...
401A_0000    401A_3FFF   16KB   LPUART8
...
 
Last edited:
Yes, there will be a way to cause a function to go into slow flash, pretty much the opposite of FASTRUN we have now. It will have a familiar name... ;)

I would like to keep most ram for data buffer and only copy FASTRUN code to RAM (e.g. FFT).

At least for the initial version, the default will be functions go into ITCM. This may change at a future date. But I'm generally inclined to have defaults and ways to override them.
 
flexcan has it’s own memory mapped address used only for itself, not sure if you can use it without CAN..
 
PROGMEM ?
Override for SLOW would actually increase the odds of that rare code sitting in the 32KB CACHE if there isn't much of it? Assuming 'FAST_RAM' is as good as cached?

@tonton81 - does post #54 lead to any surety? { those notes and Pg#'s are from 1060's RefMan }
 
While poking around NXP I came across this document: How to Enable Boot from Octal SPI Flash and SD Card. Makes interesting reading and not sure you all have seen it. I just scanned through a few minutes ago.

Just as a follow up to my previous post SDRAM, the times I posted there were for running the whole read/write function. Decided compare the cycles on reading and writing 4k blocks:
Code:
              Write        Read
 32-bit      77,946      140,766  cycle count
 16-bit     116,951       76,044 
  8-bit      86,126       71,904
*Data Length 4096
 
Last edited:
Just tried two of the Flexcan examples. Loop back worked with out issue. However, during testing I somehow managed to get my board stuck so I couldn't upload any additional programs. The debugger failed to run with error message invalid chip id. The solution that I found was to erase the hyper flash which worked. So if you run into that problem while testing with this board follow the troubleshooting section of this document: View attachment RT1050_BriefOverview_v201.pdf

The next test was to connect the board to a Teensy 3.6 and see if I could establish communication between the too. To that you need to solder a 3-pin header to J11. Once I did that I was able to run the sdk example and able to see the packet transmitted. Unfortunately the example is rather limited and the fsl_flexcan library that it uses is not exactly friendly. So it looks like tonton81 maybe busy with writing a new library for CAN 2.0 for the 1050. I used his lib on the T3.6 to receive the data from the 1050 board.

Going to see if I can come up with a better example to test with and report back.
 
I can confirm we definitely will be using the RT1062 chip for Teensy 4.0. After several minor setbacks, the purchase is finally in with NXP and the official lead time for the parts is starting today!

Beta test will begin next month with the RT1052s, since we have a couple hundred on hand.

Regarding this chip's many boot options (msg #60), we're going to end up locking down the fuse config to QSPI boot only. This is what I've been mostly working on the last couple months... how we're going to make this thing fit with the features familiar Teensy features (like holding the button at startup to recover from bad code) and prevent bricking when things go wrong. Unfortunately this chip has a tremendous number of ways to become bricked if we don't lock down the boot config fuses. We just can't make it the flexible booting playground that NXP's huge (but easily brickable) eval board is.

However, there may still be some small hope for experimentation with booting from SD cards. That tiny glimmer of hope is hidden on page 2972 of the RT1050 ref manual, even though the official documentation for those SRC registers on pages 2981-2982 says only "This register is used by the ROM code and should not be used by application software". Maybe someday someone will disassemble and fully reverse engineer the boot rom and we'll learn more about what other hidden features are lurking in SRC_GPR3 to SRC_GPR10.

I know everyone here wants to talk about performance. I do care deeply about achieving good performance and facilitating overclocking & experimentation. I also care very much about balancing access to powerful capability with Arduino-style simplicity. But right now, before we start beta testing, my focus is on a ton of other issues including fairly non-technical manufacturing and purchasing stuff, and a pretty strong technical focus on preventing mistakes from bricking the board and how we'll be able to recover from those sorts of conditions. Like last time, the early days in the beta testing will have much more focus on simply getting everything working. It's probably going to seem like I don't care about optimizations and performance tweaks. I most certainly do, so please don't take my early focus on robustness & functionality to mean performance optimization is being ignored. It will feel that way initially. This new chip offers so much incredible performance and so many ways to optimize, especially since pretty much all the timing sensitive peripherals offer clocking asynchronous from the CPU.
 
I ported coremark to MCUXpresso (GNU GCC 7.2, -O3). coremark ran at 2444 iterations/second (about the same as mbed ARM CC, post #1). I also ran coremark with the "link to RAM" option, but running in RAM didn't seem to affect performance. I did confirm that function addresses were indeed in RAM (post #48). Enabling LTO slowed coremark.
 
Last edited:
Wow Paul, great news! Oh I'm sure we can make the libraries and new hardware work. I need to order some spdif hardware.. my wife kills me if I take her 5+1 cinema surround system.. again.. :)
 
As Frank B said - WOW. You are all amazing. Going to be a lot of work for you all just to get the needed libraries up and running to support the features of the chip. Going to be a busy year next year :) Sign me up for kickstarter - just joking = know its too early for that.
 
Back the CAN testing I was doing in post #61. Once I figured out what it wanted from the Teensy side, I finally go the example working and made some modifications to print additional messages and send a whole 8 bytes of the data. It was receiving as fast as the Teensy could send it, but it needed a minimum of 10ms delay between Teensy sends before the next packet would be received. Without this delay it would hang the program. The teensy pretty much handle as fast as the 1050 would send it. So at least satisfied myself that it could talk to other devices on the CAN bus and got a feel for its library - which was not good. So my assessment still stands - the CAN library will need work.
 
mbed PWM is using eFlexPWM (ch 28, 150 MHz clock) and the mbed API limits you to max PWM frequency of 1 MHz. With scope on D3 (GPIO_AD_B1_08 FLEXPWM4 A0), 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).

Code:
    PWM4->SM[0].VAL1 =5 ;  // 150/6  25 mhz
    PWM4->SM[0].VAL3 =2 ;
    PWM4->MCTRL |= 1;
 
9.2.1 says "MQS (medium quality speaker) is used to convert the I2S audio data from SAI to PWM signals that can drive external speaker directly."
Has the dev-board the connections, and have you tried to connect a speaker?
 
I tried the sai example for recording and playback. It uses a headset mic and the board mic to record and then playback. It does work but volume was low. Have a new headset coming with a mic and as soon as I find my speaker will hook it up and give it a try. Didn't see anything in the api for volume but just did a quick scan. I will try to edit this post when I get done with the test and let you know how it goes
 
@Frank B. Didn't want you to think I forgot about your question. Unfortunately, I have not been able to get the ext speakers working. The board uses a WM8960 98/95 dB Stereo Codec with Class D Speaker Driver chip connected to the 1050. I can't seem to get the routing correct to use ext speaker - its either that or my little 8ohm speaker isn't working. Regardless I am getting sound from the jack connector and its actually pretty nice.

EDIT: I did post to the NXP Forum about how to do get output to the speakers. We'll see what happens.
 
Last edited:
I can't seem to find the max GPIO sink/source current??? The data sheet has an equation Imax = N x C x V x (0.5 x F) with too many unknowns! :D

On my EVKB eval board with hacked USB cable, I measure power at 127 ma for just a while-loop. But if I add a digitalWrite() (led1 = 0 in mbed-speak), the power jumps to 155 ma (nothing attached to digital GPIO pin). What's that all about ???

The eval board schematic shows the on-board USER LED pulled up to 3.3v with 220 ohm resistor. LED forward voltage is about 1.2v so expected current would be 9.5 ma. If the program sets the LED pin HIGH, LED is off and board current is 127 ma. If pin is set LOW, LED is on and current is 155 ma. Toggling a pin (D7) with nothing connected has board power at 155 ma LOW or HIGH.

Here is review of low-power test for eval board
https://www.nxp.com/docs/en/application-note/AN12094.pdf
It describes running at 600 528 132 24 MHz -- I haven't figured out how to do that with mbed core functions ...
 
Last edited:
Most interesting is, in the chapter about the seven PLLs (Reference Manual) they say the CHIP is capable of running with 1 GHz. We will see. If that is true, and they write that, it means it can do even more than that. But let's not talk about overclocking now :) Its just an interesting information, now.( And I fear we had to increase the core-voltage, which may be a bit risky)

Or it's just a wrong information.
 
Last edited:
Back
Top