Teensy 4.0 First Beta Test

[PaulStoffregen]

I was asking if there is a sketch way of doing a T4 Software Reset/Restart to get a clean entry to setup() ?

Sure. Use AIRCR, just like on all other 32 bit ARM.

[defragster]

White wire on the latest Ribbon mounted T4B2m? opps - compared - now I see - this was an intermediate PCB put to use with new SDIO pad layout.

Tested USB HOST to ribbon'd SDIO and it works - same as on the POGO pinned B2 breakout.

Tested USB HOST to SSD and HDD - both hitting 12.8 to 13 MB/sec disk writes with 64 KB buffer.

Prior CAN test works using the CAN2 on the CANFD hardware between two T4B2's.

EEPROM's seem to work: Test is always increasing blocks from the Put&Get samples - added 2 MyObject elements. Did them packed and unpacked, and shifted the start offset for the Block placement - That is where the anomaly I have comes in reproduces the same - but intermittent.

Only issue is posted above - on both T4B2 - but easy repro on fresh Ribbon T4B2m with nothing but USB cable. <EDIT> Seems to be like @manitou p#3103!

This is going away. The replacement is one of many little things I meant to do before we started this beta, but didn't finish in time.

To answer the original question, the Arduino IDE creates this for us, so we can always get the compile time even if none of the core library files needed to be recompiled. It does into the final liner command.

For Teensy 4, I'm going to add a bootloader command to set the RTC, and add support in Teensy Loader to always do this as the final step. Then we won't need to depend on Arduino giving this special symbol, and non-Arduino build systems won't have to replicate this special feature. We can also get rid of the complicated startup code that tries to guess if the RTC setting is "fresh" vs "stale". It should also help solve the minor offset between Arduino running the linker and when the code finally boots up and sets the RTC.

Is __rtc_localtime replacement one of the things making it to the next bootloader update?

Timeline planned for new 1.47 beta?

Saw Spot pads on T4 bottom between Labelled Pin Pads - are those Test connects or other?

I found the SCB_AIRCR = ### // request reset

[manitou]

Re: NXPMotionSense and EEPROM

OK, here is the simplest example. It doesn't have anything to do with CalibrateSensors and MotionCal.

#include <EEPROM.h>

void setup() {
  Serial.begin(9600);
  while (!Serial);
  pinMode(13, OUTPUT);
  Serial.printf("byte 0 %d\n", EEPROM.read(0));
}

void loop() {
  uint8_t b;
  if (Serial.available()) {
    b = Serial.read();
    EEPROM.write(0, b);
    Serial.printf("input %d byte 0 %d\n", b, EEPROM.read(0));
    while (!Serial.available()) {
      digitalWrite(13, HIGH);
      delay(200);
      digitalWrite(13, LOW);
      delay(200);
    }

  }
}

if you build and run this sketch and enter in a character, EEPROM byte 0 is updated for each character you enter. good

now unplug T4B2 USB cable and plug it back in. Now when you type a character, EEPROM is no longer updated!?!?

if you push reprogram button, all will work again.

(I was seeing this with MotionCal, because I was building CalibrateSensors on machine different from where I was running MotionCal, and was unplugging T4B2 to switch machines ...)

Tested with T4B2 1.8.8/1.47 beta2 with latest github cores and with IDE serial monitor (no line ending characters). also tested with 1.8.9

[defragster]

Re: NXPMotionSense and EEPROM

OK, here is the simplest example. It doesn't have anything to do with CalibrateSensors and MotionalCal.
...
if you build and run this sketch and enter in a character, EEPROM byte 0 is updated for each character you enter. good

now unplug T4B2 USB cable and plug it back in. Now when you type a character, EEPROM is no longer updated!?!?

if you push reprogram button, all will work again.

(I was seeing this with MagCal, because I was building CalibrateSensors on machine different from where I was running MagCal, and was unplugging T4B2 to switch machines ...)

On the T4B2mRibbon board w/USb connect only - no VBat - Confirmed this looks somewhat like the 'TyComm shows something Odd' and my issue p#3099 - but simpler repro. Also comes back with Button and TyComm GUI Reset.

