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

Status
Not open for further replies.

Mike Chambers

Well-known member
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
 
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?
 
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...
 
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.
 
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.
 
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.
 
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.
 
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?
 
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.
 
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:
More possibilities...

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.

I don't know if this will help (or if you have moved on from this) but I suspect I am getting the same problems as the OP and might have details he missed.

The setup I am trying to startup has the Teensy 4.0 with a "Featherwing" ILI9341 touch display. The Arduino IDE is v1.8.13 and the installation of Teensyduino is 1.53.

I have been getting the problem with the ILI9341 demo files, specifically Demosauce and graphicstest. The screen scrambles while the program runs OK. Most of the time it seems to be running in negative colours and not clearing or refreshing the display properly. The most telling hint is Demosauce which runs the first section (twistytext) fine when I power it up but then it goes bad even past the loop of all of the routines even continuing bad after a button re-set. Disconnect however and twistytext goes OK until the next section.

HERES THE CLUE. If I set the IDE to upload the code to run the Teensy 4.0 at 24 MHz and no higher everything works OK and the test routines run without a hitch.

I hope this isn't irritating. I am assuming that the library examples are based on the library tweaks that you have implemented. Pardon if I am wrong. I haven't been keeping up here lately but now that I am diving into the Teensy 4.1 I thought I might see if I could get this worked out.
 
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.

WOW. Forget all that. I have tried to get this thing to work about 8 times over the past 7 months with the same problems over and over again. The first time I bite the bullet and post a help request and all of a sudden, within minutes the next upload WORKS dammit. Now I bet am going to spend the next frustrating year trying to work out why.
 
Status
Not open for further replies.
Back
Top