MicroMod Beta Testing

@Paul - @defragster
More on QSPI FLash.

In the beta7 core libraries its dying right after it enters begin:
Code:
LittleFS Test
QSPI flash begin

Code:
	Serial.println("QSPI flash begin");   [COLOR="#FF0000"]<----- prints this and it dies.[/COLOR]

	configured = false;

	uint8_t buf[4] = {0, 0, 0, 0};

	FLEXSPI2_LUTKEY = FLEXSPI_LUTKEY_VALUE;
	FLEXSPI2_LUTCR = FLEXSPI_LUTCR_UNLOCK;
	// cmd index 8 = read ID bytes
	FLEXSPI2_LUT32 = LUT0(CMD_SDR, PINS1, 0x9F) | LUT1(READ_SDR, PINS1, 1);
	FLEXSPI2_LUT33 = 0;

	flexspi2_ip_read(8, 0x00800000, buf, 3);

	Serial.printf("Flash ID: %02X %02X %02X\n", buf[0], buf[1], buf[2]);  [COLOR="#FF0000"] <---- never reaches here[/COLOR]
For Micromod are we using FLEXSPI2?
 
That seems like a problem - MISO should be CIPO, and MOSI COPI, right? Since Master -> Controller and Slave -> Peripheral in the new naming scheme.

Oops my dyslexia is showing - got it backwards
MISO -> CIPO
MOSI -> COPI

Sorry.
 
@defragster
No PSRAM - try switching to DMAMEM. Ran into that as well.

Still can figure out why QSPI Flash isn't working - I can't mess the wiring up on that one.

OK got SPIFlash working - had wiring backwards.
MISO is COPI (12)
MOSI is CIPO (11)
...

Those NEW SPI names will take a bit to 'read' ... forget already what the 'C' stands for ...
>> Great it works on properly wired SPI !

MM.T has QSPI? How?

Working test here with above xxxADD's was:
Code:
//EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove

That had MM.T on Display board just now - hassle to swap it around ... what carrier in use there ?

It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
Code:
EXTMEM char buf[390000];  // USE DTCM for more memory than ITCM allows - or remove
 
Those NEW SPI names will take a bit to 'read' ... forget already what the 'C' stands for ...
>> Great it works on properly wired SPI !

MM.T has QSPI? How?

Working test here with above xxxADD's was:
Code:
//EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove

That had MM.T on Display board just now - hassle to swap it around ... what carrier in use there ?

It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
Code:
EXTMEM char buf[390000];  // USE DTCM for more memory than ITCM allows - or remove

Yep was using the following with the error I posted
Code:
LittleFS_RAM myfs;
// RUNTIME :: extern "C" uint8_t external_psram_size;
//EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove

Damn - I'm dumb that flash chip on the bottom of the board is system flash ? Guess was wishful thinking.

It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
Thanks for reminding me. Now to go and find my Qwiic stuff and get something to eat. Think my blood sugar is getting low.

EDIT: I am using the ATP Carrier board.
 
@Paul - Note: HANGS after UPLOAD when no PSRAM switches to DTCM and requested EXTMEM alloc is too big.
>> Not expecting this is MMOD specific - never tried it on T_4.x

Odd thing is it does not trigger FrankB's HARDFAULT like this does?
Code:
#if 1
  int *badPtr = 0;
  *badPtr = 42;
#endif

If it is over using DTCM shouldn't it be faulting?

From above this runs fine on MM.T with no PSRAM for LFSIntegrity RAM_DISK:
> EXTMEM char buf[390000];

But this HANGS on restart after Upload without triggering a Fault?
> EXTMEM char buf[490000];

for ref:
Code:
Memory Usage on Teensy MicroMod:
  FLASH: code:76360, data:10600, headers:7212   free for files:16420900
   RAM1: [B]code:98304 (70504 used)[/B], variables:21184   free for local variables:404800
   RAM2: variables:502720  free for malloc/new:21568

