Howto use T4.1 Flash to store/retrieve variables

MatrixRat

Well-known member
Midi controller Madness. Devving and works on T3.6. Tested on T4.0 and T4.1.

Need to implement a working relationship between current data structure and non-volatile memory. Shoehorning T4.1 into hardware platform anyway so warming up the solder iron to attach Flash to underside.

Hands up with HowTo store/retrieve variables like this:-

Code:
#define ROWS 4
#define COLS 144

struct JVData {
  uint16_t  Param;        // Could be a Sysex byte, CC# or NRPN#
  uint16_t  CurVal;       // Could be a Sysex byte, CC  or NRPN value
  uint16_t  OldVal;       // Could be a Sysex byte, CC  or NRPN value
  int       MinVal;       // int aimed at slider and encoder values.
  int       MaxVal;       // int aimed at slider and encoder values.
  int       CommandType;  // Proposed 0 = disabled, 1 = Single, 2 = Two byte, 3 = Three byte, and 4 = Four byte messages
  int       ChecksumType; // Proposed 0 = disabled, 1 = Roland type. Others maybe added
  uint16_t  SlideColor;   // Colors are addressed as HSV using three HEX digits. More than adequate for an ILI9431.
  uint16_t  BackColor;    // Just easier to think of a Color and create it with three digits as opposed to wrestling
  uint16_t  HandleColor;  // with 565's packed RGB format. Such is the art of True Laziness.
  bool      DrawColor;
  int       HandleShape;
  int       HandleSize;
  int       TriCursOffset;
  uint16_t  TickColor;
  uint16_t  CursorColor;
  uint16_t  CursorFillColor;
  uint16_t  ValueTextColor;
  uint16_t  ValueTextBackColor;
  char      UpperName[7]; // Constrained on an ILI9431
  uint16_t  UpperNameTextColor;
  uint16_t  UpperNameTextBackColor;
  char      LowerName[7];
  uint16_t  LowerNameTextColor;
  uint16_t  LowerNameTextBackColor;
};
JVData JVData_arr[ROWS][COLS] = {
  {
    {0x01, 0, 0, 0,   1, 1, 1, 0x1FF, 0x085, 0x1FF, true, 1, 10, 0, 0x38F, 0x3FF, 0x0BB, 0x4FF, 0x085, "Tone  ", 0x20F, 0x085, " I/O  ", 0x20F, 0x085}, // Tone Switch

// Around 600 lines removed

    {0x3F, 0, 0, 0, 127, 1, 1, 0x1FF, 0x885, 0x1FF, true, 1, 10, 0, 0x38F, 0x3FF, 0x0BB, 0x4FF, 0x885, " REV  ", 0x20F, 0x885, " SEND ", 0x20F, 0x885},// Reverb Send Level
    {0x26}// Checksum
  }
};

Thanks in advance for any insights.
 
Looking at LittleFS ... Seems like the direction of interest?

Good luck with the Flash attachment - done a few to good effect!
> supported chip
> properly oriented
> fix it in place with one pin, solder the rest, reflow pins as needed, verify no shorts, remove flux

so ~60 byte struct in array of [4][144]? About 8.5 KB?

Create a file and write the data out as needed.

Then as needed open the file and read the data back.

If data is edited the FS will to some degree rotate the data around the Flash space to not wear holes in it.

Not sure any examples do binary write of data, but seems some start like myFile.write( JVData_arr, sizeof( JVData_arr ) );

Might match some of the provided LittleFS examples.
 
Ok, thanks. A 4mm wide strip of sticky copper foil to pick and place the chip. In reality that struct will grow to something more like [16][144] with a tribe of little ones. Then double it again coz the goal is to drive Two JV's.

Now for some chores, solder sizzling and basic testing before hooking it up on a breadboard, sussing out using 74HCT125 for SPI buffers/slew limiters along the way.

Thanks again, will be back in due course.
 
Good luck. Flash use works well - can support multiple files and functions great for static storage.

Extra slack space can appear to use more than expected as the Flash is allocated and written in native page sizes of the chip in use. But not to worry if there are some spare MB's and some couple of files each taking 64 KB.

Just looking and this example writes binary data blocks: {local install}\hardware\teensy\avr\libraries\LittleFS\examples\Write_Speed_Test\Write_Speed_Test.ino. But it is coded for SPI.

This example shows setup for QSPI usage: {local install}\hardware\teensy\avr\libraries\LittleFS\examples\Test_Integrity\QSPI\QSPI.ino
Just need to adjust for NAND versus NOR flash at hand:
#define TEST_QSPI // Typical NOR FLASH
//#define TEST_QSPI_NAND // NAND Flash

For that example the real I/O is in: {local install}\hardware\teensy\avr\libraries\LittleFS\examples\Test_Integrity\QSPI\functions.ino
Then "void bigFile( int doThis )" does a verify and remove or create of data blocks that could be data from the JVData_arr[][]

Starting with the 'Test_Integrity' example will confirm valid chip well soldered, and provide example for code usage.

It was written to verify hardware function so no claim it is 'easy to read or efficient' - but it stresses the system and shows a working chip/library combo.
 
Took a while to flush my stash of Flash out of the rabbithole of relocation.

Bricked the T3.6. last night. Made that struct a [5][144] and missed a corresponding edit to an Index struct and got stuck in a (detected) reboot loop. Screen backlight flashed every second. A delay(1000) is in void setup(). Instant *keyboard faceplant*, realizing I missed that last edit. Recovery attempt failed. No more T3.6 led blinks, screen backlight flash or any sign of heat or smoke.
Code ran straight off the edge of Roadrunner's cliff. Never mind, that board has seen thousands of uploads
 
Took a while to flush my stash of Flash out of the rabbithole of relocation.

Bricked the T3.6. last night. Made that struct a [5][144] and missed a corresponding edit to an Index struct and got stuck in a (detected) reboot loop. Screen backlight flashed every second. A delay(1000) is in void setup(). Instant *keyboard faceplant*, realizing I missed that last edit. Recovery attempt failed. No more T3.6 led blinks, screen backlight flash or any sign of heat or smoke.
Code ran straight off the edge of Roadrunner's cliff. Never mind, that board has seen thousands of uploads

Code shouldn't have a way to brick a Teensy. It can take it off the rails - but the button should bring it back.

Verify compile a simple blink with Teensy unplugged.
While holding the Button down plug the T_3.6 in, wait a sec, release the button.
That should allow the bootloader to start the upload.

If that fails after a time or two, the T_3.6 offers a 15 second Button press Restore of the Factory Blink.
With Teensy powered - computer or even a USB Battery box:
> start a visible timer showing seconds
> press and hold the Button for 15 seconds, and release the Button.
>> there are no blinks or anything during the restore in progress
> The T_3.6 will be set to factory state with Flash wiped in the event some things got mucked up, then pull and program a copy of Factory Blink from reserved flash.
>> The Teensy should then start a factory 1 second Blink, there will be no Serial USB to connect from that small program.
-> if it fails try another couple of times. The Button release window for the Restore process is 13-17 seconds.
 
Good news on several fronts.

Soldering was a little tricky as the chosen T4.1 was already fully pinned. A minor fiddle with LittleFS_Usage yielded Bytes Total:16777216.

Next, other required items surfaced for a less interesting but necessary project whilst looking for Flash, so LittleFs training begins with data logging.

Pleasingly, the T3.6, soldered to a pinned Talldog DIP breakout lives. Had prised it out to rule out any external issue and overlooked the Vin / Usb power switch. Uploading Blink worked so my fried board stats remain Mega,3 and Teensy 0.

Thanks for your support.
 
Congrats. Pin headers do add challenge to the QSPI soldering. @TallDog makes some good stuff - remembering switches better than tossing a good board.
 
Back
Top