Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: When I use over 50% ram of Teensy 4.0 ... not working and.... can't read usb...

  1. #1

    When I use over 50% ram of Teensy 4.0 ... not working and.... can't read usb...

    (First of all, I'm Korean and My english too bad, so I don't know if i can explain that I want to know.)

    I'm using all teensy version.
    Actually I'm use ram of teensy3.6 to control motor position control (not eeprom).
    anyway.

    I'm use like this (on teensy 3.6).

    short rec_motor_1[15500], unsigned short rec_motor_time_1[15500];
    short rec_motor_2[15500], unsigned short rec_motor_time_2[15500];
    short rec_motor_3[15500], unsigned short rec_motor_time_3[15500];
    short rec_motor_4[15500], unsigned short rec_motor_time_4[15500];

    I can show the ram use % (around 95% use) when I compile.
    Anyway upload and work is good on teensy 3.6.

    But I show the new teensy4.0 at teensy web site, I found out that more RAM is available with teensy4.0. So I bought and test now, but If i use like the (on Teensy 4.0)
    short rec_motor_1[23000], unsigned short rec_motor_time_1[23000];
    short rec_motor_2[23000], unsigned short rec_motor_time_2[23000];
    short rec_motor_3[23000], unsigned short rec_motor_time_3[23000];
    short rec_motor_4[23000], unsigned short rec_motor_time_4[23000];

    I can show the ram use % (around 45% use) when I compile.
    But If I use more ram like this.


    short rec_motor_1[23000], unsigned short rec_motor_time_1[23000];
    short rec_motor_2[23000], unsigned short rec_motor_time_2[23000];
    short rec_motor_3[23000], unsigned short rec_motor_time_3[23000];
    short rec_motor_4[23000], unsigned short rec_motor_time_4[23000];
    short rec_motor_5[23000], unsigned short rec_motor_time_5[23000];
    ....

    I can show the ram use % (around 51% use) when I compile.
    and teensy not working and use device not find on computer.
    If i change the ram use % under 50%, then it works again....

    Can you help me ?? Is there something wrong in my code? in teensy 4.0?

    Thank a lot,
    Best regards,
    Yong.

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,699
    Please see this thread: T4-0-Memory-trying-to-make-sense-of-the-different-regions

    There is 1024 KB of RAM in a T4 - but it is segmented into TWO discrete 512KB areas. Linked thread hopefully supplies needed details.

  3. #3
    Thanks for your help.
    Actually, I found out "DMAMEM" but I have to test more on my project.

    Thanks a lot.

  4. #4
    Senior Member
    Join Date
    May 2015
    Posts
    381
    I’m confused still after reading most of the linked thread. The top half of ram is usable for stuff like larger arrays if logged data?

  5. #5
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    342
    My take on it is that one half is more optimized than the other allowing for faster code execution/memory access, that’s probably wrong on all accounts, but that’s how I choose to understand it right now.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,699
    Quote Originally Posted by DaQue View Post
    I’m confused still after reading most of the linked thread. The top half of ram is usable for stuff like larger arrays if logged data?
    Easy to get confused and harder to get clear answers or full use …

    Hopefully good questions on that thread will evolve good answers for general clarity.

    Teensy 4.0 has two segmented blocks of 512KB where one is usable at compile time - will hold data and code not marked PROGMEM. Code can run from this RAM area, using FASTRUN assures it is place there.

    All addressing is FLAT - one pointer can get anywhere - but there are address jumps/cusps between the two blocks.

    The second 512KB 'other'/DMAMEM block is where the heap and dynamic allocations come from at runtime, code cannot execute from this area.

    And that area has a magic aura of TCM - tightly coupled memory - which relates to cache or access improvements - so it can act funny with DMA access doing unseen updates behind the cache - or doing writes from stale RAM where the cache holds updated info. That AFAIK only affects DMA 'direct memory access' that bypasses the cache which needs to be flushed/purged to prevent those conflicts. But otherwise should be normally usable - just not until runtime …

    Currently AFAIK the Teensy CORE code doesn't rely on any DMA buffer or area in that DMAMEM area - but when USB updates to DMA processing that may change.

    For now the one DOS BOX emulator creator IIRC allocated all of that second DMAMEM 512KB to use as the majority of the 640KB memory space used and it works along with another 128KB from the other area.


    … that summarizes my understanding - not sure it adds anything … and hopefully it is generally valid and complete as far as it goes.

Posting Permissions

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