PS: I can quickly see from above "(70504 used)" I have about 28KB free in ITCM block - so losing ~4KB would save me a block of ITCM ( that was PR#4 in Teensy_Size )
 
Yep was using the following with the error I posted
Code:
LittleFS_RAM myfs;
// RUNTIME :: extern "C" uint8_t external_psram_size;
//EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove

Damn - I'm dumb that flash chip on the bottom of the board is system flash ? Guess was wishful thinking.

Thanks for reminding me. Now to go and find my Qwiic stuff and get something to eat. Think my blood sugar is getting low.

EDIT: I am using the ATP Carrier board.

- Yep I just ate and this was in the middle of that - now have an errand to run ...

But for "T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\LittleFS\src\littlefs\lfs.h" REF :: LFS_ERR_NOSPC = -28, // No space left on device

LFS Integrity could monitor for that "-28" and make the error clearer :(
 
Ok ran the following test on I2C QWIIC connectors and a Sparkfun QWIIC Keypad:
1. SDA - Wire
Code:
Qwiic KeyPad Example
Initialized. Firmware Version: v1.0
Press a button: * to do a space. # to go to next line.
     88888888880009632147 0854
012456789 777775555 00008888555
All good. Keypad found and operational

2. SDA1 - Wire1 (keypad1.begin(Wire1))
Code:
Qwiic KeyPad Example
Keypad does not appear to be connected. Please check wiring. Freezing...]
No good not recognized so SDA1 not equivalent to Wire1.

3. SDA1 - Wire2 (keypad1.begin(Wire2))
Code:
Qwiic KeyPad Example
Initialized. Firmware Version: v1.0
Press a button: * to do a space. # to go to next line.
00088855522233366699

99552211
9966555 88855223366997744331
So SDA1 = Wire2. So do we change this?

Ok - have to test the rest later when I find the rest of my QWIIC stuff. :)

As an update to the above.

4. Wire1 on pins 16/17 work using Wire1, again this is using the QWIIC Keypad as a quick and dirty test.

5. Wire3 on pins 40/41 work:
Code:
Qwiic KeyPad Example
Initialized. Firmware Version: v1.0
Press a button: * to do a space. # to go to next line.
88855522336699999771155


55522211177755566677711
 
Went back to playing with I2C on the MicroMod. I broke out our old I2C test board and wired up the ATP Carrier board to the i2cTestboard:

Hook up
MM Wire -> Teensy Wire
MM SDA1/SCL1 -> Teensy Wire2
MM pins 24/25-> Teensy Wire1
Here is a photo but TMM has my fingers covering it until released by Sparkfun
IMG-0337.png

Bottom line up front:
BNO080 fails on Wire/Wire1/Wire2
LidarLite Fails on Wire1/Wire2


BNO055, MPU9250, MB85, SSD1306 and SHT31 (QWIIC Connector on Wire2) all work without an issue. I also attached the T3.2 to the MM on Wire and it works transferring data (blinking on both the MM and T3.2 using EasyTransferI2C.

ToDo List:
1. Test Wire3 on the MM with those devices
2. Investigate the issues with LidarLite and BNO080.

UPDATE: Put almost everything on Wire3 including BNO080 and LidarLite:
Code:
#define _MPU9250_port Wire3
#define _BNO055_port  Wire3
#define _BNO080_port  Wire3
#define _LIDAR_port   Wire3
#define _MB85_port    Wire3
#define _SHT31_port   Wire3
To my pleasant surprise Lidar and BNO080 both work on Wire3!
Code:
=======================================================
==================  LOOP 100  ==========================
=======================================================
============ MPU9250 =============
MPU9250: 0.208306, 0.232249, -11.042621, -0.000907, 0.000421, 0.000133, 7.516276, 33.024639, -12.204796

============= BNO055 ===============
BNO055: X: 0.19 Y: -2.81 Z: -0.56

============= BNO080 ===========
BNO080: 0.03,-0.01,0.91,0.41,

============= Lidar V3 ==============
LidarLiteV3: 179
LidarLiteV3: 

=========== MB85 =============
MB85 Read Done - array loaded with read data
...... ...... ......
Data: true, 1.3574999571,  314159, 142, 0x50
Data_5: The Quick Brown Fox 

============= SHT31 =============
Temp *C = 27.74, Hum. % = 36.85

============ T32 Slave ===============
Sending Data to T3.2 ====>

UPDATE: 4/2/21 - 0730EST
Ok did some more testing this morning concentrating on the BNO080 and LidarLiteV3.

BNO080 - started working on Wire - Wire1 - sometime still die with the Timeout as we saw before. Have to do more with just a BNO080 off the board to see.
LidarLiteV3 - Working on all Wire ports. Was a sketch issue and not a hardware issue.
 
Last edited:
...
Just ran 15MB Little FS test - write not speedy? - but it works and reads 5X better:
Code:
Start Big write of 2048000 Bytes.........................
Big write /0_2MBfile.txt took  4.11 Sec for 2048000 Bytes : file3.size()=2048000
	[B]Big write KBytes per second 498.90[/B] 

...

Delete with read verify all #bigfile's
	Verify /0_2MBfile.txt bytes 2048000 : ..................................................	GOOD! >>  bytes 2048000
	[B]Big read&compare KBytes per second 2606.02[/B]

<edit>
'R' - Teensy reset data survives, of course
'f' - format unused works quickly without data or integrity loss, of course
'new program' - wipes disk, of course

Ref this "NOT SPEEDY" quote to LittleFS QSPI NAND Flash just posted on the thread - not saying this is the nest compare with larger NAND versus onboard NOR:
Code:
Start Big write of 130920448 Bytes.......
Big write /0_bigfile.txt took 47.47 Sec for 130918400 Bytes : file3.size()=130918400
	[B]Big write KBytes per second 2757.89[/B] 

Delete with read verify all #bigfile's
	Verify /0_bigfile.txt bytes 130918400 : ..................................................	GOOD! >>  bytes 130918400
	[B]Big read&compare KBytes per second 2475.46[/B]

So here is a 7MB T_4.1 PROGRAM memory disk - okay it isn't far off ...:
Code:
Big write /0_bigfile.txt took  6.95 Sec for 3643392 Bytes : file3.size()=3643392
	[B]Big write KBytes per second 524.42 [/B]

Bytes Used: 3661824, Bytes Total:7340032

Delete with read verify all #bigfile's
	Verify /0_bigfile.txt bytes 3643392 : ..................................................	GOOD! >>  bytes 3643392
	[B]Big read&compare KBytes per second 2707.35[/B]
 
Pulled that library and not seeing it work in IDE with p#64 sketch?

Getting various moving errors with attempts to fix :(
...

Sorry, my post #64 was unclear. Currently this is not an Arduino library. The idea is to just copy the two files MicroModT4.h and MicroModT4.cpp into your sketch folder.
I also fixed the 'MM32' bug you've observed and added a mmBus singleton for easier use. Here the current files:

https://github.com/luni64/TeensyHelpers/tree/master/src/MicroMod


And here a hopefully running :) usage example:

Code:
#include "MicroModT4.h"

using namespace MMT;

void setup()
{
     // name mapping MicroMod -> TeensyPins
    pinMode(D0, OUTPUT);                      
    analogWrite(PWM1, 128);
    int vBat = analogRead(BATT_VIN);
    // etc


    // 8bit Bus (G0-G7)
    pinMode(mmBus, OUTPUT);          // set pinMode for entire bus
    mmBus.pinMode(OUTPUT);           // same

    mmBus = 0x12;                    // write 8bit value to bus

    pinMode(mmBus, INPUT_PULLUP);    
    uint8_t val = mmBus;             // read 8bit value from bus

}

void loop()
{
    digitalToggleFast(D0);
    delay(1);
}

In case you want to try it: I'd be interested if the bus thing works.
 
Sorry, my post #64 was unclear. Currently this is not an Arduino library. The idea is to just copy the two files MicroModT4.h and MicroModT4.cpp into your sketch folder.
I also fixed the 'MM32' bug you've observed and added a mmBus singleton for easier use. Here the current files:

https://github.com/luni64/TeensyHelpers/tree/master/src/MicroMod


And here a hopefully running :) usage example:

...
In case you want to try it: I'd be interested if the bus thing works.

Yes, I did copy the files locally - but seeing SRC folder - like the IDE - I unzipped to Libraries and then the IDE saw it. But even the local sketch files were not working right to explain this to the compiler: using namespace MMT;

Not sure what I should see? What's a D0 {constexpr uint8_t D0 = 4; // GPIO9-06} Nothing is blinking or showing?

Oh wait - there it is - found a wired LED - LED blinking - Yes that works.

Not yet read the SFUN Silkscreen - and sorry I tried ... those white inverse tabs do a good job of hiding small RED font with big red background - especially when the cable has the board upside down ... WHERE's the CARD :)
Code:
#include "MicroModT4.h"

using namespace MMT;

void setup()
{
  // name mapping MicroMod -> TeensyPins
  pinMode(D0, OUTPUT);
  analogWrite(PWM1, 128);
  int vBat = analogRead(BATT_VIN);
  // etc

  while (!Serial && millis() < 3000) { }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__ );
  Serial.println(vBat );
  Serial.println(LED_BUILTIN );

  // 8bit Bus (G0-G7)
  pinMode(mmBus, OUTPUT);          // set pinMode for entire bus
  mmBus.pinMode(OUTPUT);           // same

  mmBus = 0x12;                    // write 8bit value to bus

  pinMode(mmBus, INPUT_PULLUP);
  uint8_t val = mmBus;             // read 8bit value from bus
  Serial.println( val, HEX );

}

void loop()
{
  digitalToggleFast(D0);
  delay(1); // much blinkier that (1)
}

Compiles and uploads - only these warnings:
Code:
MMhelpLuni: In function 'void setup()':
MMhelpLuni:10: warning: unused variable 'vBat' 
     int vBat = analogRead(BATT_VIN);
         ^
MMhelpLuni:21: warning: unused variable 'val' 
     uint8_t val = mmBus;             // read 8bit value from bus
             ^

edited code above shows this for output:
Code:
T:\tCode\T4_MM\MMhelpLuni\MMhelpLuni.ino Apr  2 2021 01:19:59
535
13
12

I DID notice when I changed to pin 13 == LED_BUILTIN that the D0 was also DIMly lit ??
 