<edit> If the EEPROM's .read()'s are removed it still hangs, if the .write() is removed it does not have a problem. See code below.

Here is TyComm Full Log - this time 'Teensy Busy on Task' not shown. I think because I paused after first character entered that does not give TimeOut, but the second character entered does give the timeout.

[reset@5889290-Teensy] Resetting board '5889290-Teensy' (Teensy 4.0)
[reset@5889290-Teensy] Sending reset command
Received removal notification for device 'HID\VID_16C0&PID_0478\7&206FFD9D&0&0000'
Remove device 'HID\VID_16C0&PID_0478\7&206FFD9D&0&0000'
Received removal notification for device 'USB\VID_16C0&PID_0478\0008FC81'
Received arrival notification for device 'USB\VID_16C0&PID_0483\5889290'
Examining device node 'USB\VID_16C0&PID_0483\5889290'
Found port number of 'USB\VID_16C0&PID_0483\5889290': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
Add serial device 'USB\VID_16C0&PID_0483\5889290' on iface 0
- USB VID/PID = 16c0:0483, USB location = usb-1-8-7
- USB manufacturer = Teensyduino, product = USB Serial, S/N = 5889290
Identified 'Teensy 4.0' with bcdDevice value 0x279
Received arrival notification for device 'USB\VID_16C0&PID_0483\5889290'
Examining device node 'USB\VID_16C0&PID_0483\5889290'
Found port number of 'USB\VID_16C0&PID_0483\5889290': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
Received removal notification for device 'USB\VID_16C0&PID_0483\5889290'
Remove device 'USB\VID_16C0&PID_0483\5889290'
Received removal notification for device 'USB\VID_16C0&PID_0483\5889290'
Received arrival notification for device 'USB\VID_16C0&PID_0483\5889290'
Examining device node 'USB\VID_16C0&PID_0483\5889290'
Found port number of 'USB\VID_16C0&PID_0483\5889290': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
Add serial device 'USB\VID_16C0&PID_0483\5889290' on iface 0
- USB VID/PID = 16c0:0483, USB location = usb-1-8-7
- USB manufacturer = Teensyduino, product = USB Serial, S/N = 5889290
Identified 'Teensy 4.0' with bcdDevice value 0x279
Received arrival notification for device 'USB\VID_16C0&PID_0483\5889290'
Examining device node 'USB\VID_16C0&PID_0483\5889290'
Found port number of 'USB\VID_16C0&PID_0483\5889290': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
[send@5889290-Teensy] Timed out while writing to '\\.\COM30'

Changed code so it won't write the '\n' each time but taking only the first char then eating everything

#include <EEPROM.h>

void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  pinMode(13, OUTPUT);
  Serial.printf("byte 0 %d\n", EEPROM.read(0));
}

void loop() {
  uint8_t b;
  if (Serial.available()) {
    b = Serial.read();
    EEPROM.write(0, b); // COMMENT this line and the problem does not happen
    Serial.printf("input %d byte 0 %d\n", b, EEPROM.read(0));
    while (Serial.available()) 
    	Serial.read();
    while (!Serial.available()) {
      digitalWrite(13, HIGH);
      delay(200);
      digitalWrite(13, LOW);
      delay(200);
    }

  }
}

[mjs513]

Sure. Use AIRCR, just like on all other 32 bit ARM.

@defragster, @Paul - I found this on AIRCR for ARM processors, https://mcuoneclipse.com/2015/07/01/...with-software/, will this do the trick?

void KIN1_SoftwareReset(void)
{
  /* Generic way to request a reset from software for ARM Cortex */
  /* See https://community.freescale.com/thread/99740
     To write to this register, you must write 0x5FA to the VECTKEY field, otherwise the processor ignores the write.
     SYSRESETREQ will cause a system reset asynchronously, so need to wait afterwards.
   */
#if KIN1_IS_USING_KINETIS_SDK
  SCB_AIRCR = (0x5FA<<SCB_AIRCR_VECTKEY_Pos)|SCB_AIRCR_SYSRESETREQ_Msk;
#else
  SCB_AIRCR = SCB_AIRCR_VECTKEY(0x5FA) | SCB_AIRCR_SYSRESETREQ_MASK;
#endif
  for(;;) {
    /* wait until reset */
  }
}

