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!
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
Last edited by defragster; 06-02-2019 at 12:29 PM.
Re: NXPMotionSense and EEPROM
OK, here is the simplest example. It doesn't have anything to do with CalibrateSensors and MotionCal.
if you build and run this sketch and enter in a character, EEPROM byte 0 is updated for each character you enter. goodCode:#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); } } }
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
Last edited by manitou; 06-03-2019 at 11:55 PM.
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.
Changed code so it won't write the '\n' each time but taking only the first char then eating everything[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'
Code:#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); } } }
Last edited by defragster; 06-02-2019 at 12:38 PM. Reason: Remove .write() and no problem
@defragster, @Paul - I found this on AIRCR for ARM processors, https://mcuoneclipse.com/2015/07/01/...with-software/, will this do the trick?
just not sure what needs to be changedCode: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 */ } }leave that to you defragster.
Last edited by mjs513; 06-02-2019 at 01:37 PM.
@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.
Last edited by mjs513; 06-02-2019 at 02:05 PM.
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:
So if first char is 'd' it will dump (limited to first 256 entries) and raw dump of sector 0 (where entry 0 is)...Code:#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 I run after programming:
Now if I unplug and replug it in...Code: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
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...
@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.
@Paul @mjs513 @manitou and ...
Thought I would try with Serial4 connected to see if anything interesting...
First run after programming...
I was curious if FLEXSPI clock was enabled in CCGR6... But does not look like it is...Code: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
Now to unplug and replug. This time no hang (blinks)...
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...Code: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
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...
Last edited by KurtE; 06-02-2019 at 03:40 PM.
@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.
@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...
Last edited by KurtE; 06-02-2019 at 06:45 PM.
@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?
@mjs513 - So I moved around my digitalWriteFasts...
Code: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
When it was hanging now getting serial output on Serial4: flash_wait timeout 00000048 7772DB4BCode:do { if (loop_count++ > 1000) { __enable_irq(); printf("flash_wait timeout %x %x\n", FLEXSPI_INTR, FLEXSPI_RFDR0); __disable_irq(); break; }
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:
If I run it right after programming:Code: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
Again don't know if it means anything...Code: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
But wonder if the bootloader program, sets something else up. The only other place I find FLEXSPI_ stuff is in the boot data...
Probably all for now, not sure where I would look next other than trying to better understand how FLEXSPI_ interacts here.Code:__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 ...
Last edited by KurtE; 06-02-2019 at 07:34 PM.
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
Last edited by manitou; 06-03-2019 at 04:27 PM.
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.
@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:
it does the flash configuration.Code:SECTIONS { .text.progmem : { KEEP(*(.flashconfig)) FILL(0xFF) . = ORIGIN(FLASH) + 0x1000; KEEP(*(.ivt)) KEEP(*(.bootdata)) KEEP(*(.vectors)) KEEP(*(.startup)) …...
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![]()
Last edited by mjs513; 06-03-2019 at 12:34 AM.
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
@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....
Will look at this later today. A couple highly urgent business things need to be done first.
@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:
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.Code:#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(); } }
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:
If I run it again, by unplugging the board from USB and plug it back in, last run gave me:Code: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
Note: My flash_wait code is hacked up, to keep it from a hard hang:Code: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
Output on Serial4: flash_wait timeout 00000048 7772DF43Code: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); }
The digitalWriteFast calls was where I verified where it was hanging...
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.
FWIW, I used this sketch to examine T4 EEPROM meta data -- sector dump and index table.Code:#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(); } }
Last edited by manitou; 06-06-2019 at 10:15 AM.
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.
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.