Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 51 to 75 of 139

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

  1. #51
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,941
    Quote Originally Posted by PaulStoffregen View Post
    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).

  2. #52
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    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.

  3. #53
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    Does it work with linker sections?

  4. #54
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,101
    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 by defragster; 11-20-2018 at 09:16 AM.

  5. #55
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,691
    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.

  6. #56
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,808
    flexcan has it’s own memory mapped address used only for itself, not sure if you can use it without CAN..

  7. #57
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,101
    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 }

  8. #58
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    RAM_WRITETHROUGH would be useful for me. And RAM_NOCACHE . And PROGMEM_NOCACHE.... xmas is near..

  9. #59
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,643
    Quote Originally Posted by mjs513 View Post
    I found out how to do that from this site: https://www.element14.com/community/...display-review. Besides the code block I borrowed for the timer it discusses timings for FFT using the CMSIS-DSP. It also explains how to do it yourself. Makes a good read, highly recommend.
    Yep that's a good review. I've added DSP FFT benchmark data to post #1.

  10. #60
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    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 by mjs513; 11-20-2018 at 01:29 PM.

  11. #61
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    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: 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.

  12. #62
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,808
    for sure ill be working on one whenever the 4.0 comes out

  13. #63
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,691
    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.

  14. #64
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,643
    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 by manitou; 11-25-2018 at 12:41 AM.

  15. #65
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    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..

  16. #66
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    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.

  17. #67
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    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.

  18. #68
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    @manitou - found something on the nxp forum talking about ISR Latency while looking for something else that you might be interested in: https://community.nxp.com/thread/482121

  19. #69
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,643
    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;

  20. #70
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    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?

  21. #71
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    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

  22. #72
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,943
    @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 by mjs513; 11-23-2018 at 12:31 AM.

  23. #73
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,643
    Quote Originally Posted by PaulStoffregen View Post
    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!
    For your reading pleasure, 1050 vs 1060 https://www.nxp.com/docs/en/applicat...te/AN12240.pdf

    NXP 1060 eval board https://www.digikey.com/product-deta...=sp_568_buynow

  24. #74
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,643
    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!

    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/applicat...te/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 by manitou; 11-25-2018 at 11:21 AM.

  25. #75
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    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 by Frank B; 11-23-2018 at 11:50 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •