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

Thread: Got a Teensy 4.1, updated Teensyduino, old working code with ILI9341 DMA broken..

  1. #1

    Got a Teensy 4.1, updated Teensyduino, old working code with ILI9341 DMA broken..

    I have two programs which use code to write to an ILI9341 via DMA. These worked great on my Teensy 4.0 last year. I haven't touched them since.

    I updated Teensyduino to the latest version since I got a 4.1. This code no longer works. I can see via serial debug output that the code is running as it should except that nothing ever displays on the LCD. It never even initialized, it stays white. If I use a more standard ILI9341 library without DMA, the screen works.

    Even if I compile it for my old 4.0, it still doesn't work. Any ideas what might be going on here?

    The display is connected to the hardware SPI ports. CS = 10, DC = 9.

    Here's one of the sketches.

    https://gofile.io/d/O3qSeu

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,764
    KurtE or mjs513 or Paul might have a specific answer. The recent T4 code for the ili9341 with DMA might show something - I haven't followed lately but one of the first two have a github version that has been kept working and improving.
    Since early release the T4 has evolved - USB uses DMA buffers now when it did not at first. There was a recent timing change added. Underlying Clocks may have changed?

  3. #3
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    I use the the ILI9341_t3n only at the moment, it is compatible to the original and works good.
    Havn't tested the ILI9341 the last months...

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,893
    Sorry, I am not sure what is going on. I did take a quick look at your sketch... And it looks like you are not using any of the libraries, but it is doing it's own thing.

    Also could not tell from your description, what version of Arduino and Teensyduino it is/was working on, and which version of Arduino and Teensyduino you are using now. Likewise are you building using Arduino or something else.. And by chance, did you earlier make any modifications to any of the things installed by Teensyduino, which then installing a new version wiped out?

    I believe that @mjs513 did some DMA testing on ILI9341 within the last several days, as per question by @Paul during the last couple beta builds.

    I might try to help you debug some, but I really don't want to go through a sketch with something like 34 files (maybe more). Now if you could condense this down to one or a few files (sketch plus your tft driver cpp, h)... It would make it a lot easier for some of us to help out debug it.

    When I run into this, I usually end up with a simple sketch, that tests out the real basic things, like
    maybe simply fill the screen with a color... Also in cases like this it would help to have some additional information, like when you say DMA broken, it does not tell me much. Do you setup to write individual things at a time to the screen? Or do you setup a logical frame buffer and then tell it to update once? Do you setup to have it continuously update, such that you do one initialization at the start and then it just keeps on running?

    Sorry I know that this answer is not much help.

  5. #5
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    I see.. you're using my old Teensy 3.6 specific ILI9341_dma code.
    This can't work. I've not updated it - was not needed, since Kurt has a solution.

    So use the ILI9341_t3n from Kurt - it can use DMA, too.

  6. #6
    Thanks for the replies.

    Frank - It was working well on the 4.0 back in September. Though, I took the files from the MCUME project so it may have been modified from your version.

    Kurt - Thanks for having a look but based on what Frank said, I'll just try to adapt it to your ILI9341_t3n library next and see how it goes.

  7. #7
    Kurt, I'm having success with your t3n library! Thanks for making it.



    Though I was curious if it's possible to set the update area of the screen before each DMA transfer. That way I could allocate only 64 KB for a framebuffer and update each half of the screen separately at maybe 25 FPS. I need to ideally reclaim some RAM to get my emulator the full 640 KB that it would work best with. Alternatively, I'll need to see if there's some other refactoring I can do elsewhere but I'm short about 40 KB so this framebuffer is obviously the first place to look.

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,764
    Quote Originally Posted by Mike Chambers View Post
    Kurt, I'm having success with your t3n library! Thanks for making it.

    Though I was curious if it's possible to set the update area of the screen before each DMA transfer. That way I could allocate only 64 KB for a framebuffer and update each half of the screen separately at maybe 25 FPS. I need to ideally reclaim some RAM to get my emulator the full 640 KB that it would work best with. Alternatively, I'll need to see if there's some other refactoring I can do elsewhere but I'm short about 40 KB so this framebuffer is obviously the first place to look.
    With a T_4.1 an 8MB PSRAM added might provide a solution to RAM filling?

  9. #9
    That's probably the best solution, you're right. It slipped my mind that we can do that now.

  10. #10
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,893
    It may also depend on how you are defining the frame buffer. Are you allocating your frame buffer yourself or letting it do malloc?

    If you are defining your own, did you set it up to use DMAMEM (the upper 512kb) of memory. If not you might try that. Again I don't know where you are short in memory...

    With the T4.x there are several things you can try.
    a) Move as many constant tables and the like into PROGMEM(so it does not eat up the 512kb associated with DTCM and ITCM. You might look into trying to mark a lot of code, especially any things that are not run often like the init code to be FLASHMEM. Again the 512KB of the main memory is actually something like 16 chunks of 32 kb which each chunk can be data or code. So if your chunk of code > 32 it will grab another chunk... So sometimes to get more data space you need to get stuff out of main code space.

  11. #11
    Quote Originally Posted by KurtE View Post
    It may also depend on how you are defining the frame buffer. Are you allocating your frame buffer yourself or letting it do malloc?

    If you are defining your own, did you set it up to use DMAMEM (the upper 512kb) of memory. If not you might try that. Again I don't know where you are short in memory...

    With the T4.x there are several things you can try.
    a) Move as many constant tables and the like into PROGMEM(so it does not eat up the 512kb associated with DTCM and ITCM. You might look into trying to mark a lot of code, especially any things that are not run often like the init code to be FLASHMEM. Again the 512KB of the main memory is actually something like 16 chunks of 32 kb which each chunk can be data or code. So if your chunk of code > 32 it will grab another chunk... So sometimes to get more data space you need to get stuff out of main code space.
    Thanks, I am indeed already doing most of that. All constant arrays are in PROGMEM and I did put the framebuffer in DMAMEM. The rest of DMAMEM is used by a majority of the emulator RAM array. The PC emulator uses a split memory access scheme between that and a standard memory array to be able to use more than ~512 KB.

    The rest of memory is used up by other arrays for things like video memory, various buffers etc.

    I was not aware of the 32 KB chunk allocation though, that may turn out to be useful! I'll see what that can do for me.

    I did order two PSRAM chips, but I would like to see if I can do it without it. I'd like to put the project on Github at some point, and it would be ideal if users didn't need to buy extra RAM.

    EDIT: After FLASHMEM'ing some infrequently called functions, I got what I needed plus 15 KB left over. Great tip!
    Last edited by Mike Chambers; 05-17-2020 at 11:38 PM.

Posting Permissions

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