Teensy 4.0 First Beta Test

[Frank B]

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

 

[KurtE]

Thanks, yep I had a feeling you would say that...

With that I am seeing a 72mhz clock



And my display appears to be working

And for what is worth, the timings show:

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

 

[Frank B]

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 !!

 

[defragster]

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].

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

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

  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>

 

[Frank B]

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/engineering-bulletin/EB790.pdf

 

[defragster]

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.

 

[mjs513]

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:

#define RFM69_IRQ     4    // "C"
#define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )

2. They use a manual reset of the chip:

  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:

#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.

 

[Frank B]

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

 

[defragster]

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.

 

[Frank B]

Tim, read my comment on github re:systick_safe_read ?

 

[defragster]

Tim, read my comment on github re:systick_safe_read ?

Not finding the comment? In the Pull 330 or elsewhere?

 

[Frank B]

this : https://github.com/PaulStoffregen/cores/pull/330#pullrequestreview-193572542

 

[defragster]

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.

 

[mjs513]

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

 

[mjs513]

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:

#define RFM69_IRQ     4    // "C"
#define RFM69_IRQN    digitalPinToInterrupt(RFM69_IRQ )

2. They use a manual reset of the chip:

  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:

#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:

#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.

 

[defragster]

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
...

 

[Frank B]

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

 

[mjs513]

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.

 

[mjs513]

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:

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

 

[tonton81]

PFD1->3 look slightly off

 

[KurtE]

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:

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

 

[KurtE]

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:


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


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

 

[mjs513]

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:

/* 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?

 

[KurtE]

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

 

[mjs513]

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:

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