just not sure what needs to be changed leave that to you defragster.

[mjs513]

Re: NXPMotionSense and EEPROM

OK, here is the simplest example. It doesn't have anything to do with CalibrateSensors and MotionalCal.
…….

if you build and run this sketch and enter in a character, EEPROM byte 0 is updated for each character you enter. good

now unplug T4B2 USB cable and plug it back in. Now when you type a character, EEPROM is no longer updated!?!?

if you push reprogram button, all will work again.

(I was seeing this with MotionCal, because I was building CalibrateSensors on machine different from where I was running MotionCal, and was unplugging T4B2 to switch machines ...)

Tested with T4B2 1.8.8/1.47 beta2 with latest github cores and with IDE serial monitor. also tested with 1.8.9

@manitou - well I just tried your test sketch (T4B2 white wire on top) and am seeing exactly the same problem as you are with the sketch. Very repeatable on seeing the problem.

Did you see my modified calibrate sensors sketch in post #3096. Might help with debugging.

UPDATE: Just tried it with one of my sketches for writing to eeprom from serial, multiple sequential starting at 0, and yes am seeing exactly the same thing.

[KurtE]

With EEPROM issue, thought I would try a combo of app, where you type in like the above apps, and add the dump in from my other app...

So:

#include <EEPROM.h>

void setup() {
  Serial.begin(9600);
  while (!Serial);
  pinMode(13, OUTPUT);
  Serial.printf("byte 0 %d\n", EEPROM.read(0));
}

void loop() {
  uint8_t b;
  if (Serial.available()) {
    b = Serial.read();
    if (b == 'd') {
      dump_eeprom();
    } else {
      EEPROM.write(0, b);
      Serial.printf("input %d byte 0 %d\n", b, EEPROM.read(0));
    }
    while (Serial.available()) {
      Serial.read();
    }
    while (!Serial.available()) {
      digitalWrite(13, HIGH);
      delay(200);
      digitalWrite(13, LOW);
      delay(200);
    }
  }
}

#define FLASH_BASEADDR 0x601F0000
#define FLASH_SECTORS  15

void dump_eeprom() {
  // Lets print out all of the Possible EEPROM values.
  uint16_t eeprom_size = EEPROM.length();
  Serial.printf("EEPROM length: %d\nContents:\n", eeprom_size);

  eeprom_size = 256; // BUGBUG limit for this test.
  for (uint16_t i = 0; i < eeprom_size; i++) {
    Serial.printf("%x:%x ", i, EEPROM.read(i));

    if ((i & 0xf) == 0xf) Serial.println();
  }
  Serial.println("\nRaw Data");

  // Now lets see if we can dump the flash sectors:
  uint32_t sector;
  uint16_t *last_indexes[256];

  for (sector = 0; sector < 1 /*FLASH_SECTORS*/; sector++) {
    for (uint16_t i = 0; i < 256; i++) last_indexes[i] = nullptr;  // out of range...
    const uint16_t *p_start = (uint16_t *)(FLASH_BASEADDR + sector * 4096);
    const uint16_t *p_end = (uint16_t *)(FLASH_BASEADDR + (sector + 1) * 4096);
    uint16_t *p;
    for (p = p_start; p < p_end; p++) {
      if (*p == 0xFFFF) break;
      last_indexes[*p & 0xff] = p;
    }
    Serial.printf("EEprom Page:%d addresses(%lx - %lx): first free: %x\n", sector, p_start, p_end, p);

    uint8_t count = 0;
    for (p = p_start; p < p_end; p++) {
      if (*p == 0xFFFF) break;
      uint8_t value_offset = *p & 0xff;
      uint8_t value = *p >> 8;
      uint16_t eeprom_index = (((value_offset >> 2) * FLASH_SECTORS) << 2) + (sector << 2) + (value_offset & 0x3);
      Serial.printf(" %c%03d(%02x)=%02x", last_indexes[value_offset] == p ? '*' : ' ',
                    eeprom_index, value_offset, value);
      count++;
      if (count == 16) {
        Serial.println();
        count = 0;
      }
    }
    Serial.println();
  }
}

So if first char is 'd' it will dump (limited to first 256 entries) and raw dump of sector 0 (where entry 0 is)...
So if I run after programming:

byte 0 120
input 89 byte 0 89
EEPROM length: 1080
Contents:
0:59 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 

Raw Data
EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f006e
  000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
  240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
 *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
 *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78 *000(00)=59

Now if I unplug and replug it in...
Sometimes it hangs when I try to write, other times it just does not write... The times it did not hang, the raw data is still looking the same as before the reboot...

[mjs513]

@KurtE - @manitou

Just tested with my app version of write from serial and uncommented the debug statements in the eeprom.c. It looks like its getting to the right spots, at least it says it writing but it doesn't appear to be. Never did see where newdata= olddata gets executed or erase then write gets hit though.

[KurtE]

@Paul @mjs513 @manitou and ...

Thought I would try with Serial4 connected to see if anything interesting...
First run after programming...

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 49
input 50 byte 0 50
EEPROM length: 1080
Contents:
0:32 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 

Raw Data
EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f0072
  000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
  240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
 *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
 *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78  000(00)=59  000(00)=31 *000(00)=32

I was curious if FLEXSPI clock was enabled in CCGR6... But does not look like it is...

Now to unplug and replug. This time no hang (blinks)...

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 50
EEPROM length: 1080
Contents:
0:32 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 

Raw Data
EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f0072
  000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
  240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
 *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
 *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78  000(00)=59  000(00)=31 *000(00)=32
input 51 byte 0 50
EEPROM length: 1080
Contents:
0:32 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 

Raw Data
EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f0072
  000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
  240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
 *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
 *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78  000(00)=59  000(00)=31 *000(00)=32

I started this run of with a dump, which showed the same last value for 0=32, tried making it 33, and you can see it read back 32 and the raw dump shows it as 32...

The next run it just hung... Again no new output on Serial4...

Edit: Wondered if maybe some of the FlexSPI registers might be different depending on programmed or boot, so I printed out some:
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40

Did not change between program versus just powerup...

[mjs513]

@KurtE
I have been printing 128 addresses starting at 0 of course and then trying to change not only the first address but I have not seen any hang.

[KurtE]

@mjs513 - Sometimes I see hang other times it just does not do the write...

Will try to localize...

Edit: Put digitalWriteFast calls at start and end of flash_wait and flash_write, when new program loaded it runs fine.

When I unpower the T4 and repower it shows both 7 and 8 staying high so hanging in flash_wait....

Now to figure out which loop...

[mjs513]

@KurtE - Good luck - I had uncommented the debug prints to serial4 and watch what happened as I did the writes from the sketch - didn't see any hangs said it was writing but didn't - maybe its not in eeprom.c but with FlexSPI calls?

[KurtE]

@mjs513 - So I moved around my digitalWriteFasts...

static void flash_wait()
{
	digitalWriteFast(8, HIGH);
	FLEXSPI_LUT60 = LUT0(CMD_SDR, PINS1, 0x05) | LUT1(READ_SDR, PINS1, 1); // 05 = read status
	FLEXSPI_LUT61 = 0;
	uint8_t status;
	do {
		FLEXSPI_IPRXFCR = FLEXSPI_IPRXFCR_CLRIPRXF; // clear rx fifo
		FLEXSPI_IPCR0 = 0;
		FLEXSPI_IPCR1 = FLEXSPI_IPCR1_ISEQID(15) | FLEXSPI_IPCR1_IDATSZ(1);
		FLEXSPI_IPCMD = FLEXSPI_IPCMD_TRG;
		digitalWriteFast(7, HIGH);
		while (!(FLEXSPI_INTR & FLEXSPI_INTR_IPCMDDONE)) {
			asm("nop");
		}
		digitalWriteFast(7, LOW);
		FLEXSPI_INTR = FLEXSPI_INTR_IPCMDDONE;
		status = *(uint8_t *)&FLEXSPI_RFDR0;
	} while (status & 1);
	FLEXSPI_MCR0 |= FLEXSPI_MCR0_SWRESET; // purge stale data from FlexSPI's AHB FIFO
	while (FLEXSPI_MCR0 & FLEXSPI_MCR0_SWRESET) ; // wait
	__enable_irq();
	digitalWriteFast(8, LOW);
}

