Forum Rule: Always post complete source code & details to reproduce any issue!
Page 14 of 18 FirstFirst ... 4 12 13 14 15 16 ... LastLast
Results 326 to 350 of 426

Thread: Teensyduino 1.55 Beta #1

  1. #326
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    538
    Quote Originally Posted by KurtE View Post
    And now for something completely different

    If my sketch crashes and I have
    Code:
      Serial.print(CrashReport);
    The crash report (as well as other stuff early on in next run) shows up in the Serial Monitor window when I use the (not in the build)
    USB type of MTP Disk Serial (Experimental)

    But none of this output shows up with the MTP Disk(Experimental)
    I do finally get some output after the sketch has completed setup:

    Turned out I was going through NULL pointer...

    Setup for this is the starting of new round of: some MTP/MSC stuff that @mjs513 and I have started including adding file dates and times...
    Easy setup - Note will be starting new thread on this as a follow up to my earlier TLA thread.

    Current setup: Arduino 1.8,15 and this beta:
    Update cores: with https://github.com/KurtE/cores/tree/FS_DATES (Added dates/times will have branch FS_Integration)
    update MTP: https://github.com/KurtE/MTP_t4/tree/FS_Integration
    update MSC: https://github.com/KurtE/UsbMscFat/tree/FS_Integration
    Update LittleFS: https://github.com/Mjs513/LittleFS/tree/FS_Integration

    Update: SD: (This is what I forgot) with https://github.com/KurtE/SD/tree/FS_Integration

    run the sketch: https://github.com/KurtE/MTP_t4/blob...MTP-logger.ino
    And then on PC try to expand the Teensy/SD directory... And it called through null ptr to un updated SD Modify date and crashed...

    Easy

    Now back to playing
    Glad to see this. Will update

  2. #327
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,576
    Quote Originally Posted by wwatson View Post
    Glad to see this. Will update
    Will be posting new thread soon!

    Trying to first take care of the strange crash I mentioned in other thread...
    Kept running into this through the earlier code, but never fully tracked it down...

  3. #328
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Update to p#323 and p#325
    added arm_dcache_flush_delete( a1, sizeof( a1 ) ); for the four strings a1,a2,z1,z2 on exit from _isr()
    > that will force it to fully fill cache 'as needed' for each char compare on every entry
    -> Could alternate (after each cycle) char* and uint32* to force 4 byte chunk compare - the repetitive nature of the source string should pass.

    It is still working!

    It takes about 1000% longer per pass with the loss of continuous cache encypted or not here are the TallDog's:
    Code:
    7.1875, 48.33
    10379970 ENC SM: Completed CASCADE Count 4000	Cascading took 10301797 us [1844042038 piCycles] : net 7228394
    Direct calls took 10243064 us [1845954231 piCycles] : net 7166474
    
    Code:
    7.8926, 43.58
    6683800 nor ns: Completed CASCADE Count 4000	Cascading took 9883625 us [1596720292 piCycles] : net 7222425
    Direct calls took 9843493 us [1606557656 piCycles] : net 7165897
    Also added test of those 4 strings to be in encrypted space - and they are PASS on the two ENCrypted units 970 and 960, other of course FAIL.
    Here is 960 Locked SM/ENCrypted start:
    Code:
    Pass: Bus Encryption Engine is active
    Pass: Encryption region starts at proper address
    Pass: Program data is entirely within encrypted region
    Pass: title_function() is within encrypted region
    Pass: title_text[] is within encrypted region
    Pass: a1[] is within encrypted region
    Pass: a2[] is within encrypted region
    Pass: z1[] is within encrypted region
    Pass: z2[] is within encrypted region
    Pass: csf is PJRC
    NOTE: hab_version == 0x40307
    NOTE: hab_status == 0xF0
    Secure mode IS set :: Fuses == 0x4C8B01A
    
    All Tests Passed.  :-)

  4. #329
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Time to restart the IDE:
    Click image for larger version. 