Not sure what I should see? What's a D0 {constexpr uint8_t D0 = 4; // GPIO9-06}

This just translates the Teensy Pin names to official pin names from the MicroMode spec. You can of course use Teensy Names as well but then you have to look up in a table where they end up on the carrier board (like the one KurtE showed at the beginning of the thread). You find the spec of the micromod connector here: https://www.sparkfun.com/micromod#tech-specs


WHERE's the CARD :)
This https://learn.sparkfun.com/tutorials/micromod-all-the-pins-atp-carrier-board/all#hardware-overview might help (but the image quality is not the best...)

535 for vBat/3 seems wrong. I would have expected something like (battery voltage 3V) -> (3V / 3) / 3.3V * 1024 = 310 counts...

Does the value 0x12 show up on the 8bit bus? (i.e. on G0-G7)?

I DID notice when I changed to pin 13 == LED_BUILTIN that the D0 was also DIMly lit ??
Weird, hard to tell without hardware :-(
 
This just translates the Teensy Pin names to official pin names from the MicroMode spec. You can of course use Teensy Names as well but then you have to look up in a table where they end up on the carrier board (like the one KurtE showed at the beginning of the thread). You find the spec of the micromod connector here: https://www.sparkfun.com/micromod#tech-specs



This https://learn.sparkfun.com/tutorials/micromod-all-the-pins-atp-carrier-board/all#hardware-overview might help

535 for vBat/3 seems wrong. I would have expected something like (battery voltage 3V) (3V / 3) / 3.3V * 1024 = 310 counts...

Does the value 0x12 show up on the 8bit bus? (i.e. on G0-G7)?

Weird, hard to tell without hardware :-(

Sorry - trying to get off this thing for Zzzz's ...

The D0 was a total mystery until I looked in the header ... and then read the silkscreen ... left it to be funny ... because you are mapping to be helpful and it just left me with added :confused: ... because I had to find the right board pin and an LED.

Where's the CARD was also a PLUS to PJRC for sending the physical card for each board that is readable and full of needed info. Thanks for the SFun link - I've seen that - but it isn't a PJRC like CARD :)

I did not test the 8bit bus voltage values - just had time to add printing it ... so it must be there right :) ... will check later when I move the T.MM back to the ATP board.

ONLY having ONE is 'hard' too :) ... :cool:
 
Was curious about which pins hooked up to camera.

The tentative plan for Himax HM01B0 camera support is to use FlexIO2, similar to AN12686. I'll attach the PDF to this message.

Code:
HM01B0 pin      pin#    NXP     Usage
----------      ----    ---     -----
FVLD/VSYNC      33      EMC_07  GPIO
LVLD/HSYNC      32      B0_12   FlexIO2:12
MCLK            7       B1_01   PWM
PCLK            8       B1_00   FlexIO2:16
D0              40      B0_04   FlexIO2:4
D1              41      B0_05   FlexIO2:5
D2              42      B0_06   FlexIO2:6
D3              43      B0_07   FlexIO2:7
D4              44      B0_08   FlexIO2:8  - probably not needed, use 4 bit mode
D5              45      B0_09   FlexIO2:9  - probably not needed, use 4 bit mode
D6              6       B0_10   FlexIO2:10 - probably not needed, use 4 bit mode
D7              9       B0_11   FlexIO2:11 - probably not needed, use 4 bit mode
TRIG            5       EMC_08  ???
INT             29      EMC_31  ???
SCL             19      AD_B1_0 I2C
SDA             18      AD_B1_1 I2C
 

Attachments

  • AN12686.pdf
    437 KB · Views: 786
Are there enough remaining resources to emulate I2S via flexIO? If my questions makes sense.. not sure as there would be no board for cam&audio.. and if there would be one, it had the cam on other pins?
 
It is unfortunate the way Sparkfun connected the microphones.

When(if) the camera is working in 4 bit mode, perhaps we can convince them to make another base board with the camera using only pins 40-45 and connect the I2S pins properly?

Somewhere I have a confidential datasheet with the I2C register info for that camera. I really should dig that up and write a little code to put it into 4 bit mode and turn on MCLK using PWM, so we can start trying to capture the camera data.

The camera also supports a 1 bit mode, which I believe could allow use with only 3 FlexIO pins, 1 PWM pin, 1 GPIO and 2 I2C. But 1 bit mode is limited to slow frame rates. 4 and 8 bit modes allow all speeds, so there's really no advantage to using 8 bit mode.
 
This
Screenshot 2021-04-02 143848.jpg
is probably a typo? Shouldn't it be SPI_COPI1 / SPI_CIPO1? If so, which one is which?
 
@luni
They did that on the SPI_SDO and SPI_SDI pins as well if you look:
Capture.PNG

So
SDO = COPI
SDI = CIPO

I think :)
 
Back
Top