Forum Rule: Always post complete source code & details to reproduce any issue!
Page 42 of 174 FirstFirst ... 32 40 41 42 43 44 52 92 142 ... LastLast
Results 1,026 to 1,050 of 4350

Thread: Teensy 4.0 First Beta Test

  1. #1026
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Kurt, sorry, a "0" too much.. not 7.2 GHz
    uint32_t clkhz = 720000000u / (((CCM_CBCMR >> 26 ) & 0x07 ) + 1); // LPSPI peripheral clock

    copy&paste as usual...for me

    the PLL runs with 720MHz "only"...

    DIV=3 after calculation

  2. #1027
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,570
    Thanks, yep I had a feeling you would say that...

    With that I am seeing a 72mhz clock

    Click image for larger version. 

Name:	screenshot.jpg 
Views:	20 
Size:	32.9 KB 
ID:	15665

    And my display appears to be working

    And for what is worth, the timings show:
    Code:
    Benchmark                Time (microseconds)
    Screen fill              87690
    Text                     6410
    Lines                    36550
    Horiz/Vert Lines         7300
    Rectangles (outline)     4770
    Rectangles (filled)      180500
    Circles (filled)         35010
    Circles (outline)        36470
    Triangles (outline)      8480
    Triangles (filled)       64100
    Rounded rects (outline)  14140
    Rounded rects (filled)   199420
    Rectangles (filled) FB     20180
    Rounded rects (filled) FB   22240

  3. #1028
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Ah..ok..the half.. hm, why? Something is not right either with my calculation or with the documentation - i guess, it's my fault...
    OK, 72 MHz is OK - yes my display works with that, too. Cool

    Thank You !!

  4. #1029
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953

    Micros working at 1us

    <Update:> Expected to work [200 and above MHz] - Pull request updated
    Updated Syncron_isr below and added Syncron_Micros that runs the same code with real time CORES micros with pull code above.

    The posted 10X speed test version ran 720 error free passes of the passing of 100,000,000 sequential 'microsecond' and six cold USB plug restarts after upload. Uploaded a pure 'ARM Synchronization Primitives' version without my sample and cleaned up a bit [then added #ifdef's as I wrote this post ]- realized both samples handle clock wrap. That version just finished another 135 loops()'s of 100M with no problem. Uploaded version cycles clock speed each 3rd iteration [except first loop is 2].

    Quote Originally Posted by Frank B View Post
    Yes, it triggers on any interrupt.
    Thanks for confirmation - the Synchronization article didn't state any _isr - it read like it watched the actual var for write. Sample above updated to remove forced write in _isr

    Quote Originally Posted by manitou View Post
    Re: systick, micros, GPT
    Just one more thought on systick and micros. You could replace the core systick timing with GPT2 timer. GPTx has COMPARE register so can do the 1 ms tick interrupt, and the GPT clock is running at 24 mhz, so you get full resolution micros() and a clock independent of CPU clock.

    Actually, I would like to see systick used at CPU clock speed, and systick reconfigured if user changes CPU clock speed ...
    Uploaded Syncron_isr tests with changing F_CPU_ACTUAL. The real systick_isr runs in constant time - getting 1000 ticks/sec - from
    Code:
      ccdelta = ARM_DWT_CYCCNT - systick_cycle_count;
      usec = 1000 * systick_millis_count + (ccdelta / (F_CPU_ACTUAL / 1000000));
    Works with IntervalTimer 1000us systick simulation sketch:
    > doesn't use any other timer hardware, except CycCnt and slow millis systick.
    > micros and as used by elapsedMicros will have resolution to 1us regardless of clock speed (as long as systick is 1000 us)
    > Does not disable interrupts, and is interrupt safe
    > runs in time similar to current micros() - will confirm when PULL updated
    > test sketch runs at these F_CPU_ACTUAL speeds in CORRECT constant time: 600000000, 498000000, 402000000, 300000000, 201000000, 99428571, 696000000, 804000000 [ 200 Mhz to 800 Mhz]
    > Slowed CPU misses us's so added #ifdef CHANGE_SPEED to allow misses at F_CPU_ACTUAL: 99428571
    > FOUND/Added special case for Loop#1 - at 600 Mhz until cache fills it would skip one us increment and report ERROR

    Will move changes back to CORES and update the PULL … Updated cores/pull/330
    Also added 800 MHz to test loop, only one showing trouble returning micros() in order is the 100 MHz.
    Updated test code to remove test false error at the uint32_t wrap spot, faster to test now so 200 MHz doesn't miss. <github test code update after overnight run>
    Last edited by defragster; 01-20-2019 at 10:57 AM. Reason: Pull 330 updated

  5. #1030
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Tim, my English sometimes makes it hard for me to follow you in the details...
    Does that mean your code is now fully functional and shows no mismeasurements - or mismeasurements larger than micros() on T3.6?

    Congratulations then

    @Paul:
    As I don't understand my miscalculation above, I looked at the PFDs. It seems they need a restart after PLL-Lock.
    Manual:
    When the related PLL is powered up from the power down state or made to go through a
    relock cycle due to PLL regrogramming, it is required that the related PFDx_CLKGATE
    bit in CCM_ANALOG_PFD_480n or CCM_ANALOG_PFD_528n, be cycled on and off
    (1 to 0) after PLL lock. The PFDs can be in the clock gated state during PLL relock but
    must be un-clock gated only after lock is achieved. See the engineering bulletin,
    Configuration of Phase Fractional Dividers (EB790) at www.nxp.com for procedure
    details.
    I don't know if you do that - in any case, here is an useful document, maybe interesting for others..
    https://www.nxp.com/docs/en/engineer...etin/EB790.pdf

  6. #1031
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953
    Quote Originally Posted by Frank B View Post
    Tim, my English sometimes makes it hard for me to follow you in the details...
    Does that mean your code is now fully functional and shows no mismeasurements - or mismeasurements larger than micros() on T3.6?

    Congratulations then
    ...
    You and Paul both AFAIK it is testing Perfectly - but didn't say that in so many words - just 'Will move changes back to CORES and update the PULL' and test details where I did NOT find any problems except my testing for 1us change at lower CPU speeds … and on 600 MHz startup Loop #1

    <correction>: Perfect over 100 MHz - under 100 MHz the last digit is noisy from the 1us math.
    Last edited by defragster; 01-19-2019 at 10:20 PM.

  7. #1032
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    RADIOHEAD LIBRARY AND ADAFRUIT RF69 MODULE

    When I tested the radiohead library using one of the supplier examples the module failed on initialization for the module. Looking at he Adafruit example for the module there are a couple of things they do that are not in the stock library example:
    1. For the Teensy 3.1 they define the modules interrupt pin as:
    Code:
    #define RFM69_IRQ     4    // "C"
    #define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )
    2. They use a manual reset of the chip:
    Code:
      pinMode(RFM69_RST, OUTPUT);
      digitalWrite(RFM69_RST, LOW);
    
      // manual reset
      digitalWrite(RFM69_RST, HIGH);
      delay(10);
      digitalWrite(RFM69_RST, LOW);
      delay(10);
    Then the rest of the code is as it would be in the example. Doing it this way seems to work and the module inits and proceeds to listen. Have to hook the other one up to the T3.2 I have on the breadboard and make sure it actually is transmitting and receiving.

    EDIT: Hooked up the other module to the T3.2 with the same construct and yes the are talking to each other. On the T3.2 the following config works:
    Code:
    #define RFM69_RST     3   // "A"
    #define RFM69_CS      10   // "B"
    #define RFM69_IRQ     2    // "C"
    #define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )
    If I switch pins 2 and 3 it doesn't work. Haven't tried it on the T4 yet

    EDIT 2: Looks like I can move rst pin but the IRQ has to stay on 2. Not sure why? When I am more awake going to poke around the code.
    Last edited by mjs513; 01-19-2019 at 10:06 PM.

  8. #1033
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    PFDs for PLL2 and PLL3:
    - They have random, useless settings.
    The manual shows two different(!!!) "default" register values, both do not match the set values... (haha)
    I created a pull-request to fix that for PLL2 (352, 594, 396, 297 MHz)
    With PLL3, I have some problems.. something is not as it should be. Have asked Paul if he knows more..

    This is also the reason why my assumed 144MHz for SPI are 72MHz in reality.. - OK, found the Problem, but have no fix, yet.. should be easy as soon I know the reason for the "strange" PLL3
    Last edited by Frank B; 01-20-2019 at 11:11 AM.

  9. #1034
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953
    Post #1029 and Pull request updated

    Mike - you just HAVE to try it out - it prints TEMP before each loop()! and as clock speed changes each three 10 second loops the temp drops/rises.

    LED flashes - USB serial cryptic spew that tells (me) stuff. If an error occurs each line after will show that in case it scrolled off.

  10. #1035
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Tim, read my comment on github re:systick_safe_read ?

  11. #1036
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953
    Quote Originally Posted by Frank B View Post
    Tim, read my comment on github re:systick_safe_read ?
    Not finding the comment? In the Pull 330 or elsewhere?

  12. #1037
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679

  13. #1038
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953
    Thanks Frank - it showed up 6 minutes later in email and on the web …
    Code changed - cleaned out the unused volatiles in both sketches too.

    Mike: Temp as low as 42.01 at 200 MHz then in 20 & 30 seconds hits 49.21 at 700 MHz - then drops with most 10 sec update as speed is dropped.

  14. #1039
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    Quote Originally Posted by defragster View Post
    Post #1029 and Pull request updated

    Mike - you just HAVE to try it out - it prints TEMP before each loop()! and as clock speed changes each three 10 second loops the temp drops/rises.

    LED flashes - USB serial cryptic spew that tells (me) stuff. If an error occurs each line after will show that in case it scrolled off.
    Assuming you are talking about your test case in post#1029 - will give it a try - fun watching what happens to the temperature as things change - at some point need to really stress the chip and see what the temp does

  15. #1040
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    Quote Originally Posted by mjs513 View Post
    RADIOHEAD LIBRARY AND ADAFRUIT RF69 MODULE

    When I tested the radiohead library using one of the supplier examples the module failed on initialization for the module. Looking at he Adafruit example for the module there are a couple of things they do that are not in the stock library example:
    1. For the Teensy 3.1 they define the modules interrupt pin as:
    Code:
    #define RFM69_IRQ     4    // "C"
    #define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )
    2. They use a manual reset of the chip:
    Code:
      pinMode(RFM69_RST, OUTPUT);
      digitalWrite(RFM69_RST, LOW);
    
      // manual reset
      digitalWrite(RFM69_RST, HIGH);
      delay(10);
      digitalWrite(RFM69_RST, LOW);
      delay(10);
    Then the rest of the code is as it would be in the example. Doing it this way seems to work and the module inits and proceeds to listen. Have to hook the other one up to the T3.2 I have on the breadboard and make sure it actually is transmitting and receiving.

    EDIT: Hooked up the other module to the T3.2 with the same construct and yes the are talking to each other. On the T3.2 the following config works:
    Code:
    #define RFM69_RST     3   // "A"
    #define RFM69_CS      10   // "B"
    #define RFM69_IRQ     2    // "C"
    #define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )
    If I switch pins 2 and 3 it doesn't work. Haven't tried it on the T4 yet

    EDIT 2: Looks like I can move rst pin but the IRQ has to stay on 2. Not sure why? When I am more awake going to poke around the code.
    Mystery solved. The radiohead driver for the RF69 seems to be written for the lowest common denominator - no chip specific code included - seems that is left up to the user. Based on the notes for the interrupts piece:
    // Set up interrupt handler
    // Since there are a limited number of interrupt glue functions isr*() available,
    // we can only support a limited number of devices simultaneously
    // ON some devices, notably most Arduinos, the interrupt pin passed in is actuallt the
    // interrupt number. You have to figure out the interruptnumber-to-interruptpin mapping
    // yourself based on knwledge of what Arduino board you are running on.
    The code allows interrupt indices 0, 1, and 2 (only 3) so ergo we can only use pins 0, 1, 2. This I tested on the T4 and confirms it. Also, the defines can be simplified to:
    Code:
    #define RFM69_RST     3   // "A"
    #define RFM69_CS      10  // "B"
    #define RFM69_INT     digitalPinToInterrupt(2 )
    
    // Singleton instance of the radio driver
    RH_RF69 rf69(RFM69_CS,RFM69_INT);
    So while the library works, there is a problem with existing examples. Not sure how to handle this for inclusion into Teensyduino, unless we create a Teensy fork with just teensy examples like Adafruit did for their boards.

    The other big caveat I only have one radio type to test the library with.

    @Paul, others - suggestions?

    EDIT: [DELETED]. Any suggestion for a good radio to test

    EDIT2: looks like the RF95, cc110 has the same problems, There may be others.
    Last edited by mjs513; 01-20-2019 at 04:14 AM.

  16. #1041
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,953
    Quote Originally Posted by mjs513 View Post
    Assuming you are talking about your test case in post#1029 - will give it a try - fun watching what happens to the temperature as things change - at some point need to really stress the chip and see what the temp does
    Yes, this one is the standalone version github.com … Syncron_isr using IntervalTimer to make same edits as the pull request.

    <opps:: removed misc sketch errors - now corrected where compare code below was bad>
    Also added 'Clock Speed is:804000000 C=49.86' [rises to C=51.17] to the loop

    From this test to make sure slow speeds could keep up better: <<< BAD TEST at max uint32_t
    if ( usn <= (rrN-1 ) && ( usn <= rrN+5 ) ) // extra us ticks missed slower speeds

    Proper testing working - and faster test cycle misses less - but still 100 MHz fails to control the last returned 1us digit:
    dd = rrN - usn;
    if ( dd == 0 ) ;
    else if ( dd == 1 ) nn++;
    else if ( dd <= 2 ) // extra us ticks missed slower speeds
    ...
    Last edited by defragster; 01-20-2019 at 09:44 AM.

  17. #1042
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by Frank B View Post
    PFDs for PLL2 and PLL3:
    - They have random, useless settings.
    The manual shows two different(!!!) "default" register values, both do not match the set values... (haha)
    I created a pull-request to fix that for PLL2 (352, 594, 396, 297 MHz)
    With PLL3, I have some problems.. something is not as it should be. Have asked Paul if he knows more..

    This is also the reason why my assumed 144MHz for SPI are 72MHz in reality.. - OK, found the Problem, but have no fix, yet.. should be easy as soon I know the reason for the "strange" PLL3
    The exact PLL3 PFD freqs are:

    PFD0: 720000000Hz
    PFD1: 664615384Hz
    PFD2: 508235294Hz
    PFD3: 454736842Hz

    Fix is here - without that the PFDs are not usable due to wrong settings: https://github.com/PaulStoffregen/cores/pull/335
    Last edited by Frank B; 01-20-2019 at 11:11 AM.

  18. #1043
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    REASSIGNING ALT FUNCTIONS TO PINS 0 and 1 NOT WORKING

    @Paul and others,

    In post #996 I was able to reassign the pins (2, 3) to XBAR1 and read encoder values. As a test I tried to that this morning on pins 0 and 1 without any success, nothing being read! I made the pin pad and config changes by substituting 2 ->0 and 3->1, the IO numbers for pins 0,1 are IO16,17. Also checked the RM.

    Not sure if there is something that I can't see that has locked the pin changes for 0,1? Right now this seems to be also affecting progress on Flexcan if they can't be changed.
    Last edited by mjs513; 01-20-2019 at 02:57 PM.

  19. #1044
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    Quote Originally Posted by Frank B View Post
    The exact PLL3 PFD freqs are:

    PFD0: 720000000Hz
    PFD1: 664615384Hz
    PFD2: 508235294Hz
    PFD3: 454736842Hz

    Fix is here - without that the PFDs are not usable due to wrong settings: https://github.com/PaulStoffregen/cores/pull/335
    Morning Frank.
    A while ago I put together a test sketch to check the clock frequencies on startup. I incorporated your changes this morning and remembered I had it so I ran the sketch:
    Code:
    System Clock: 600000000
    IPG Clock: 150000000
    Semc Clock: 200000000
    RTC Clock: 32768
    USB1pll Clock: 480000000
    Peripheral Clock: 24000000
    Osc Clock: 24000000
    Arm Clock: 1200000000
    Usb1PllPfd0 Clock: 720000000
    Usb1PllPfd1 Clock: 664615368
    Usb1PllPfd2 Clock: 508235292
    Usb1PllPfd3 Clock: 454736826
    Usb2Pll Clock: 24000000
    SysPll Clock: 528000000
    SysPllPfd0 Clock: 351999990
    SysPllPfd1 Clock: 594000000
    SysPllPfd2 Clock: 396000000
    SysPllPfd3 Clock: 297000000

  20. #1045
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,117
    PFD1->3 look slightly off

  21. #1046
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,570
    Quote Originally Posted by mjs513 View Post
    REASSIGNING ALT FUNCTIONS TO PINS 0 and 1 NOT WORKING

    @Paul and others,

    In post #996 I was able to reassign the pins (2, 3) to XBAR1 and read encoder values. As a test I tried to that this morning on pins 0 and 1 without any success, nothing being read! I made the pin pad and config changes by substituting 2 ->0 and 3->1, the IO numbers for pins 0,1 are IO16,17. Also checked the RM.

    Not sure if there is something that I can't see that has locked the pin changes for 0,1? Right now this seems to be also affecting progress on Flexcan if they can't be changed.
    I know that with HardwareSerial with Serial1 on those pins, that the RX pin was not the default RX pin for the Uart. In order to get it to read not only did I need to set the Daisy chain register...

    Doing a quick look at the manual, for some other references to those pins in the Select input registers...
    Example if you look at Page 804 (In the newer PDF file)... Sometime would be nice to update page number references in code from the older PDF page numbers to newer PDF page files...

    But you will see: IOMUXC_FLEXCAN2_RX_SELECT_INPUT, so you will see that that signal can be handled by a few different pins:
    Code:
    00 GPIO_EMC_10_ALT3 — Selecting Pad: GPIO_EMC_10 for Mode: ALT3
    01 GPIO_AD_B0_03_ALT0 — Selecting Pad: GPIO_AD_B0_03 for Mode: ALT0
    10 GPIO_AD_B0_15_ALT6 — Selecting Pad: GPIO_AD_B0_15 for Mode: ALT6
    11 GPIO_B1_09_ALT6 — Selecting Pad: GPIO_B1_09 for Mode: ALT6
    So in order to use: pin GPIO_AD_B0_03 for this, it needs to have it's pin set to ALT0 configuration and this register must be set to 1

    Again not sure if this is the pin/signal that you are looking at, but that should hopefully point you toward the right stuff...
    That same pin shows up in other daisy chain registers...
    LPSPI1_SDI_SELECT_INPUT, LPSPI3_PCS0_SELECT_INPUT, LPUART6_RX_SELECT_INPUT, USB_OTG1_OC_SELECT_INPUT,
    IOMUXC_XBAR_INOUT17_SELECT_INPUT

    Kurt

  22. #1047
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,570
    ILI9341_t3n DMA Usage - Update Async

    Made progress - Went back to using LPSPI_TCR_RXMSK

    Was still hanging. Never showed as IDLE. It would output the last WORD, but on the last bit the clock was held high... Finally figured out that maybe it did not like that I had the option: LPSPI_TCR_CONT
    Turned on... When I removed it, things were happier. Than needed to fix a few other issues like, my code to remember what state TCR was in and only if I change it, do I actually update the TCR register. Problem was my mask for which bits did not include the RXMSK so it left that on, which hung me later on.

    So it does not hang, but there still appears to be issues with the DMA memory not properly showing up on the screen...

    If I output the Frame buffer without using DMA, it comes out like:
    Click image for larger version. 

Name:	IMG_0627-(002).jpg 
Views:	18 
Size:	22.2 KB 
ID:	15694

    If I output the same screen using DMA it comes out, but some of it appears to be corrupted slightly...
    Click image for larger version. 

Name:	IMG_0626-(002).jpg 
Views:	33 
Size:	18.2 KB 
ID:	15695

    But getting closer - Note this output was using memory allocated using malloc, with the buffer being allocated on 16 byte alignment.

  23. #1048
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    Morning Kurt
    Thanks for getting back to me. Pretty sure that's what I am doing. This is going to be a little long winded, feels like I am back in college writing a lab report

    XBARA1/ENCODER
    Specifically for my encoder sketch that I know works on pins 2 and 3 where I change the pin assignment to IO6 and IO7 but not on pins 0 and 1 for IO17 and IO16.

    For pin 0, IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03, pg 1817 *(rev2 RM) defines:
    001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1 with the SCION bit to 1
    as
    CORE_PIN0_CONFIG = 0x11 or 0b10001 (I have his bad habit to also check the binary first time through)

    then for the pad config I used CORE_PIN0_PADCONFIG = 0x10B0 (your fastio config works as well on pin2), after that I set IO17 as input:
    IOMUXC_XBAR1_IN17_SELECT_INPUT = 0x01; (see page 2274, daisy chain selection)

    Then of course I have to link the xbar input and output (using Paul's function in pwm.c
    xbar_connect(17, 66);

    All I do for the XBARA1 clock is enable it:
    CCM_CCGR2 |= CCM_CCGR2_XBAR1(CCM_CCGR_ON); //turn clock on for xbara1
    According to the RM, pg 3533
    All sequential functionality is controlled by the Bus Clock.
    Then for pin 1 I follow the same type assignments but still does not work when I run the sketch.

    FLexCAN
    Now FlexCAN, have to do a few things different but pretty similar to what I did for the Encoder module:
    Code:
     
    /* Set clock to use 24Mhz clock with a div by 1, pg 717
     CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(1) | CCM_CSCMR2_CAN_CLK_PODF(0);
    
    
        //rx configure pin for flexcan, pg 1817
        CORE_PIN0_CONFIG = 0x10;        // 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
        IOMUXC_FLEXCAN2_RX_SELECT_INPUT = 0x01;   //01 GPIO_AD_B0_03_ALT0 — Selecting Pad: GPIO_AD_B0_03 for Mode: ALT0, pg 2168
      
        //pin1, can2TX B0_02
        CORE_PIN1_CONFIG = 0x12;
        //uint32_t fastio =  IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);
        CORE_PIN0_PADCONFIG = 0x10B0;
        CORE_PIN1_PADCONFIG = 0x10B0;  // 0x1A081, 0x10B0
    Not really tested flexcan since not sure pins are enabled, tonton81 has a sketch for the testing but the pins just don't seem like they are enabled, that was one reason I was testing with my Encoder sketch.

    Really appreciate the help, because I am stumped, especially with the encoder sketch that I know is working on pins 2/3 but not on pins 0/1.

    Mike

    EDIT: Just saw your DMA post - nice work on getting that far

    EDIT1: You don't think there is a clock conflict? Just a wild thought.

    EDIT2: Just tried the encoder example on pins 6/7, io15/14 and it is working fine. Not sure whats going on with 0 and 1?
    Last edited by mjs513; 01-20-2019 at 07:24 PM.

  24. #1049
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,570
    Hi Mike,

    With your FlexCan/XBar stuff - I am not the best one to answer as I honestly never looked at it

    But wondering about the different Flex can pins and how they work... That is you are setting up the FLEXCAN2_RX_SELECT_INPUT here... Which I can understand when you are using the FLEXCAN2_RX pin...

    But then you say that it works on Pins 2 and 3 Which are EMC_04 and EMC_05, and I don't see any FlexCan pins on these two pins...
    That is the valid internal pins for FLEXCAN2_RX is (GPIO_AD_B0_03, GPIO_EMC_10, GPIO_AD_B0_15, GPIO_B1_09). So not sure how these map?
    Or does the example go through other output paths? Maybe if saw whole example?

    Kurt

    P.S. = Thanks I am making progress with the DMA but pretty slowly

  25. #1050
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,207
    Really appreciate the help, because I am stumped, especially with the encoder sketch that I know is working on pins 2/3 but not on pins 0/1.
    Sorry, think I got you confused the Encoder is working on pins 2/3 not flexcan. Just tested the encoder sketch on pins 6 and 7 and its working there as well, just pins 0 and 1 are giving me a problem. Have two problems with pins 0 and 1. One is the encoder sketch is not working and second flexcan pins don't seem to enabled.

    For flexcan, here is the initialization routine, maybe you'll see something:
    Code:
    FlexCAN_T4 Can1 = FlexCAN_T4(FLEXCAN1_BASE);
    FlexCAN_T4 Can2 = FlexCAN_T4(FLEXCAN2_BASE);
    
    
    FlexCAN_T4::FlexCAN_T4(uint32_t base) {
      _baseAddress = base;
    
      /* Set clock to use 24Mhz clock with a div by 1, pg 717*/
      CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(1) | CCM_CSCMR2_CAN_CLK_PODF(0);
    
        //rx configure pin for flexcan, pg 1817
        CORE_PIN0_CONFIG = 0x10;        // 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
        IOMUXC_FLEXCAN2_RX_SELECT_INPUT = 0x01;   //01 GPIO_AD_B0_03_ALT0 — Selecting Pad: GPIO_AD_B0_03 for Mode: ALT0, pg 2168
      
        //pin1, can2TX B0_02
        CORE_PIN1_CONFIG = 0x12;
        
        //uint32_t fastio =  IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);
        CORE_PIN0_PADCONFIG = 0x10B0;
        CORE_PIN1_PADCONFIG = 0x10B0;  // 0x1A081, 0x10B0
      
      if ( _baseAddress == FLEXCAN1_BASE ) {
        _VectorsRam[16 + IRQ_CAN1] = can1_message_isr;
        NVIC_IRQ = IRQ_CAN1;
        CCM_CCGR0 |= (0xF << 14);
      }
      else if ( _baseAddress == FLEXCAN2_BASE ) {
        _VectorsRam[16 + IRQ_CAN2] = can2_message_isr;
        NVIC_IRQ = IRQ_CAN2;
        CCM_CCGR0 |= (0xF << 18);
      }
      FLEXCANb_CTRL1(_baseAddress) |= FLEXCAN_CTRL_LOM; /* listen only mode enable */
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_FRZ; /* enable freeze bit */
      FLEXCANb_MCR(_baseAddress) &= ~FLEXCAN_MCR_MDIS; /* enable module */
    
      while (FLEXCANb_MCR(_baseAddress) & FLEXCAN_MCR_LPM_ACK);
      softReset(); /* reset bus */
      while (!(FLEXCANb_MCR(_baseAddress) & FLEXCAN_MCR_FRZ_ACK));
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_SRX_DIS; /* Disable self-reception */
    
      disableFIFO();
      disableFIFOInterrupt();
    
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_IRMQ; // individual mailbox masking
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_AEN; // TX ABORT FEATURE
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_LPRIO_EN; // TX PRIORITY FEATURE
      FLEXCANb_MCR(_baseAddress) |= FLEXCAN_MCR_LPRIO_EN; // TX PRIORITY FEATURE
      FLEXCANb_MCR(_baseAddress) &= ~FLEXCAN_MCR_SUPV;
      FLEXCANb_CTRL2(_baseAddress) |= FLEXCAN_CTRL2_RRS | // store remote frames
                                      FLEXCAN_CTRL2_MRP; // mailbox > FIFO priority.
    
      FLEXCANb_MCR(_baseAddress) &= ~FLEXCAN_MCR_HALT; // start the CAN //
    
      while (FLEXCANb_MCR(_baseAddress) & FLEXCAN_MCR_FRZ_ACK);
      while (FLEXCANb_MCR(_baseAddress) & FLEXCAN_MCR_NOT_RDY); // wait until ready /
    
      //setRX(); setTX();
    
      //NVIC_SET_PRIORITY(NVIC_IRQ, 1); // set interrupt priority /
      NVIC_ENABLE_IRQ(NVIC_IRQ); // enable message interrupt /
    
    }
    Thank tonton81 for the flexcan code - I am just working the pin configs since I did the Encoder piece.

    EDIT: If you want to see the Encoder sketch that works on pins 6/7, and 2/3 I just posted it on GitHub, https://github.com/mjs513/WIP

Posting Permissions

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