Project: SPI_MSTransfer

I think it goes back to the post re:SPI timing, notes by Manitou and KurtE. Right now I doing some dumps of F_CPU and F_BUS so I can check the SPI. Also if it is supported in the SPI.cpp. See the post by KurtE.

This is what I have so far:
Code:
F_CPU	168000000
F_BUS	56000000
===================
F_CPU	144000000
F_BUS	48000000
===================
F_CPU	120000000
F_BUS	60000000
===================
F_CPU	96000000
F_BUS	48000000
 
Your code still running here

10:41 --> 12:40

thats 2 hours still running as is :)

1:11, still running strong, 0 errors.

BTW, both M & S running at "Faster" Optimizations
 
Last edited:
Oh, mike, also use a dedicate ground wire between both teensies!
for high speed SPI, this made things stable and been doing this since forever

Dont rely on "common ground", hook a GND point from one directly to the other, it got rid of errors in the past
 
Running faster here too. Right now I slave gnd going to MPU9250 gnd to gnd on the Master. Will switch so slave goes directly to master gnd.

EDIT: Did it - still hung at 168 on both. I am using faster and I did update to 1.41
 
Last edited:
still running here... thats 3 hours and still going, watching netflix here while keeping an eye on the pc scrolling :)
 
Trying a few SPI speeds right now. Has to be something with my set up, because I can't figure out anything else. But its funny only an issue when doing two way on my setup. hate these kind of problems.
 
indeed, its a hardware/wire/signal issue i would think since your sketch is still running as is without errors for over 3 hours
 
Trying a few different bus speeds but just hangs after awhile. Going to rewire when I come home. Will be off line for a while now.
 
does anyone know what priority loop() is running on teensy 3.x? 0-255?
does it run as systick level 0?

It just runs as the primary function in MAIN():

From ...\hardware\teensy\avr\cores\teensy3\main.cpp
Code:
extern "C" int main(void)
{
   // ...
	// Arduino's main() function just calls setup() and loop()....
	setup();
	while (1) {
		loop();
		yield();
	}
}
 
The pain is back. Ok. I soldered up a new 3.5 and put it into my current setup (think I posted a picture earlier), re did all the wiring and did not connect up the GPS or the 9250. Still just hung with no errors on the slave or OT's, both showed 0 when it hung.

Step two took the two breadboard friendly 3.5's and put then on two breadboards next to each other and redid the wiring so I could get a nice clean gnd to gnd with nothing else. Ran both at 168Mhz with SPI at 30Mhz. 20ms on the master and 40 on the slave. Still hung but this time I got an error on the slave:
Code:
58436.00, #, #, #, #, #, #, #, #, #, #, #,10332,0
58448.00, #, #, #, #, #, #, #, #, #, #, #,10333,0
Bad Length: 8191

Ok. I am stumped. The sketches work fine with your setup (3.6 master and 3.5 slave, correct, I think) but I can't get 2 way going reliably on between 2 T3.5's. Yet one way on each works. Going to just try increasing from 40 on the slave to 100ms and see what happens.
 
I bumped SPI ISR to 25 PRIORITY at 2:15PM today, I just got home now (6:20) and its still running

I just added FASTRUN and reuploaded to spi0_isr(), seems i ommitted it at one point, it made the mem usage go from 6% -> 8%, oh well, we wont cry for 2%
gonna let it run :)

Also added FASTRUN to events() for testing since its called the most
 
I noticed something else weird, probably because of a priority

When reflashing the slave, have to push the button to enable it if it was being used with the master, for this i presume its because the SPI priority is set at 1 and the USBSerial is set at 112
The other thing is, I tried to add a print in the slave loop and then disconnect the CS line from the master, the slave doesnt seem to be printing from the slave, tim, know where i should start looking to fix this loop issue?

I'd expected the slave loop to continue printing millis() to serial monitor when i disconnect CS line, but its at a standstill. Reconnecting CS line makes everything come back working including the serial prints?

thats why i asked about loop() priority
 
Only real place to put FASTRUN is on the callback functions. Did that on the slave same behavior. Slave just hangs. Trying now with fastrun on the master and slave callback's. So far its gotten farther than it ever has since I started this. going to see how far it gets - will keep you posted.
 
the sketch callbacks?

ok ill put them as

FASTRUN for both master&slave callbacks
FASTRUN for events()
and FASTRUN for ISR

fun testing :)
 
Worked a little better but hung at 28K on the slave. This is with 20 on the master and 120 on the slave.

If I added fastrun for slave.events, it got upset... :) Guess you have to that in the cpp file. :)

I actually like testing and debugging and figuring out how things work. Just gets frustrating at times when you don't see any progress :)
 
ok false alarm, slave is printing millis() in tight loops on serial monitor when hot plugging the CS line

mike, i also fixed the resends, when i made the function it was in test mode, the actual reassertion and resending wasnt done, thats why u get 4 hits per transaction

fixed now :p

Code:
bool SPI_MSTransfer::command_ack_response(uint16_t *data, uint32_t len) {
  uint8_t resend_count = 0; uint32_t timeout = micros(); uint16_t _crc = 0;
  while ( 1 ) {
    _crc = spi_port->transfer16(0xFFFF);
    if ( _crc == 0xF00D ) {
      spi_port->transfer16(0xBEEF); break;
    }
    else if ( _crc == 0xBAAD ) {
      spi_port->transfer16(0xBEEF); SPI_deassert(); return 0;
    }
    if ( micros() - timeout > 50 ) {
      resend_count++;
[B][COLOR="#FF0000"]      SPI_deassert(); SPI_assert();
      for ( uint16_t i = 0; i < data[1]; i++ ) { spi_port->transfer16(data[i]); }[/COLOR][/B]
      if ( resend_count > 3 ) {
        if ( debugSerial != nullptr ) {
          Serial.print(F("DEBUG: [SLAVE CS ")); Serial.print(chip_select);
          Serial.print(F("] [INFO] FAILED RESENDING ")); Serial.print(resend_count);
          Serial.print(F(" TIMES. TRANSFER ABORTED.")); delay(1000);
        }
[B][COLOR="#FF0000"]        SPI_deassert(); return 0;[/COLOR][/B]
        break;
      }
      if ( debugSerial != nullptr ) {
        Serial.print(F("] [INFO] FAILED RESENDING ")); Serial.print(resend_count);
        Serial.print(F(" TIMES. RETRYING...")); delay(1000);
      }
      timeout = micros();
    }
  }
  return 1;
}

RED == added
 
:) Added the fastrun's in the library - was curious to see what happened. Glad something I am doing is helping :) Just joking.
 
that might actually also explain why yours didnt recover since the last state was left asserted when it hit the next transfer!? woah good catch! :)
 
mike u need to patch the resend function so it deasserts, i think thats a big problem right there if its ever hit, it prevents further processing!
 
I was thinking about that but wasn't sure if that might be the problem. I didn't catch it - you did :)

EDIT: Question. So why was it working so well for you but not for my setup? Just thinking out loud.
 
Back
Top