Forum Rule: Always post complete source code & details to reproduce any issue!
Page 7 of 7 FirstFirst ... 5 6 7
Results 151 to 165 of 165

Thread: T4.0 Memory - trying to make sense of the different regions

  1. #151
    Junior Member
    Join Date
    Feb 2017
    Location
    Chicago, IL
    Posts
    16
    Quote Originally Posted by Frank B View Post
    .. Have fun til next update
    I'm having fun, thanks for this, my sketch now has the headroom it needs (although the IDE still reports way more global variable space usage when I chose FLASH memory vs compiling on the Teensy 3.6).

    One issue, though - when I compile/link my sketch to flash memory using your modified linker above, audio stops working. Switch back to ITCM and it works. I'm using the Audio library and various modules (AudioPlaySdWav, AudioPlayQueue, AudioMixer4, AudioAmplifier, AudioOutputI2S2). No errors returned in my code, just no audio output. In one area my sketch makes a call to playSdWav1.isPlaying() and waits for true to synch other actions to the sound, and it just waits there. This is only when I choose flash; ITCM it all works. Under flash, all my other code - driving TFT, accessing hardwired SD card, etc - seems to be fine. Thanks for your help on this!

  2. #152
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    That's too unspecific..

    I connected an audioshield and tested the Guitar - example: works.
    Can you post a !minimal! example which does not work?

  3. #153

    ITCM spillover?

    Sorry for resurrecting this thread, but I have suddenly found it very interesting.

    My program is randomly dropping sensor readings and copying over variables with strange numbers. I think it might be a memory problem.

    I did a freemem() of it after setup:

    Code:
    ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
    ITCM:   55376 84.50% of   64kB (  10160 Bytes free) (RAM1) FASTRUN
    OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
    FLASH:  67456  3.22% of 2048kB (2029696 Bytes free) FLASHMEM, PROGMEM
    DTCM:
       458752 Bytes (448 kB)
    -   17088 Bytes (16 kB) global variables
    -     104 Bytes (0 kB) stack (currently)
    =========
       441560 Bytes free (431 kB), 17192 Bytes in use (16 kB).
    Size of Free ITCM in Bytes = 10156
    Start of Free ITCM = 55380 [D854] 
    End of Free ITCM = 65536 [10000]
    The ITCM part of RAM1 is close to filling 2 blocks of memory (84.5%) so I tried to reduce it by using FLASHMEM on all functions except loop() and DMAMEM on most non-const variables. This is the result:

    Code:
    ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
    ITCM:   53856 82.18% of   64kB (  11680 Bytes free) (RAM1) FASTRUN
    OCRAM:  23200  4.43% of  512kB ( 501088 Bytes free) (RAM2) DMAMEM, Heap
    FLASH:  69072  3.29% of 2048kB (2028080 Bytes free) FLASHMEM, PROGMEM
    DTCM:
       458752 Bytes (448 kB)
    -   17088 Bytes (16 kB) global variables
    -     104 Bytes (0 kB) stack (currently)
    =========
       441560 Bytes free (431 kB), 17192 Bytes in use (16 kB).
    Size of Free ITCM in Bytes = 11676
    Start of Free ITCM = 53860 [D264] 
    End of Free ITCM = 65536 [10000]
    The number of dropped readings went down, but did not go away altogether, and the variables stopped changing.

    Is it possible that during runtime, the program is overflowing the 64KB of ITCM that has been allocated to it? I am assuming that once this amount has been set, it cannot be changed because other stuff has already been piled on top of it? Can more ITCM be allocated to the FASTRUN code, say another 32KB block? Or might it be best to aim for a program that just spills over the 32KB line, thus reserving 31KB or so for runtime?

    Cheers

  4. #154

    Ignore that last post

    Ignore that last post. I haven't had my morning coffee yet.

    Compiling the program using the 'smallest' option leaves nearly 30KB of ITCM free:

    Code:
    ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
    ITCM:   35952 % of   64kB (  29584 Bytes free) (RAM1) FASTRUN
    OCRAM:  12384 % of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
    FLASH:  45008 % of 2048kB (2052144 Bytes free) FLASHMEM, PROGMEM
    
    DTCM:
       458752 Bytes (448 kB)
    -   12992 Bytes (12 kB) global variables
    -     128 Bytes (0 kB) stack (currently)
    =========
    445632 Bytes free (435 kB), 13120 Bytes in use (12 kB).
    Size of Free ITCM in Bytes = 29580
    Start of Free ITCM = 35956 [8C74] 
    End of Free ITCM = 65536 [10000]
    Readings are still being dropped. Back to the drawing board...

  5. #155
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,890
    Again hard to say why you are losing data, without any clues on what your program is actually doing.
    As mentioned in the first post as well as then the updated data on the PJRC website: https://www.pjrc.com/store/teensy40.html
    The fast memory area of the chip is 512kb of which part is DTCM and part is ITCM. This main memory is comprised of 16 32kb chunks of memory, where each chunk of memory will be marked as either DATA or CODE. How many blocks will be marked as code, depends on how big your program is (rounded up to multiples of 32kb) This does not include the code marked as FLASHMEM which will be run from the slower memory. So if your program is under 32kb it will use 1 of the 16 chunks. If it is >32kb and <64kb it will use 2, likewise if over 64kb and under 96kb 3...

    So with your above: ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
    It is showing that two of the chunks were allocated to ITCM (the two I's in the above)
    And the rest is assigned to be data:

    The 82% is not very interesting or important, other than it is showing you how close you are to needing a 3rd page of code... And there are some hacks one can do to try to use the remaining parts of that chunk for data... Without those hacks, that memory will not be used for anything. Likewise, with the majority of your ITCM (faster) memory will not be used for anything, except what variables you have that go onto the stack (local variables to functions...) Anything that is created by new operations or malloc will go into the heap

    As for dropping readings. There is nothing mentioned in your post on how you are getting these readings. From a serial port? SPI? Wire? ... The one interesting thing with these memory regions and readings is if you are doing something that for example does DMA operations. If these DMA operations are going to or from RAM2 (DMAMEM new/Malloc) area than you have some stuff to deal with. As these areas of memory have a cache setup, and normal operations use the cache and DMA goes to/from the physical memory so if these two are not in sync you get interesting results. That is if your are doing DMA from this memory, you need to make sure the cache memory is written out to the physical memory. And if your operation is using DMA to write out to the physical memory, you need to tell the cache that this area is no longer valid and it needs to fetch the data...

    But again no idea if this is your issue or not.,

  6. #156
    Yes, I understand, the query was intended to be general. Thank you for trying to help anyway. Incidentally, I now think that the problem might be caused by the screen I am using (RA8875), but that needs a different thread.

    My original thought was that if the FASTRUN code was close to filling a whole chunk, say 30KB out of 32KB, or 95KB out of 96KB, could something happen during runtime that might require additional ITCM and cause a spillover? Where might that additional memory come from if the global variables are on top? Or am I doing the compiler a great disservice and it is much cleverer than that?

  7. #157
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,890
    As far as I know, the only thing that writes to ITCM area is the startup code.

    That simply copies the stuff from FLASH memory into the ITCM area, with a really simple copy:
    memory_copy(&_stext, &_stextload, &_etext);

    Which is the same data shown in your debug outputs. Unlike a PC where there are libraries loaded at run time, with the Teensy the linker will place everything in their final positions which the loader simply uses. Hope that makes sense.

    So nothing else uses that extra 2K... Unless you are @defragster who has test code to allow one to claim that memory to put some variables...

    As for RA8875, as you mentioned probably should discuss on a different thread. Either a new one or there are a couple of ones discussing some stuff, that might help, including:
    https://forum.pjrc.com/threads/59563-Teensy-4-0-RA8875
    https://forum.pjrc.com/threads/57280...rom-Buydisplay

  8. #158
    Quote Originally Posted by KurtE View Post
    Hope that makes sense.
    Yes, it does. Very interesting - thank you.

  9. #159
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    172
    Using the code https://forum.pjrc.com/threads/57326...l=1#post227539 #83 in this thread I get the same output for T4.0 and T4.1 Isn't 4.1 supposed to have more flash?

  10. #160
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    That old code does not support the T4.1 - i'll update the post....

  11. #161
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Done....

  12. #162
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    172
    Thanks Frank
    That was FAST !

    thought there might be more to it than just the defines.

    ps. It took me longer to reply than it took you to fix post and reply !

  13. #163
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    172
    Having a little issue:
    Using the new code in #83 it seems to work fine for T4.0 and T4.1 at >150MHz CPU:
    Code:
    @150MHz:
    /var/folders/b9/m7vp5hr925n_3r73_y07979w0000gn/T/arduino_modified_sketch_595702/memory2.ino May 12 2020 18:12:10
    Teensyduino version 1.52
    
    ITCM: 32kB, DTCM: 480kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDDI]
    ITCM:   23200 70.80% of   32kB (   9568 Bytes free) (RAM1) FASTRUN
    OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
    FLASH:  33632  0.41% of 7936kB (8092832 Bytes free) FLASHMEM, PROGMEM
    DTCM:
       491520 Bytes (480 kB)
    -   12992 Bytes (12 kB) global variables
    -      80 Bytes (0 kB) stack (currently)
    =========
       478448 Bytes free (467 kB), 13072 Bytes in use (12 kB).
    but at 24MHz:
    Code:
    @24MHz:
    /var/folders/b9/m7vp5hr925n_3r73_y07979w0000gn/T/arduino_modified_sketch_347420/memory2.ino May 12 2020 18:13:39
    Teensyduino version 1.52
    
    ITCM: 32kB, DTCM: 480kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDDI]
    ITCM:   23200 70.80% of   32kB (   9568 Bytes free) (RAM1) FASTRUN
    OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
    FLASH:  33632  0.41% of 7936kB (8092832 Bytes free) FLASHMEM, PROGMEM
    DTCM:
       491520 Bytes (480 kB)
    -   12992 Bytes (12 kB) global variables
    OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
    �>{����
    J=========
       478448 Bytes free (467 kB), 13072 Bytes in use (12 kB).
    Opitimization setting doesn't seem to matter. The OCRAM line repeats. Maybe there was something about not using USB at this speed? Or a Arduino terminal issue with Mac Catalina only thing?

    Don't seem to have any terminal problems with other programs, even ones with a lot of fast printout.

  14. #164
    Senior Member
    Join Date
    Oct 2015
    Location
    Roma (IT, EU)
    Posts
    336
    Quote Originally Posted by bicycleguy View Post
    Maybe there was something about not using USB at this speed?
    I would exclude this.
    I'm running 4.0 at 24 MHz with USB just fine (Teensyduino 1.52beta4).

  15. #165
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    172
    Has anyone else tried the code posted at #83 https://forum.pjrc.com/threads/57326...l=1#post227539 at 24 MHz? Did you get the results two post above?

    Been trying all sorts of variations of stuffing print statements in and moving code around. It seems to:
    1. work fine at other CPU speeds
    2. work fine if I include the flexRamInfo() function in other code
    3. not work no matter if I add additional print statements in the function or move around the existing statements
    The second to the last time the fmtstr is used like Serial.printf(fmtstr, "OCRAM:", ... it will show up again overwriting the third to last print statement

    4. for some reason print statements using
    const char* fmtstr = "%-6s%7d %5.02f%% of %4dkB (%7d Bytes free) %s\n";
    seem to duplicate
    5. thought it didn't matter before(maybe me) but optimization setting of debug crashes Teensy(short press to reload) and setting of 'smallest code' causes more print errors earlier at any CPU setting.
    Last edited by bicycleguy; 05-13-2020 at 05:51 PM. Reason: added optimization settings

Posting Permissions

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