So it is hanging on the status loop... Will be interesting to print this out... But interrupts disabled... May do loop count down and then exit and
print...

EDIT:

I did a counter if it loops > 1000 times it bails and prints out

	do {

		if (loop_count++ > 1000) {
			__enable_irq();
			printf("flash_wait timeout %x %x\n", FLEXSPI_INTR, FLEXSPI_RFDR0);
			__disable_irq();
			break;
		}

When it was hanging now getting serial output on Serial4: flash_wait timeout 00000048 7772DB4B

So RFDR0 is some large value...

So I updated my printing at start to print out RFDR0 as well, also reprint everything after EEPROM.write is called.

The was hanging one shows:

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 97
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:7772db4b
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:7772db4b
input 98 byte 0 9

If I run it right after programming:

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 97
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:55
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:44
input 99 byte 0 99

Again don't know if it means anything...

But wonder if the bootloader program, sets something else up. The only other place I find FLEXSPI_ stuff is in the boot data...

__attribute__ ((section(".flashconfig"), used))
uint32_t FlexSPI_NOR_Config[128] = {
	// 448 byte common FlexSPI configuration block, 8.6.3.1 page 223 (RT1060 rev 0)
	// MCU_Flashloader_Reference_Manual.pdf, 8.2.1, Table 8-2, page 72-75
	0x42464346,		// Tag				0x00
	0x56010000,		// Version
	0,			// reserved
	0x00020101,		// columnAdressWidth,dataSetupTime,dataHoldTime,readSampleClkSrc

	0x00000000,		// waitTimeCfgCommands,-,deviceModeCfgEnable
...

Probably all for now, not sure where I would look next other than trying to better understand how FLEXSPI_ interacts here.

[manitou]

this is way above my pay grade, but status = *(uint8_t *)&FLEXSPI_RFDR0; seems a strange "status" register, since manual says RFDR0 is 32-bits of data from RX FIFO ???

I have not seen a hang in my experiments.

So a program load (build or push re-program button) is going to write to the flash whereas a cycle-power won't involve a flash write. so EEPROM emulation needs something that reprogramming is doing. Maybe enabling the flash for write is not properly invoked? As Kurt suggests, studying the bootloader actions may be insightful.

NXP SDK has bootloader source

[defragster]

re: EEPROM.write(0, b);

Very odd I didn't see it in my code until I hit PROG Button - I was cutting power and other to interrupt the test more than a few times. Though often I cut 5V not pulling USB cable.

Then @manitou p#3103 simple example triggers it on every cable pull

And in both cases it persists across Zero Power.

>> And the solution whenever "something like this" happens is - to program it takes a Button push.

Thinking WAY back - was it @manitou who returned a beta 1 unit that always required pushbutton to program? But that was ANY code - even simple blink IIRC.

[mjs513]

this is way above my pay grade, but status = *(uint8_t *)&FLEXSPI_RFDR0; seems a strange "status" register, since manual says RFDR0 is 32-bits of data from RX FIFO ???

I have not seen a hang in my experiments.

So a program load (build or push re-program button) is going to write to the flash whereas a cycle-power won't involve a flash write. so EEPROM emulation needs something that reprogramming is doing. As Kurt suggests, studying the bootloader actions may be insightful.

@manitou, @KurtE
Started poking around just because today was one of those days I didn't feel like reading the RM. Always gives me a headache

Anyway looking at boot code (IMXRT1062.LD and bootdata.c) the only thing I saw was that on boot:

SECTIONS
{
	.text.progmem : {
		KEEP(*(.flashconfig))
		FILL(0xFF)
		. = ORIGIN(FLASH) + 0x1000;
		KEEP(*(.ivt))
		KEEP(*(.bootdata))
		KEEP(*(.vectors))
		KEEP(*(.startup)) …...

it does the flash configuration.

When I looked in startup.c and resethandler I didn't see anything that would initialize or configure FLASH. Think @KurtE said all this in one of the previous posts.

Don't know if its needed or not - again you guys (and me) got looking at things I never looked at before. But that's the only difference I am seeing but I can't be sure.

EDIT: Just went back into post #4 to change EEPROM status but see Paul or someone beat me to it and added it to the open issue post

[manitou]

It may not be helpful or relevant but NXP SDK has bootloader source and flexspi flash example.

middleware/mcu-boot/tools/src/bootloader
middleware/mcu-boot/src/bootloader

boards/evkmimxrt1060/driver_examples/flexspi/nor/polling_transfer/

Paul's early thoughts on T4 EEPROM: https://forum.pjrc.com/threads/54711...l=1#post197435

[KurtE]

@manitou @Paul - I reread that thread posting... Looks like a whole can of worms, and will probably need someone (Paul) who understands the inner workings to figure out what is different with the FlexSPI configuration and the like between when the board was freshly programmed and when just powered up....

[PaulStoffregen]

Will look at this later today. A couple highly urgent business things need to be done first.

[KurtE]

@PaullStoffregen - Sounds good, again not sure if any of this data is interesting or not, but test program that I am trying right now is still like ones earlier:

#include <EEPROM.h>

void setup() {
  Serial.begin(9600);
  Serial4.begin(115200);
  pinMode(7, OUTPUT); digitalWrite(7, LOW);
  pinMode(8, OUTPUT); digitalWrite(8, LOW);
  while (!Serial);
  pinMode(13, OUTPUT);
  delay(50);
  Serial.printf("CCM_CCGR6: %x CCM_CCGR7: %x\n", CCM_CCGR6, CCM_CCGR7);
  Serial.printf("byte 0 %d\n", EEPROM.read(0));
  Serial.printf("FLEXSPI MCR0:%x MCR1:%x MCR2:%x AHBCR:%x INTEN:%x INTR:%x RFDR0:%x\n",
                FLEXSPI_MCR0, FLEXSPI_MCR1, FLEXSPI_MCR2, FLEXSPI_AHBCR, FLEXSPI_INTEN, FLEXSPI_INTR, FLEXSPI_RFDR0);
  Serial.printf("    LUT60:%x LUT61:%x LUT62:%x LUT63:%x\n", FLEXSPI_LUT60, FLEXSPI_LUT61, FLEXSPI_LUT62, FLEXSPI_LUT63);
}

void loop() {
  uint8_t b;
  if (Serial.available()) {
    b = Serial.read();
    if (b == 'd') {
      dump_eeprom();
    } else {
      EEPROM.write(0, b);
      Serial.printf("FLEXSPI MCR0:%x MCR1:%x MCR2:%x AHBCR:%x INTEN:%x INTR:%x RFDR0:%x\n",
                    FLEXSPI_MCR0, FLEXSPI_MCR1, FLEXSPI_MCR2, FLEXSPI_AHBCR, FLEXSPI_INTEN, FLEXSPI_INTR, FLEXSPI_RFDR0);
      Serial.printf("    LUT60:%x LUT61:%x LUT62:%x LUT63:%x\n", FLEXSPI_LUT60, FLEXSPI_LUT61, FLEXSPI_LUT62, FLEXSPI_LUT63);
      Serial.printf("input %d byte 0 %d\n", b, EEPROM.read(0));
    }
    while (Serial.available()) {
      Serial.read();
    }
    while (!Serial.available()) {
      digitalWrite(13, HIGH);
      delay(200);
      digitalWrite(13, LOW);
      delay(200);
    }
  }
}

#define FLASH_BASEADDR 0x601F0000
#define FLASH_SECTORS  15

void dump_eeprom() {
  // Lets print out all of the Possible EEPROM values.
  uint16_t eeprom_size = EEPROM.length();
  Serial.printf("EEPROM length: %d\nContents:\n", eeprom_size);

  eeprom_size = 256; // BUGBUG limit for this test.
  for (uint16_t i = 0; i < eeprom_size; i++) {
    Serial.printf("%x:%x ", i, EEPROM.read(i));

    if ((i & 0xf) == 0xf) Serial.println();
  }
  Serial.println("\nRaw Data");

  // Now lets see if we can dump the flash sectors:
  uint32_t sector;
  uint16_t *last_indexes[256];

  for (sector = 0; sector < 1 /*FLASH_SECTORS*/; sector++) {
    for (uint16_t i = 0; i < 256; i++) last_indexes[i] = nullptr;  // out of range...
    const uint16_t *p_start = (uint16_t *)(FLASH_BASEADDR + sector * 4096);
    const uint16_t *p_end = (uint16_t *)(FLASH_BASEADDR + (sector + 1) * 4096);
    const uint16_t *p;
    for (p = p_start; p < p_end; p++) {
      if (*p == 0xFFFF) break;
      last_indexes[*p & 0xff] = p;
    }
    Serial.printf("EEprom Page:%d addresses(%lx - %lx): first free: %x\n", sector, p_start, p_end, p);

    uint8_t count = 0;
    for (p = p_start; p < p_end; p++) {
      if (*p == 0xFFFF) break;
      uint8_t value_offset = *p & 0xff;
      uint8_t value = *p >> 8;
      uint16_t eeprom_index = (((value_offset >> 2) * FLASH_SECTORS) << 2) + (sector << 2) + (value_offset & 0x3);
      Serial.printf(" %c%03d(%02x)=%02x", last_indexes[value_offset] == p ? '*' : ' ',
                    eeprom_index, value_offset, value);
      count++;
      if (count == 16) {
        Serial.println();
        count = 0;
      }
    }
    Serial.println();
  }
}

I am printing out some additional information like what is in LUT60-63 before we call any writes. I also print stuff out after we do any writes.

Any thing you type in to Serial monitor, first char is output to eeprom address 0
Except if it is a 'd' - Then it dumps some of the eeprom and also page 0 in raw data...

If I run this program after the chip is programmed, the last run looked like:

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 99
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:55
    LUT60:2601069f LUT61:0 LUT62:0 LUT63:0
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:44
    LUT60:24010405 LUT61:0 LUT62:0 LUT63:0
input 49 byte 0 49

If I run it again, by unplugging the board from USB and plug it back in, last run gave me:

CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 49
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:7772df43
    LUT60:64bd3240 LUT61:d292adfc LUT62:14f89264 LUT63:65f453b
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:7772df43
    LUT60:24010405 LUT61:0 LUT62:14f89264 LUT63:65f453b
input 50 byte 0 49

Note: My flash_wait code is hacked up, to keep it from a hard hang:

static void flash_wait()
{
	digitalWriteFast(8, HIGH);
	uint16_t loop_count = 0;
	FLEXSPI_LUT60 = LUT0(CMD_SDR, PINS1, 0x05) | LUT1(READ_SDR, PINS1, 1); // 05 = read status
	FLEXSPI_LUT61 = 0;
	uint8_t status;
	do {

		if (loop_count++ > 1000) {
			__enable_irq();
			printf("flash_wait timeout %x %x\n", FLEXSPI_INTR, FLEXSPI_RFDR0);
			__disable_irq();
			break;
		}

		FLEXSPI_IPRXFCR = FLEXSPI_IPRXFCR_CLRIPRXF; // clear rx fifo
		FLEXSPI_IPCR0 = 0;
		FLEXSPI_IPCR1 = FLEXSPI_IPCR1_ISEQID(15) | FLEXSPI_IPCR1_IDATSZ(1);
		FLEXSPI_IPCMD = FLEXSPI_IPCMD_TRG;
		digitalWriteFast(7, HIGH);
		while (!(FLEXSPI_INTR & FLEXSPI_INTR_IPCMDDONE)) {
			asm("nop");
		}
		digitalWriteFast(7, LOW);
		FLEXSPI_INTR = FLEXSPI_INTR_IPCMDDONE;
		status = *(uint8_t *)&FLEXSPI_RFDR0;
	} while (status & 1);
	FLEXSPI_MCR0 |= FLEXSPI_MCR0_SWRESET; // purge stale data from FlexSPI's AHB FIFO
	while (FLEXSPI_MCR0 & FLEXSPI_MCR0_SWRESET) ; // wait
	__enable_irq();
	digitalWriteFast(8, LOW);
}

Output on Serial4: flash_wait timeout 00000048 7772DF43

The digitalWriteFast calls was where I verified where it was hanging...

[defragster]

One EEPROM note is:: I made a couple samples before - and other versions after - manitou posted his nice repro one - and they do not all fail this way. So this example seems to do something unique - like my original ungainly case that does repro.

I get a feeling it is related to USB - but attempts to prove that only show it didn't do it in the ones that worked while still doing EEPROM get/put/write.

All the best to Paul putting the pieces together understanding the 'stored bad state' across power outages that take a button press AND then either [ Upload or TyComm Reset ] to unwind.

[manitou]

One EEPROM note is:: I made a couple samples before - and other versions after - manitou posted his nice repro one - and they do not all fail this way. So this example seems to do something unique - like my original ungainly case that does repro.

I get a feeling it is related to USB - but attempts to prove that only show it didn't do it in the ones that worked while still doing EEPROM get/put/write.

All the best to Paul putting the pieces together understanding the 'stored bad state' across power outages that take a button press AND then either [ Upload or TyComm Reset ] to unwind.

I also had an EEPROM test sketch that made NO use of Serial -- it incremented EERPOM byte 0 every 5 seconds, and flashed the LED the number of times determined by the read of EEPROM byte 0. It also demonstrated that EEPROM updates were not happening after a power cycle. I guess USB could still have some background influence ?, but there was no Serial usage in the sketch.

#include <EEPROM.h>

void setup() {
  pinMode(13, OUTPUT);
}

void loop() {
  static uint8_t b = 1, c;
  static uint32_t ms = millis();
  if (millis() - ms > 5000) {
    EEPROM.write(0, b);
    c = EEPROM.read(0);
    for (int i = 0; i < c; i++) {
      digitalWrite(13, HIGH);
      delay(200);
      digitalWrite(13, LOW);
      delay(400);
    }
    b++;
    ms = millis();
  }
}

FWIW, I used this sketch to examine T4 EEPROM meta data -- sector dump and index table.

[defragster]

I also had an EEPROM test sketch that made NO use of Serial -- it incremented EERPOM byte 0 every 5 seconds, and flashed the LED the number of times determined by the read of EEPROM byte 0. It also demonstrated that EEPROM updates were not happening after a power cycle. I guess USB could still have some background influence ?, but there was no Serial usage in the sketch.

Good info - Indeed that example works as indicated … i.e repro of not working when cable pulled

[PaulStoffregen]

I've committed a fix for the eeprom problems after a cold boot.

https://github.com/PaulStoffregen/co...a2d634ee29c450

The bootloader does indeed fully initialize the FlexSPI LUT memory. Even if a LUT contains a stop instruction, turns out the hardware gets upset if any of LUT's the 8 instructions are invalid, even after a stop. I didn't realize this until now (kind of assumed it didn't read anything after the stop instruction - NXP's manual doesn't really say either way but kind of implied it reads the LUT's instructions in order), so the code was depending on the bootloader leaving the LUTs in a "clean" state. These extra initialization writes should fully solve the problem where the LUT table has unknown garbage after a cold boot.

[defragster]

Looks Good here.

manitou's last test - and the larger sketch I posted before - with or without a button pulling USB the sketch restarts and runs as expected.

ALSO : somehow I'm not seeing that other EEPROM mystery where the struct went out of sync with expected location values.