Teensy MicroMod

[defragster]

Interesting - I just made this note somewhere else yesterday?

>> Should there be a DELAY after CrashReport Printing?
Otherwise, the code may get to the Re-Crash before the USB can survive the printing out to the Host!

Need to test if it helps in this case. There was a Crash and the Crash was RECORDED, but the next boot crashed before it could be made 'public'.

Glad to help.

Tim (@defragster):

Thanks for that golden nugget of info !!

...

#include <Wire.h>
#include <DS1307RTC.h>

void setup() {
   unsigned long check_time = millis();

   Serial.begin(9600);
   while (!Serial && ((millis() - check_time) < 3000));

   if (CrashReport) {
      Serial.print(CrashReport);
[B]delay(10000);[/B]
   }
}

void loop() {}

If you simply comment out the "#include <Wire.h>" line, the Teensy MM will boot loop & CrashReport will fail to print anything . . .

...

 

[KurtE]

Note: in the USBHost example USBHost_Viewer, I got it a little more hard core

  if (CrashReport) {
    Serial.print(CrashReport);
    Serial.println("\n *** Press any key to continue ***");
    while (Serial.read() == -1)
      ;
    while (Serial.read() != -1)
      ;
  }

Actually, it was not to be able to see it, it was to avoid continuous resetting and beeps

 

[defragster]

Running the p#76 code with:

   else
      Serial.print(" NO CrashReport");

I see that print when the wire.h is commented? The build shows WIRE being pulled in

Multiple libraries were found for "TimeLib.h"
 Used: C:\T_Drive\tCode\libraries\Time
 Not used: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.1\libraries\Time
Using library DS1307RTC at version 1.4.1 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.1\libraries\DS1307RTC 
Using library Time at version 1.6.1 in folder: C:\T_Drive\tCode\libraries\Time 
Using library Wire at version 1.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.1\libraries\Wire

So not seeing repro to test?

 

[Rezo]

There is some conflicting information between the Sparkfun TMM docs and @KurtE pin mapping document

I'm specifically referring to the SDIO/SPI2 pin mappings.
Per Sparkfun (https://learn.sparkfun.com/tutorials/micromod-teensy-processor-hookup-guide/hardware-overview) these are the correct pin numbers and mappings (and appear to work as expected? will double check)

And per Kurt's document

Seems that MM pins 66, 68 and 70 and incorrectly mapped on @KurtE document.
This has caused much confusion for me and if SF is the correct source, it should be corrected

 

[submo]

There is some conflicting information between the Sparkfun TMM docs and @KurtE pin mapping document

I'm specifically referring to the SDIO/SPI2 pin mappings.
Per Sparkfun (https://learn.sparkfun.com/tutorials/micromod-teensy-processor-hookup-guide/hardware-overview) these are the correct pin numbers and mappings (and appear to work as expected? will double check)
View attachment 38422

And per Kurt's document
View attachment 38423


Seems that MM pins 66, 68 and 70 and incorrectly mapped on @KurtE document.
This has caused much confusion for me and if SF is the correct source, it should be corrected

I was looking at this the other day....

I think Kurt's table is correct.

If you scroll down further on that Spark Fun webpage, there is the larger complete pin out table for the MicroMod connector which does match Kurt's pin out. This also contradicts that SparkFun table that you posted, which I think may be at fault.

It would be nice to get it corrected though, whichever one is at fault.

 

[KurtE]

I can not say for sure, everything on my document is perfect... But have built a few different boards like:

Although this one is simple adding stuff to plug into their ATP board. Including SDIO connector

The one board that I actually made that a MMOD actually plugged into looks like:

Again it has full SDIO connector... Note: I had these partially assembled as to not have to solder those small pins...

 

[Rezo]

After much testing I can confirm that the pin mapping in @KurtE document is correct.
Sparkfun’s SDIO pin specific section has incorrect MM<>T4 pin mapping @Paul FYI