Name:	IDErestart.png 
Views:	19 
Size:	60.5 KB 
ID:	25694

    PENDING POST - I GOT WEDGED


    Since TSET just calls the IDE Builder I suppose it works ... I should try it ...

    >> GOOD WORK @Paul

    TSET under SUBLIME TEXT build WORKS... one caveat not integrated it prompts and holds Serial Open
    >> just escape/close the select Dialog, and Push the Teensy Button or TyComm/Bootloader

    Seems this is the 'normal problem'? I could have TSET "ASK" if 'TyComm integrated' and just skip that step when NOT and it builds
    >> REM lines 89 and 90 where it calls TyCommander in Compile.CMD

    I did see new warnings - Under IDE the 3 INO's collected allowing the new data strings a1,a2,z1,z2 to be seen. From command line I had to share an extern. And a sizeof() for dcache_flush_delete( sz, sizeof( sz ) )) now wanted to know how big each was with a number I didn't include?

    Tried to add DWORD 'pointer cast' of the char code - BIG FAIL : would need custom crafted strings sized to work
    Last edited by defragster; 08-28-2021 at 09:35 PM. Reason: TRIED TSET

  5. #330
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096

    @Paul - something Broke for finding eHex

    Not fixed or working yet.

    After all the following -that did not work- I got it working.
    > Upload Build VerifySecure.ino with ANOTHER Teensy connected in IDE - just a Production T4
    > Power up the LOCKED Beta holding the button and it finally had the needed paths set

    Back in IDE this is the Sketch being built to upload to LOCKED T4_Beta - this is th eIDE Console build path:
    Code:
    "C:\Users\Tim\AppData\Local\Temp\arduino_build_326025\VerifySecure.ino.ehex"
    But IDE is LOCKED - and the "Open HEX File" is Grayed so I cannot even point to that USABLE file.

    Pressing Button does not turn on RED LED, but Teensy Loader does try Upload and fails pointing to a bad file. I just deleted the indicated t:\temp\arduino_build_MakeCode.ino\ directory and it still persists?

    #1> It should be getting proper PATH from the IDE on Build? Not holding a 'broken path' from before with no .eHex.
    #2> If File Open was not grayed out - I could show it a valid .eHex file

    Code:
    > I put the IDE build folder in the expected path with the expected name and it still failed?
    > I went into RegEdit {HKEY_USERS\S-1-5-21-3950958835-4219114207-2426240891-1001\Software\PJRC} and took away the dir and file and Did a new Verify
     --> Now it doesn't even show a path in Verbose and still cannot 'Open HEX File'
    > There is no teensy_loader_cli.exe here - but trying the following with the files in the folder below still fails:
    
    
    T:\Arduino_1.8.15td155\hardware\tools>teensy --mcu=TEENSY40 -w VerifySecure.ino.ehex T:\Arduino_1.8.15td155\hardware\tools>teensy --mcu=TEENSY40 -w VerifySecure.ino.hex
    Directory of T:\Arduino_1.8.15td155\hardware\tools ... 08/17/2021 11:09 AM 4,482,856 teensy.exe ... 08/28/2021 02:43 PM 61,275 VerifySecure.ino.ehex 08/28/2021 02:53 PM 456,868 VerifySecure.ino.elf 08/28/2021 02:53 PM 57,677 VerifySecure.ino.hex
    Doing a 'Verify' Build - because the Beta Teensy is OFFLINE after this failure started.

    This is what IDE shows: { I got stuck like this once before ??? }
    Code:
    Archiving built core (caching) in: C:\Users\Tim\AppData\Local\Temp\arduino_cache_195234\core\core_cde230c268154177edb21ee291c1c116.a
    Linking everything together...
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TT:\\Arduino_1.8.15td155\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025\\sketch\\VerifySecure.ino.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/core\\core.a" "-LC:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025" -larm_cortexM7lfsp_math -lm -lstdc++
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.eep"
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.hex"
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/teensy_secure" encrypthex TEENSY40 "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.hex"
    encrypting 12288 bytes to C:\Users\Tim\AppData\Local\Temp\arduino_build_326025/VerifySecure.ino.ehex
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.lst" "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf"
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.sym" "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf"
    "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/teensy_post_compile" -file=VerifySecure.ino "-path=C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025" "-tools=T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/" -board=TEENSY40
    Teensy Loader is currently busy with another operation (p).  Please try again in a few seconds, or restart Teensy Loader.
    quitexit status 1
    Error compiling for board Teensy 4.0.
    
    Clearing Verbose and building again this is the content from Teensy Loader.
    It seems stuck on THIS file from a failed build under TSET: t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    Code:
    14:40:00.603 (loader): remote connection 1528 opened
    14:40:00.603 (loader): remote cmd from 1528: "comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)"
    14:40:00.603 (loader): remote cmd from 1528: "status"
    14:40:00.608 (post_compile 7): Begin, version=1.55-beta1, high-res time
    14:40:00.615 (post_compile 7): Sending command: comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)
    14:40:00.616 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.666 (loader): remote cmd from 1528: "status"
    14:40:00.668 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.724 (loader): remote cmd from 1528: "status"
    14:40:00.726 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.787 (loader): remote cmd from 1528: "status"
    14:40:00.788 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.850 (loader): remote cmd from 1528: "status"
    14:40:00.851 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.913 (loader): remote cmd from 1528: "status"
    14:40:00.916 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
    14:40:00.974 (post_compile 7): Teensy Loader is currently busy with another operation (p).
    14:40:00.975 (post_compile 7): quit

  6. #331
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    @mjs513 @KurtE - Not seeing the change needed on Builder line? Somehow it doesn't get the updated path to TeensyLoader?
    It worked ONCE because the old path had valid code it was using. Then the path got changed and it wasn't 'right' apparently RE:P#330.

    TSET Works to Verify and Build, creates .hex and .eHex, shows teensy_size.exe - but not to notify Teensy.exe of the new file location?

    Will have to look after Beta two perhaps ...

  7. #332
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,576
    @defragster - right now mostly using Arduino to build... Currently MTP+Serial currently For T4.1...

  8. #333
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,555
    Quote Originally Posted by defragster View Post
    @mjs513 @KurtE - Not seeing the change needed on Builder line? Somehow it doesn't get the updated path to TeensyLoader?
    It worked ONCE because the old path had valid code it was using. Then the path got changed and it wasn't 'right' apparently RE:P#330.

    TSET Works to Verify and Build, creates .hex and .eHex, shows teensy_size.exe - but not to notify Teensy.exe of the new file location?

    Will have to look after Beta two perhaps ...
    I pretty much stick to Arduino IDE but haven't had any issues with loading sketches to the Locked Beta4. Only issue I had was loading code4code onto a single T4. Worked once then had problems. Just uploaded a different sketch and no problem.

    Really have played much with it since the last temp tests. Primarily working with MTP+serial on T4.1 although have tried MTP with the Locked T4 without an issue using an ext SD Card and SPI chip.

  9. #334
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by KurtE View Post
    @defragster - right now mostly using Arduino to build... Currently MTP+Serial currently For T4.1...
    Yes, me too. But crashing the IDE with the 3MB code file made me wonder ... and seems there is a missing trick for TSET use.

    Will do a better study of the CMD lines used - looked the same and resulted in valid Hex's. But then again It has never been perfect using TyComm perhaps and now a new trick is needed.
    Last edited by defragster; 08-28-2021 at 11:51 PM. Reason: EDIT 4,000 func's source is 3MB

  10. #335
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by mjs513 View Post
    I pretty much stick to Arduino IDE but haven't had any issues with loading sketches to the Locked Beta4. Only issue I had was loading code4code onto a single T4. Worked once then had problems. Just uploaded a different sketch and no problem.

    Really have played much with it since the last temp tests. Primarily working with MTP+serial on T4.1 although have tried MTP with the Locked T4 without an issue using an ext SD Card and SPI chip.
    Indeed the IDE is the safe bet and has to be tested. It will need to be workable otherwise - and TSet ideally should - and it does build and Teensy.exe just doesn't know where it seems. Seems to fail getting Teensy_post_compile notice, maybe TyComm interferes? Will have to follow up on the CMDline for that and see about using it.

    Problem I found was locking up the Locked T4 when Teensy.exe got path confusion ( not sure what was wrong the first time I got that ) - but this time took some doing until I found the simple solution, since Teensy 'OPEN' was disabled?

    I tried the initial MTP and it worked. Since I have two TallDog boards I could move to that with builtin SD for testing. Perhaps the other Bet on the PJRC Memory Breakout with the NAND & NOR Flash pairs? That would support an Audio board for SD cardRev D (unless it used p#6 for CS?) too right?

  11. #336
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,555
    Quote Originally Posted by defragster View Post
    Indeed the IDE is the safe bet and has to be tested. It will need to be workable otherwise - and TSet ideally should - and it does build and Teensy.exe just doesn't know where it seems. Seems to fail getting Teensy_post_compile notice, maybe TyComm interferes? Will have to follow up on the CMDline for that and see about using it.

    Problem I found was locking up the Locked T4 when Teensy.exe got path confusion ( not sure what was wrong the first time I got that ) - but this time took some doing until I found the simple solution, since Teensy 'OPEN' was disabled?

    I tried the initial MTP and it worked. Since I have two TallDog boards I could move to that with builtin SD for testing. Perhaps the other Bet on the PJRC Memory Breakout with the NAND & NOR Flash pairs? That would support an Audio board for SD cardRev D (unless it used p#6 for CS?) too right?
    pin 6 is the memory pin cs for the on board flash. At some point will test on the locked T4 but need to workout issues first with know quantity and qspi etc.

  12. #337
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by mjs513 View Post
    pin 6 is the memory pin cs for the on board flash. At some point will test on the locked T4 but need to workout issues first with know quantity and qspi etc.
    Thought it was shared with something - seems the Rev D Audio here seems to have conflicting memory chips on them ...

    But that gives me the Native SDIO SD on the TallDog also two units with USBMsc with one a locked Beta

  13. #338
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    @Paul - loaded a few sketches to T_4.0 on the TallDog breakout with no problem with TD 1.55 Beta.

    Using USB and SDIO socket it provides - One Production and the other Locked Beta unit.

    Just put CR1220 cell's onto them and they hold time and work with TeensyTime3 and @Luni's Time_Clock code with us resolution.

    Same Verify build works to upload to either unit without issue, except the puzzling TWIN LED flashed noted twice.

  14. #339
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Reviewing possible issues, still have this from msg #96 on my list:


    Quote Originally Posted by mjs513 View Post
    However for some reason looks like it is corrupting the directory and file data in LittleFS
    When this was written - only 15 days ago but kinda seems like forever now - I had not yet written this documentation:

    https://www.pjrc.com/teensy/td_code_security.html

    The latest documentation now has a table for maximum LittleFS sizes to be properly retained across code updates. Scroll down to "Minimum Erase Size".

    @mjs513 - Any chance I can talk you into retrying this test with the LittleFS filesystem size of 960K for secure mode or 1472K for normal mode?

    If corruption happens with those sizes, and the program is less than 512K or 1M, the we do indeed have a bug I need to fix. But my hope is the issue was just lack of documentation at the time and attempting sizes larger than the now-documented maximum.

  15. #340
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,555
    @mjs513 - Any chance I can talk you into retrying this test with the LittleFS filesystem size of 960K for secure mode or 1472K for normal mode?
    Will do it right now give me a bit while I remember what I did - seems like forever. But I think once we figure out about the 960 block it wasn't an issue but will try again to confirm.

    Locked T4 with 960blocks of 1024 bytes: Data is retained between restarts or code updates without an issue.
    Code Size:
    Code:
    Memory Usage on Teensy 4.0:
      FLASH: code:78464, data:6900, headers:8840   free for files:1937412
       RAM1: variables:17088, code:73624, padding:24680   free for local variables:408896
       RAM2: variables:12384  free for malloc/new:511904
    Normal T4 with 1472blocks of 1024, same thing Data is retained between restarts or code updates without an issue.

    In neither case am I see any corruption.

    Edit:
    By accident I ran the 1472k on the locked t4 and flue system was corrupted as you would expect.
    The only way to clear the corruption even if I changed to 960k was to do a quick format.
    Last edited by mjs513; 09-02-2021 at 01:08 AM. Reason: Update

  16. #341
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    @Paul - Should the examples/Integrity/RAM/RAM.ino be updated to account for the 'change on boot' region of DMAMEM?

    Something like:
    Code:
    // This declares the LittleFS Media type and gives a text name to Identify in use
    LittleFS_RAM myfs;  // CAN use either RAM1 or RAM2 as available
    #define LFS_BUF_SIZE 390*1024
    //char LFS_BUF[ LFS_BUF_SIZE ];	// BUFFER in RAM1 :: Lost on any Restart/Upload
    void *LFS_BUF = (void*)(0x2027ff00-LFS_BUF_SIZE); // RAM2 Addr :: typically survives Restart/Upload, avoid lower 64KB 0x2020000, upper CrashReport area
    Instead if this sure to break:
    Code:
    //DMAMEM char buf[ 390 * 1024 ];	// DMAMEM Uses RAM2 :: Typically survives Restart/Upload
    Last edited by defragster; 09-02-2021 at 12:49 AM. Reason: RAM not PSRam

  17. #342
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by mjs513 View Post
    In neither case am I see any corruption.
    Ok, going to delete that one from my issues list. Thanks for retesting!

  18. #343
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by defragster View Post
    Something like:
    Let's not put raw addresses into the examples.

    Really not sure how important this is, to demonstrate RAM-based filesystem retained across code updates. But if it is, please do so with a normal array and then don't use the first 32k, probably with a comment in the code that the first 32k of RAM2 can be overwritten during reboot.

    So something like myfs.begin(buf + offset, sizeof(buf) - offset)

  19. #344
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by PaulStoffregen View Post
    Let's not put raw addresses into the examples.

    Really not sure how important this is, to demonstrate RAM-based filesystem retained across code updates. But if it is, please do so with a normal array and then don't use the first 32k, probably with a comment in the code that the first 32k of RAM2 can be overwritten during reboot.

    So something like myfs.begin(buf + offset, sizeof(buf) - offset)
    Indeed the RAW address is UGLY - but prevents WASTE of that 32KB - though it DOES assure that any leftover DMAMEM is blocked form dynamic allocations.

    Was just compilng to test - will rework as noted ...

  20. #345
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Works like this - not real pretty either - adding the #define BUF_OFFSET for the common .begin():
    Code:
    // This declares the LittleFS Media type and gives a text name to Identify in use
    LittleFS_RAM myfs;  // CAN use either RAM1 or RAM2 as available
    #define LFS_BUF_SIZE 390*1024 // Adjust this for the usable desired size, here in KiloBytes
    #define BUF_OFFSET 32768 // 0 // ZERO When using RAM.  Must be 32768 when using DMAMEM to survive warm restart
    //char buf[ LFS_BUF_SIZE ];	// BUFFER in RAM1 :: Lost on any restart
    DMAMEM char buf[ LFS_BUF_SIZE ];	// DMAMEM Uses RAM2 :: Typically survives Restart/Upload
    char szDiskMem[] = "RAM_DISK";
    
    // ... 
    void setup() {
    // ...
    	if (!myfs.begin(&buf[BUF_OFFSET], sizeof(buf)-BUF_OFFSET)) {

  21. #346
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,333
    You could use malloc() and allocate enough memory that the address exceeds the 32kb. - and then free the unused memory. This is also not pretty, but cleaner, and nothing would be wasted.
    And the heap would know about littleFS.

    littleFS could do that itself, too, on create.

  22. #347
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,333
    Code:
    __attribute__((malloc))
    void * allocPersistent(size_t size)
    ...
    code moved here:https://github.com/FrankBoesing/snip...fc5/misc.c#L19
    Last edited by Frank B; 09-02-2021 at 01:16 PM. Reason: add comments, make it interrupt safe

  23. #348
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,555
    @KurtE mentioned that we have been making changes to simplify setting up MTP and adding in things like SD Card Detection as well as file dates and times. I have been testing with a T4.1 since we can then test with PSRAM as well as QSPI flash. On the T4.1 it has been working - did have to do a quick adjust (not much) after the FS update .

    So I decided to see if it would break the Locked T4 - I did not break it and it does work with some caveats for now. Next up testing on a normal T4.
    1. If I have a hub plugged in with a SSD drive and 2 partions, along with a USB Drive with 1 partition and another with 2 partitions MTP doesn't recognize the SSD or the USB drives on startup. Have to plug them into the hub after the MTP starts. Now sure why this is happening or its unique to the Locked T4 but I do know on a T4.1 with the hub plugged in and all drives in the hub MTP recognizes the drive on MTP start.
    2. SD card detect is still a work in progress as @KurtE already mentioned.



    Here is a screen shot of explorer with all the drives/partitions:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	14 
Size:	13.5 KB 
ID:	25748

    See this post for the links to the files and libraries that are affected: https://forum.pjrc.com/threads/67989...l=1#post287150

    @KurtE's MTP fork has a number of updates that the the MTP_T4 does not have - like more events to support the changes. Did I get this right Kurt.

    EDIT: Tracked the problem down and its an issue with my breakout board. On the T4 breakout I have a USB current limit chip on it which I don't have on the T4.1 breakout board. So attached a Powered Hub and all drives came up when MTP started. So no issue with MTP working with a Locked T4.
    Last edited by mjs513; 09-02-2021 at 10:49 AM.

  24. #349
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,555
    Quote Originally Posted by PaulStoffregen View Post
    Ok, going to delete that one from my issues list. Thanks for retesting!
    Not a problem - was watching backyard and front of the house flooding from IDA anyways. Just as a note I started adding the following test to example sketches for T4 and the 960K limit for the locked T4:
    Code:
      // see if the Flash is present and can be initialized:
      // lets check to see if the T4 is setup for security first
      #if ARDUINO_TEENSY40
        if ((IOMUXC_GPR_GPR11 & 0x100) == 0x100) {
          //if security is active max disk size is 960x1024
          Serial.println("SECURITY ENABLED");
          if(file_system_size > 960*1024){
            diskSize = 960*1024;
            Serial.printf("PROGRAM disk defaulted to %u bytes\n", diskSize);  
          } else {
            diskSize = file_system_size;
            Serial.printf("PROGRAM disk using %u bytes\n", diskSize);
          }
        }
      #else
        diskSize = file_system_size;
      #endif
    Should I go ahead and add to the LittleFS example sketch or hold off for now.

  25. #350
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Malloc() works - but like the solution posted in #345 - the address is subject to change between builds.

    The Great thing about the RAW Address is : it is always there - safe ABOVE the 32KB without wasting it for other use and as long as DMAMEM alloc()'s don't push up - it won't be corrupted in use or with a warm restart.

    Also the p#345 is ugly with the secondary #define needed to edit to skip the 32KB - would be cleaner to have that not be in the shared RAM sketch but a separate DMAMEM_RAM example.

    I don't suppose this is any better than the RAW number ? :: extern unsigned long _heap_end;
    > seems I mentioned having a way for having malloc() allocate from that _heap_end point - then it wouldn't crash into it

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •