Forum Rule: Always post complete source code & details to reproduce any issue!
Page 104 of 173 FirstFirst ... 4 54 94 102 103 104 105 106 114 154 ... LastLast
Results 2,576 to 2,600 of 4308

Thread: Teensy 4.0 First Beta Test

  1. #2576
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Quote Originally Posted by defragster View Post
    After the Restore this is what it tells me about the T4-2:
    Could you please run this on your beta #2 board and post the result?

    Code:
    void setup() {
      while (!Serial) ; //wait
      delay(250);
      const uint8_t *data = (const uint8_t *)0x601FF000;
      for (int i=0; i < 4096; i++) {
        if ((i & 15) == 0) Serial.printf("%04X:", i);
        Serial.printf(" %02X", data[i]);
        if ((i & 15) == 15) Serial.print("\n");
      }
    }
    
    void loop() {
    }
    This program prints a hexdump of the top 4K of your flash chip. The big question is whether I messed up getting the restore program into your board, or if you have a good restore image but the restore process is not properly copying it.

  2. #2577
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,191
    Quote Originally Posted by PaulStoffregen View Post
    I've been looking into the SD issues using SPI. This commit "fixes" SD card access on the audio shield (when CS is set to pin 10), at least well enough for "listfiles" to work, with the 1 card I tested here (Samsung EVO 32GB).

    https://github.com/PaulStoffregen/SD...dea142ed21e95b

    I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...
    That patch got listfiles working for my Kingston uSD on the SPI uSD on the audio shield on the T4B2.

    I thought the memset() might just be acting as delay between the CS set and the SPI io, but trying delayMicroseconds(2) in place of memset() didn't work.

  3. #2578
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,415
    Quote Originally Posted by defragster View Post
    @KurtE did some good tests of data integrity for Serial#. Quick search didn't find note on pseudorandom.
    Hi @defragster and @Paul, and @...

    I have done a few different type tests with Serial. Really nothing special.
    For hardware Serial, I did something like fill buffer with known values send them, with a loop back test (connect RX to TX) and compare the resulting values...
    Extended it to have multiple Serial ports, where everything they receive they send back out. Then hook up Serial1 TX -> Serial 2 RX, 2TX->3RX... 7TX->1RX
    And then I can compare the results on what was sent out on Serial1 to begin with with what was returned...

    Then a more useful test for me, is try to talk to Robotis Dynamixel servos using Half duplex usually at 1mbs, but have tried 2mbs and more...
    This uses a very specific packet format - Actually two different formats:
    Older servos run Protocol 1: http://emanual.robotis.com/docs/en/dxl/protocol1/
    Most newer ones run Protocol 2: http://emanual.robotis.com/docs/en/dxl/protocol2/

    Protocol1 uses simple 1 byte checksum, Protocol 2 uses 2 byte CRC...

    On Beta 1, I tried it using Half duplex using (RS485 like support TX direction line), and hooked up to some servos through a OpenCM 485 expansion board.
    These boards are used to plug in their cheap controller (OpenCM9.04C) < $20, and it has a connector where the OpenCM9 board connects a Serial RX, TX, IO pin, and GND...
    to this board, so I used jumpers from Beta 1 board to appropriate positions on the expansion board.... The servos worked

    Next up, with working USB, is to try making the B2 board act like a simple Servo controller, where I try to control the servos of a Robot using RPI3... with it sending commands
    to T4, which forwards to servos... The most simple version is more or less our simple USB Serial to Serial...

    A more complex version is where you logically assign an Servo ID to the controller, who then parses the packets, and if the message is for their ID, it then generates it's own response packet...

    Some of the more interesting things about these types of tests is often it is more interested in latency than it is about throughput. That is often times, the code works like:
    (Send request to Teensy over USB)->Teensy forward packet over Serial -> Wait for response packet over Serial -> forward response back to program over USB... Program continues...

    So The code on both sides is often setup to do something like Serial->flush() when it finishes writing out packet...

    Example: On my hexapod I need to get back to, I may want to send out new position and speed (maybe other) to maybe 20 servos. But in that case with SyncWrites it is lets say we output something like 10 bytes per servo (ID, Position, Speed), plus the overhead of packet to the servos 20*10 + about 10 bytes overhead... So about 210 bytes, over USB... Note SyncWrite does not send response so don't have to wait for it... But then the user may want to get current information for the servos, like Current Position, or Torque, or Temp, or ... So again maybe with this we need to send out the request packet (maybe in the size of maybe 50 bytes (20*2 for ids plus overhead). Then wait for response, again probably in the order of 200+ bytes,
    And we would like to do this maybe 50-100 times per second...

    Will be interesting to see how some things play out for throughput speed. That is for example with the SyncRead. You send out the request for the different servos to respond, each of these servos will wait until the previous servo in the list finishes outputting it's data (plus maybe a gap), before it will send out it's response... So will it be better on USB to wait for all of the packets to finish sending before we respond, or let each part dribble out as it is received...

    Probably enough rambling. Will try out some of this soon!

  4. #2579
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Looks like i've managed to "brick" my T4B2.
    I edited the imrtx1062.ld file to
    Code:
        ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 256K
        DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 256K
    and uploaded a simple sketch
    (yes I know that I have to configure the "flexram, too.. was about to do it)

    And from that point, it does not work anymore.
    I took the changes back, but this does not help.
    It responds to a button-press and upload seems to work:
    Code:
    19:29:44.428 (post_compile 1): Begin, version=1.47-beta1, high-res time
    19:29:44.632 (loader): Teensy Loader 1.47-beta1, begin program
    19:29:44.694 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
    19:29:44.710 (loader): Listening for remote control on port 3149
    19:29:44.710 (loader): initialized, showing main window
    19:29:44.804 (loader): remote connection 1340 opened
    19:29:44.804 (loader): remote cmd from 1340: "comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)"
    19:29:44.804 (loader): remote cmd from 1340: "status"
    19:29:44.804 (loader): HID/win32:  vid:046A pid:0023 ver:0220
    19:29:44.804 (loader): HID/win32:  vid:046A pid:0023 ver:0220
    19:29:44.804 (loader): remote cmd from 1340: "dir:c:\temp\arduino_build_318689\"
    19:29:44.804 (loader): remote cmd from 1340: "file:sketch_apr29a.ino.hex"
    19:29:44.804 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
    19:29:44.804 (loader): remote cmd from 1340: "status"
    19:29:44.806 (post_compile 1): Sending command: comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)
    19:29:44.810 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
    19:29:44.810 (post_compile 1): Sending command: dir:c:\temp\arduino_build_318689\
    19:29:44.810 (post_compile 1): Sending command: file:sketch_apr29a.ino.hex
    19:29:44.819 (loader): remote cmd from 1340: "auto:on"
    19:29:44.820 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
    19:29:44.820 (post_compile 1): Sending command: auto:on
    19:29:44.822 (post_compile 1): Disconnect
    19:29:44.835 (loader): remote connection 1340 closed
    19:29:45.074 (loader): remote connection 1340 opened
    19:29:45.074 (loader): remote cmd from 1340: "comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)"
    19:29:45.074 (loader): remote cmd from 1340: "status"
    19:29:45.074 (loader): remote cmd from 1340: "dir:c:\temp\arduino_build_318689\"
    19:29:45.074 (loader): remote cmd from 1340: "file:sketch_apr29a.ino.hex"
    19:29:45.074 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
    19:29:45.079 (post_compile 2): Begin, version=1.47-beta1, high-res time
    19:29:45.081 (post_compile 2): Sending command: comment: Teensyduino 1.47-beta1 - WINDOWS (teensy_post_compile)
    19:29:45.082 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
    19:29:45.082 (post_compile 2): Sending command: dir:c:\temp\arduino_build_318689\
    19:29:45.082 (post_compile 2): Sending command: file:sketch_apr29a.ino.hex
    19:29:45.090 (loader): remote cmd from 1340: "status"
    19:29:45.092 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, c:\temp\arduino_build_318689\, sketch_apr29a.ino.hex
    19:29:45.092 (post_compile 2): Disconnect
    19:29:45.105 (loader): remote connection 1340 closed
    19:29:45.105 (loader): remote connection 1340 opened
    19:29:45.105 (post_compile 3): Running teensy_reboot: "C:\Arduino\hardware\teensy\..\tools\teensy_reboot.exe" teensy_reboot.exe "-board=TEENSY40" "-port=usb:0/1A0000/0/1/6/3" "-portlabel=(null)" "-portprotocol=(null)"
    19:29:45.118 (reboot 4): Begin, version=1.47-beta1, high-res time
    19:29:45.118 (reboot 4): location = usb:0/1A0000/0/1/6/3
    19:29:45.118 (reboot 4): portlabel = (null)
    19:29:45.118 (reboot 4): portprotocol = (null)
    19:29:45.118 (reboot 4): LoadLibrary cfgmgr32 ok
    19:29:45.118 (reboot 4): LoadLibrary ntdll ok
    19:29:45.119 (reboot 4): nothing new, skipping HID & Ports enum
    19:29:45.121 (loader): remote connection 1408 opened
    19:29:45.121 (reboot 4): Disconnect
    19:29:45.137 (loader): remote connection 1408 closed
    19:29:45.137 (loader): remote connection 1340 closed
    19:29:50.160 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    19:29:50.166 (loader): remote connection 1388 opened
    19:29:50.168 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#0008d7a1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    19:29:50.168 (ports 5): found_usb_device, loc=usb:0/1A0000/0/1/6/4    Port_#0004.Hub_#0006
    19:29:50.168 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0002
    19:29:50.168 (ports 5): found_usb_device, devinst=00000012
    19:29:50.168 (ports 5): add: loc=usb:0/1A0000/0/1/6/4, class=HID, vid=16C0, pid=0478, ver=0002, serial=0008d7a1, dev=\\?\usb#vid_16c0&pid_0478#0008d7a1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    19:29:50.168 (ports 5): hiddev_from_devinst_list: iface=0
    19:29:50.169 (ports 5): found_usb_device complete
    19:29:50.169 (ports 5): hid, found devinst=00000013
    19:29:50.169 (ports 5): hid, path=\\?\hid#vid_16c0&pid_0478#8&af6fcf9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
    19:29:50.169 (ports 5): hid,  opened handle
    19:29:50.170 (ports 5):  devinst=00000013, location=usb:0/1A0000/0/1/6/4
    19:29:50.170 (ports 5):  vid=16C0, pid=0478, ver=0002, usepage=FF9C, use=0024
    19:29:50.170 (ports 5):  devpath=\\?\hid#vid_16c0&pid_0478#8&af6fcf9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
    19:29:50.170 (ports 5): usb_add: usb:0/1A0000/0/1/6/4  hid#vid_16c0&pid_0478 (Teensy 4-Beta2) Bootloader
    19:29:50.173 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    19:29:50.175 (ports 5): nothing new, skipping HID & Ports enum
    19:29:50.188 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    19:29:50.200 (ports 5): nothing new, skipping HID & Ports enum
    19:29:50.213 (loader): Device came online, code_size = 1572864
    19:29:50.213 (loader): Board is: Teensy 4-Beta2 (IMXRT1062), version 0.02
    19:29:50.213 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
    19:29:50.213 (loader): set background IMG_ONLINE
    19:29:50.213 (loader): File "sketch_apr29a.ino.hex". 15268 bytes, 1% used
    19:29:50.213 (loader): elf appears to be for Teensy 4-Beta2 (IMXRT1062) (1572864 bytes)
    19:29:50.213 (loader): elf binary data matches hex file
    19:29:50.213 (loader): elf file is for Teensy 4-Beta2 (IMXRT1062)
    19:29:50.213 (loader): begin operation
    19:29:50.228 (loader): flash, block=0, bs=1024, auto=1
    19:29:50.228 (loader):  gauge old value = 0
    19:29:50.228 (loader): flash, block=1, bs=1024, auto=1
    19:29:50.526 (loader):  gauge old value = 1
    19:29:50.536 (loader): flash, block=2, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 2
    19:29:50.536 (loader): flash, block=3, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 3
    19:29:50.536 (loader): flash, block=4, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 4
    19:29:50.536 (loader): flash, block=5, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 5
    19:29:50.536 (loader): flash, block=6, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 6
    19:29:50.536 (loader): flash, block=7, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 7
    19:29:50.536 (loader): flash, block=8, bs=1024, auto=1
    19:29:50.536 (loader):  gauge old value = 8
    19:29:50.536 (loader): flash, block=9, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 9
    19:29:50.546 (loader): flash, block=10, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 10
    19:29:50.546 (loader): flash, block=11, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 11
    19:29:50.546 (loader): flash, block=12, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 12
    19:29:50.546 (loader): flash, block=13, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 13
    19:29:50.546 (loader): flash, block=14, bs=1024, auto=1
    19:29:50.546 (loader):  gauge old value = 14
    19:29:50.556 (loader): sending reboot
    19:29:50.556 (loader): begin wait_until_offline
    19:29:50.591 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    19:29:50.593 (ports 5): remove: loc=usb:0/1A0000/0/1/6/4
    19:29:50.593 (ports 5): usb_remove: usb:0/1A0000/0/1/6/4
    19:29:50.593 (ports 5): nothing new, skipping HID & Ports enum
    19:29:50.627 (loader): offline, waited 1
    19:29:50.627 (loader): end operation, total time = 0.415 seconds
    19:29:50.627 (loader): set background IMG_REBOOT_OK
    19:29:50.627 (loader): redraw timer set, image 14 to show for 1200 ms
    19:29:50.642 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    19:29:50.643 (ports 5): nothing new, skipping HID & Ports enum
    19:29:50.709 (loader): HID/win32:  vid:046A pid:0023 ver:0220
    19:29:50.709 (loader): HID/win32:  vid:046A pid:0023 ver:0220
    19:29:51.837 (loader): redraw, image 9
    19:29:52.270 (ports 5): purge, name=hid#vid_16c0&pid_0478 (Teensy 4-Beta2) Bootloader, loc=usb:0/1A0000/0/1/6/4, age=1.677 sec
    19:29:56.080 (loader): Verbose Info event
    But the program does not run.
    Same if I do the 15-sec reset (the inbuilt "blink" works)

    Edit: Arduino shows no Teensy port - com1 only, which is on the PC-mainboard.


    Edit: Don't know exactly what this was... deleted all Teensy USB dvices from Windows, rebooted, downloaded Teensyduino again and did a fresh install.. works!!
    Last edited by Frank B; 04-29-2019 at 06:33 PM.

  5. #2580
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    Man - a lot going on. Have to download the latest changes. Been trying to get FD working but 0 luck so far. Did find that for CAN3 there is a IOMUXC register missing from imxrt.h but everything else is there. Now just trying to break the code on why its not working. A little more complicated than regular CAN - a couple extra variable thrown in - new MCP2558FD chip and having to get it to talk to a different setup - clickFD board on the T3.5.

  6. #2581
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,415
    If I wanted to play a little with canbus suggestions on what I should order?

  7. #2582
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,676
    Quote Originally Posted by PaulStoffregen View Post
    Could you please run this on your beta #2 board and post the result?

    ...

    This program prints a hexdump of the top 4K of your flash chip. The big question is whether I messed up getting the restore program into your board, or if you have a good restore image but the restore process is not properly copying it.
    You read my mind … to read the source …
    Code:
    08F0: 02 03 01 26 03 54 00 65 00 65 00 6E 00 73 00 79     & T e e n s y
    0900: 00 64 00 75 00 69 00 6E 00 6F 00 20 00 52 00 61   d u i n o   R a
    0910: 00 77 00 48 00 49 00 44 00 18 03 54 00 65 00 65   w H I D   T e e
    0920: 00 6E 00 73 00 79 00 64 00 75 00 69 00 6E 00 6F   n s y d u i n o
    Code:
    void setup() {
      while (!Serial) ; //wait
      delay(250);
      char lTxt[20];
      int i, jj = 0;
      const uint8_t *data = (const uint8_t *)0x601FF000;
      for (i = 0; i < 4096; i++) {
        if ((i & 15) == 0) Serial.printf("%04X:", i);
        Serial.printf(" %02X", data[i]);
        if ( data[i] >= 32 && data[i] <= 126 )
          lTxt[jj++] = data[i];
        else
          lTxt[jj++] = ' ';
        if ((i & 15) == 15) {
          lTxt[jj] = 0;
          Serial.printf("  %s\n", lTxt);
          jj = 0;
        }
      }
    }
    
    void loop() {
    }

    My sketch ran happily the past hours - encoder turn gave expected messages … general function seems good Paul
    Last edited by defragster; 04-29-2019 at 09:32 PM.

  8. #2583
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @Paul, is it correct, that the size of a RAM Bank is 64KB on a 1062, and 32 KB on a 1052?
    So, doing this:

    noInterrupts();
    IOMUXC_GPR_GPR17 = 0x55AFFA55;
    IOMUXC_GPR_GPR16 |= (1<<2);
    interrupts();

    in theory should switch to ITCM=256, DTCM=256, OCRAM =512 ?


    However, it seems it does not because this crashes:

    #define TESTADR (*( uint32_t *)0x20020000)
    TESTADR = 7;

    Where is my fault?

  9. #2584
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    Quote Originally Posted by KurtE View Post
    If I wanted to play a little with canbus suggestions on what I should order?
    Hi Kurt. Just woke up Anyway to get started with CAN you have to know there are 2 flavors of CAN. CAN2.0 and CANFD. On the T4 you have CAN1/2 on pins 22/23 and pins 0/1. CAN2.0 is also available on the T3.2/3.5/3.6 For that all you will need is two transceivers (someone said you could just hook up the pins directly but not sure how reliable that is), I use these, since they are breadboard friendly: https://www.amazon.com/gp/product/B0...?ie=UTF8&psc=1. There are several libraries available to use them on the T3.x and @tonton81 has one working for CAN2.0 for the T4 but still a WIP. These have been tested.

    Now, CANFD is a different animal, Tony and I are using a Mikro MCP2517FD Click, https://www.digikey.com/products/en?...oe%20mcp2517fd, that we used to play with FD on the T3.x's. Uses SPI to communicate with the FD driver/transceiver on the Click board. @tonton81 has a nice library for that he developed and we tested the heck out of. It's similar to SK Pang's CANFD boards. One would be a minimum to interface to the T4.

    Now, I have been playing with the SDK driver but having challenges that I just can't seem to pin down. @tonton81 just got his T4 today so probably more on this later. Not sure if the problems are the clock configuration, pin configuration or something with the driver or with the interface to the Click.

    Know this is long winded but figured I would put it out there for reference. I am sure @tonton81 will jump in here if I said anything wrong.

  10. #2585
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Quote Originally Posted by manitou View Post
    I thought the memset() might just be acting as delay between the CS set and the SPI io, but trying delayMicroseconds(2) in place of memset() didn't work.
    Yeah, I was a little surprised at first. SD cards are supposed to ignore MOSI during that time, but it seems some cards don't. Kinda makes me wonder what sort of undocumented behavior may be lurking.

    At first I wondered how this ever could have worked. But then I realized that particular code is only used by Teensy LC. Makes me wonder if we've had similar SD card problems on LC all this time, but never knew because only some cards are affected and most people don't use LC for heavier tasks involving SD card access?

  11. #2586
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by Frank B View Post
    @Paul, is it correct, that the size of a RAM Bank is 64KB on a 1062, and 32 KB on a 1052?
    So, doing this:

    noInterrupts();
    IOMUXC_GPR_GPR17 = 0x55AFFA55;
    IOMUXC_GPR_GPR16 |= (1<<2);
    interrupts();

    in theory should switch to ITCM=256, DTCM=256, OCRAM =512 ?


    However, it seems it does not because this crashes:

    #define TESTADR (*( uint32_t *)0x20020000)
    TESTADR = 7;

    Where is my fault?
    My fault was that 512KB are dedicated to OCRAM, so the RAM-BANK size is still 32KB.
    This works:
    noInterrupts();
    IOMUXC_GPR_GPR17 = 0xAAAAFFFF;
    IOMUXC_GPR_GPR16 |= (1<<2);
    interrupts();

    //Serial.println(TSTADR);
    Serial.println();
    Serial.println(IOMUXC_GPR_GPR16, HEX);
    Serial.println(IOMUXC_GPR_GPR17, HEX);

    #define TSTADR (*( uint32_t *)0x20030000)
    TSTADR = 7;

    now, with adjusting the stackpointer it should be possible to use the mentioned configuration. Only minor edits to startup.c are needed.

    I'll try that tomorrow. Too late here for working people...

    However, I need to test OCRAM - not sure if the printed Adress here is correct - it is the same as for 1052(?!)
    https://www.nxp.com/docs/en/application-note/AN12240.pdf


  12. #2587
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    ...we can use a common linker file for all RAM configs
    Code:
    MEMORY
    {
        ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
        DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
        RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
        FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1536K
    }
    [...]
    It will not detect overflows anymore - that a job for a new size - print tool... we need it anyway.

    ...and we can detect the needed ITCM at runtime, so it's possible to automatically select the needed ITCM/DTCM sizes in 32KB steps - at runtime.
    I'll do that tomorrow.

  13. #2588
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Quote Originally Posted by mjs513 View Post
    Did find that for CAN3 there is a IOMUXC register missing from imxrt.h but everything else is there.
    Opps, missed those new IOMUXC registers. Hopefully this helps?

    https://github.com/PaulStoffregen/co...83c60234c56e1f

    Thanks Paul. I added the CAN3 but of course I had the wrong offset
    Last edited by mjs513; 04-29-2019 at 10:29 PM.

  14. #2589
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,676
    Quote Originally Posted by Frank B View Post
    ...we can use a common linker file for all RAM configs



    It will not detect overflows anymore - that a job for a new size - print tool... we need it anyway.

    ...and we can detect the needed ITCM at runtime, so it's possible to automatically select the needed ITCM/DTCM sizes in 32KB steps - at runtime.
    I'll do that tomorrow.
    Good info and progress FrankB! Nice finding you can't really brick the T4 too! - I thought I did it the other day as the 15s Restore took 3 times to work.

    Also nice you did the print size tool - that will come in handy and be important given the memory split/segmentation. I was thinking it is good the T4 is small like the T_3.2 - that will leave more room on the card for pin details - but the T4 is going to need a Tech manual - or a good web page or wiki.

  15. #2590
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Tim,
    for the fixed 256k, 256k, 512k you can use this:
    Code:
    void ResetHandler(void)
    {
        asm volatile("CPSID I");
        //SCB_MPU_CTRL = 0; // turn off MPU
        IOMUXC_GPR_GPR17 = 0xAAAAFFFF;
        IOMUXC_GPR_GPR16 |= (1<<2);
        //force the stack to begin at some arbitrary location
        asm volatile("mov sp, %0" : : "r" (0x20040000) : );
        asm volatile("CPSIE I");    
        
        unsigned int i;
    ...
    ...
    with this edit to the imxrt1062.ld file:
    Code:
    MEMORY
    {
        ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
        DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
        RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
        FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1536K
    }
    
    ENTRY(ImageVectorTable)
    ...
    ...
    tomorrow, I try to make it more flexible, and add a "automatic adjust".
    Yes the linker files has wrong numbers. This is intentionally..
    Attention, OCRAM is still not tested. Maybe we have to adjust the OCRAM adress. I'm not sure...

    Good night.

    edit: Attention this will not work for the 1052 - We have to add a #ifdef for 1062 only.

  16. #2591
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Quote Originally Posted by Frank B View Post
    toromorrow, i try to make it more flexible.
    On my todo list (but after USB) is changing the linker script to 512K for both ITCM and DTCM, and an additional program run during the build which checks the total size when rounding each up to nearest 32K doesn't exceed 512K, and of course code in startup to dynamically configure based on the real sizes.

    If you're going to work on this soon, please go with that basic approach. I know it'll feel risky declaring 1M of TCM memory in the linker script without the middle step to check for too much memory used, but please go that route and assume I'll later add the overflow check.

  17. #2592
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @PaulStoffregen

    Just received the modified breakout board with the addition of the resistor - thank you for doing that. I just played my wavFilePlayer and worked right out of the box, only 1 file didn't play but that's a problem with the file . The player reads the SD Card on the audio shield and the plays the various formats using @Frank B's codecs:
    Code:
    initialization done.
    SYSTEM~1
    Playing file: //OPERAT~1.WAV
    2001
    Playing file: 2001/CALCUL~1.WAV
    Playing file: 2001/COMPLE~1.WAV
    Playing file: 2001/DANGER~1.WAV
    Playing file: 2001/ENOUGH~1.WAV
    Playing file: 2001/FUNCTI~1.WAV
    Playing file: 2001/ONE_MO~1.WAV
    Playing file: 2001/OPERAT~1.WAV
    Playing file: 2001/SORRY_~1.WAV
    Playing file: 2001/STOP.WAV
    FLAC
    Playing file: FLAC/T1_1024.FLA
    Playing file: //BERLIN~1.FLA
    Playing file: //CHRIST~1.AAC
    Playing file: //ODD.MP3
    Playing file: //ODD1.MP3
    Playing file: //ZARATH~1.MP3
    Playing file: //ODD1.WAV
    Playing file: //SDTEST1.WAV
    Playing file: //CALCUL~1.WAV
    I also checked Zelda and Guitar sketches and sounds great.

  18. #2593
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,070
    Yes Mike everything you said is correct, i might play a couple more days on the rtr frames before bringing fd into play since it has same offsets as the other busses, once i reconnect the click boards to the t3.5 and t3.6 and have them communicating back and forth in a loop ill be able to work on the FD version from the sdk for t4. The library wont have features or enhancements in it’s current state because i’m rebuilding it from the base up, so only after the functionality is in play i will readd queue support and enhancements. The new library will support up to 128 can ids for fifo and obviously 64 mailboxes (in it’s current state they are working) but i want to tackle the transmissions of rtr, also t4 will have the can clock selectable in future, currently we have the clock running at 60mhz, the sdk runs at 20/24

  19. #2594
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,676
    Looking into Windows app for USB I found : github.com Device enumeration and pairing sample

    Paul - did you note that 'Winusb.sys' is the inbuilt driver used to talk to a Teensy?

    @KurtE / mjs513 - that sample app might be useful for USBHost enumeration and pairing observation

    Also thought that or another sample might lead to T4 interface to do some data Transfer testing ...

    … Sure While that 27MB package is unzipping the WHOLE sample set - I'll open VS2017 and UPDATE … opps ... Update involves removing the install and pulling down 8.8GB … how handy … my internet is mostly blocking all else and getting 400 to 490KB/sec … just 18+ hours … 1.6GB down ...

  20. #2595
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Quote Originally Posted by defragster View Post
    Paul - did you note that 'Winusb.sys' is the inbuilt driver used to talk to a Teensy?
    Nope, we're not using winusb in any way. I'm considering it (and libusb or similar on Mac & Linux) for a future feature, but kinda hoping more Windows users migrate away from version 7 first. Yeah, I know it's possible to make it work on Windows 7, but that requires installing stuff that doesn't fit well with the Teensyduino installer. The last thing I want is more Windows 7 support nightmares!

    Please remember to run the code from msg #2576. I want to understand why the restore process isn't always working on your board. The first step is to figure out whether your board really does have a complete copy of the restore image permanently stored in the top of the flash.

  21. #2596
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,676
    Paul - reposting this as it seems to have been missed some hours back? Output is in the attached TXT file.

    Quote Originally Posted by PaulStoffregen View Post
    Nope, we're not using winusb in any way. ...

    Please remember to run the code from msg #2576. ...
    If I worked up the sample - would winusb on my machine find the device as is as far as you know? What is the 'standard windows driver' named that works for Teensy?

    Quote Originally Posted by defragster View Post
    You read my mind … to read the source …
    Code:
    08F0: 02 03 01 26 03 54 00 65 00 65 00 6E 00 73 00 79     & T e e n s y
    0900: 00 64 00 75 00 69 00 6E 00 6F 00 20 00 52 00 61   d u i n o   R a
    0910: 00 77 00 48 00 49 00 44 00 18 03 54 00 65 00 65   w H I D   T e e
    0920: 00 6E 00 73 00 79 00 64 00 75 00 69 00 6E 00 6F   n s y d u i n o
    Code:
    void setup() {
      while (!Serial) ; //wait
      delay(250);
      char lTxt[20];
      int i, jj = 0;
      const uint8_t *data = (const uint8_t *)0x601FF000;
      for (i = 0; i < 4096; i++) {
        if ((i & 15) == 0) Serial.printf("%04X:", i);
        Serial.printf(" %02X", data[i]);
        if ( data[i] >= 32 && data[i] <= 126 )
          lTxt[jj++] = data[i];
        else
          lTxt[jj++] = ' ';
        if ((i & 15) == 15) {
          lTxt[jj] = 0;
          Serial.printf("  %s\n", lTxt);
          jj = 0;
        }
      }
    }
    
    void loop() {
    }
    ...

  22. #2597
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,191
    Quote Originally Posted by PaulStoffregen View Post
    Yeah, but hard to say exactly what to test or how.

    Long ago, there was a thread about sending a huge amount of pseudo-random data in both directions and verifying a checksum after several megabytes. Any maybe measuring the speed along the way. Was going to try to recreate that. If anyone wants to give it a try, please jump in and write a little code on both sides. Otherwise, I'll probably do it in a day or two....
    FYI. There were some serial USB throughput and latency tests that we used on K66

    https://forum.pjrc.com/threads/34808...l=1#post107140
    https://www.pjrc.com/teensy/benchmar...l_receive.html
    https://www.pjrc.com/teensy/usb_serial.html
    https://forum.pjrc.com/threads/23643...ed-Improvement
    https://forum.pjrc.com/threads/7826-...ital-I-O-delay

    Tests were sensitive to the host OS as well as core USB implementation.

    and 2011 UNO/Teensy2 discussions http://forum.arduino.cc/index.php?topic=59892.0

    EDIT: 6/26/19

    USB serial benchmark results (latency_test and USBreadbytes) on T4B2R 1.8.8 1.47-beta4
    Code:
    latency_test /dev/ttyACM0
    port /dev/ttyACM0 opened
    waiting for board to be ready:
    .ok
    latency @ 1 bytes: 0.18 ms average, 3.56 maximum
    latency @ 2 bytes: 0.16 ms average, 1.81 maximum
    latency @ 12 bytes: 0.13 ms average, 0.21 maximum
    latency @ 30 bytes: 0.19 ms average, 4.70 maximum
    latency @ 62 bytes: 0.12 ms average, 0.17 maximum
    latency @ 71 bytes: 0.17 ms average, 4.26 maximum
    latency @ 128 bytes: 0.12 ms average, 0.17 maximum
    latency @ 500 bytes: 0.32 ms average, 6.98 maximum
    latency @ 1000 bytes: 0.43 ms average, 4.97 maximum
    latency @ 2000 bytes: 0.84 ms average, 5.44 maximum
    latency @ 4000 bytes: 1.40 ms average, 2.20 maximum
    latency @ 8000 bytes: 2.77 ms average, 3.72 maximum
    
                receive_test /dev/ttyACM0
                port /dev/ttyACM0 opened
                ...
                Bytes per second = 5450581
                Bytes per second = 5459509
                Bytes per second = 5516227
                Average bytes per second = 5450651
    Last edited by manitou; 06-26-2019 at 03:54 PM.

  23. #2598
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,676
    WOW - the flashcode text has 5 Views! Paul hopefully you are one of them? It was posted as soon as I got to the forum … before I ate even.

    T4- has two working encoders with a different interface to each - the @mjs513 linked code and the encoder.h library - both working together without issue - interrupts seems fine. Did a quick edit as the encoder was pulsing 4 times per click so I cut the range/4.

    Found a com port stress test that shows ~24KB/sec on T_3.6 with block reads and about the same with byte reads on T4-2 - it sends and gets random data and verifies, seems it doesn't work in 64 byte blocks so the T4 runs same speed - when I did the write(buffer) I forgot the buffer len param and it was showing errors until added on T_3.6, so app works to confirm data and both handled the data.

    Visual Studio update completed and rebooted … now [well not now now] to do a loopback test … assuming the PC will be better at write/read/verify with larger memory space. Maybe I'll get somewhere with that by the time read(buf, .available) is ready?

    Edit>> now 6 views on the code … and just a few more GB to get the new SDK for Visual Studio …
    Last edited by defragster; 04-30-2019 at 10:36 AM.

  24. #2599
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,553
    Does anyone on the list of beta testers with only beta #1 hardware, or no hardware at all yet, want to do specific stuff with the beta #2 hardware? Within the next 2 weeks?

    The beta #3 boards are being made now. They're approx 2 to 3 weeks out. Beta #3 is nearly identical to beta #2. Beta #3 will be the first machine-built boards and we'll have enough for everyone on the list.

    Beta #2 boards take quite a lot of manual labor, so please request one only if you're sure you'll do something specific with it in the next 2 weeks. If you are, please reply here and/or contact me by email. Looks like we can solder up just a few more beta #2 boards. If you're on the list and really have something you want to do with it right now, I'd love to get one of these last beta #2 boards into your hands.

    As always, the beta test hardware is only being made available to the people listed in msg #1 of this long thread. When we have more hardware available, I might expand the list a bit - but generally the list is only open to people who've been long-time contributors on this forum and authors of important open source Arduino libraries.

  25. #2600
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,191
    GPT2 capture not working ?

    I tried porting the GPT capture sketch that i used on T4B1 (GPT1 capture 1, pin 30) to the T4B2 which uses GPT2 capture 1 (pin 15). Testing with PWM from pin 14, i am not getting a capture interrupt ???
    https://github.com/manitou48/teensy4..._capture62.ino

    any one see any obvious mistakes?

Posting Permissions

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