cpu20

Note that this isn't a solid solution. As also mentioned in this bug report on the ChibiOS forums it is not guaranteed that the FatFS buffers are 32-bit aligned. So in most cases it will work, but if the buffer stretches over two 32-bit lines in memory due to misalignment it could be that things go wrong as only one cache line will be flushed. The most solid solution is to use non-cachable memory.

Can you try replacing the file src/gfile/gfile_fatfs_diskio_chibios.c with the one I provided here and test that? gfile_fatfs_diskio_chibios.c

Tht is normally defined in your HAL config file if I'm not mistaken. Maybe the file isn't corretly included here?

The cache consistency on the STM32f7 platform is a pretty annoying thing to deal with. If the problems described here are caused by the data cache, then it could be that the LTDC is reading invalid data causing the glitching. Making only the framebuffer RAM uncachable will still decrease performance. You could try however to flush the cache before the LTDC starts a DMA transfer. I have no idea if that will kill the performance again or not, but it should also solve the problem.

Great to see that you managed to get everything working! Note that it is never a good idea to modify the library's source files in any way. I know that you sometimes can get it working that way, but you are always doing something fundamentally wrong in your project and that will always lead to problems eventually. The linking of the project is done by the linker script you provided. You don't have to worry about that. Just get gcc to compile everything correctly and you should be good. In your screenshots you first posted I don't see the stm32f7xx_hal_conf.h file. This is necessary for the HAL-libraries to function. Also this way you can exclude unused modules to narrow down the problem and shrink code size. The errors you were seeing are most likely caused by the red, green and blue color conflicts as explained in my previous posts. Why do you get other errors? Well compilers aren't perfect and can give very different errors than the ones that are causing problems. If you have any other problems don't hesitate to ask!!!

The fix I just uploaded is just setting the event timeout to TIME_INFINITE. Else the event timer gives an immediate timeout which isn't caught. That however has nothing to do with the color errors you are getting. The problem you see with the colors is due to the fact that both µGFX and the HAL_drivers use the names red, green and blue for their color naming schemes. Thus they conflict when you try to compile the program. Those conflicts can be fixed by excluding the files in the HAL_driver that use those color names. The conflicting ones, if I remember correctly are the DMA2D driver and the LTDC driver. Normally you'll never need those HAL-drivers when using µGFX so you can simply exclude them from your build. For more details on which files are excluded from build in the example project check the stm32f7xx_hal_conf.h file. (Note that when overwriting the HAL_driver in the project you also loose this file. But you do need this to make the HAL work!) All included drivers are listed there. You don't need many of them to make your program work, so play it safe and exclude everything you don't use. I made another mistake in the example project btw. The stm32f7xx_hal_conf.h file should be located in the inc folder of the project. It is very bad practice to put it in the HAL_driver folders. I will fix that as soon as possible.

It has nothing to do with what type of RAM or which part of the RAM you are using. The MCU will cache any frequently used data from any part of the memory. The easiest way to check if this is the problem, is to invalidate the buffer you are using for the DMA transfer. If this is the problem, you will see the data appearing in your buffer immediately after you invalidate it. Note that the data you see in your debugger is the data the CPU sees and not the data that is currently present in the RAM. So in your debugger you will see the cached memory.

Are you sure you aren't experiencing cache coherency problems as described here? I've ran into this problem several times already on the M7-platform and it's a pain in the *** to debug the problem. But the fact that your data on the screen must update first before you see the DMA transfer happen is probably because the data from the ADC is then removed from cache and replaced with that from the screan. The cpu will look at the data in the RAM directly. Thats what I think happens. But it is probably more complex is the cache is set assosiative.

You are compiling two demos at once in your Makefile: GFXDEMO = modules/gdisp/basics include $(GFXLIB)/demos/modules/gwin/widgets/demo.mk The best way to include the demo is by using GFXDEMO. Most likely the widgets demo is a leftover here you forgot to delete.

Your gfxconf and Makefile look ok. If your program stops at the i2c transfers than it is possible that ChibiOS is not configured correctly. In your halconf do you have conflicting dma channels?

Can you post your makefile and gfxconf file? That way we are sure the problem lies somewhere else.

They clash indeed. If I remember correctly the problems occur in the HAL_LTDC and HAL_DMA2D files. The problem can be solved by putting: #undef Green #undef Red #undef Blue at the top of the conflicting files. I also had to do this in the HAL libraries used in the STM32F7 demo project I uploaded here. You could use that as a reference. Do you have some more info? What board are you using? What display are you using? What demo did you try? Does debugging hang anywhere?

From the CSRC variable remove the main.c line. The demo makefile will include the correct main.c file.

Does the program jump to a hard fault handler? It seems that you are using ChibiOS and in some cases it catches overflows etc and gives an error message of what went wrong. If that is the case that can tell you what is going on. It might be a good idea to look at an example project in the "demos/modules/ginput/keyboard".

That is correct, but after deleting the main.c file you need to adjust your Makefile to use the desired demo project. This is described in the section below the part where it tells you to delete the main.c. If you did set the GFXDEMO as specified in the guide and still get the error, then it is possible that your GFXLIB path may be incorrect.

@malachib got it working according to this thread: Maybe he is willing to help you out with this?

Here are some pictures with two lines, a circle and some text printed on the EPD.

Recently I've gotten this little display. It's my first time working with an e-paper display and I have to say it's really neat how it works! The pas few days I have been busy writing a driver for it. Rotation works, but partial refresh is not implemented yet. The reason for this, is that I have no idea how to do this. Currently the driver uses the draw_pixel method to write every pixel into a frame buffer and then flush everything at once to the display. I have no idea if it would be beneficial to implemented partial refresh and if so how to do it. If anyone could give some more info that would be really helpful! WS29EPD.zip

You should not do this. It will work but altering the ChibiOS source files will give you alot of trouble (same goes for altering the µGFX source files). The proper way of adding the board.c file is adding: SRC = board.c in your Makefile. Yes, the purpose of the debugwrite is to indicate that the thread is working and sleeps correctly every 500/900ms. As mentioned in the main.c you could blink a led as that is far easier than writing to a file. For the errors you must remove the error message from the main.c file because it will always throw the error otherwise.

When using the shift click to select everything under drivers you must make sure to unselect the top folders gdisp and ILI9341 again. If you don't do this, then it indeed looks fine in the project explorer, but everything in the folder is still excluded. It's pretty annoying and maybe I should file a bug report. Good to hear you figured it out! Don't hesitate to ask if you have any other problems or questions!

Seems like you just found the solution for your first problem! The second problem you are having, is that your are using fonts and drawing routines from GDISP without enabling them. To keep code size as small as possible most things in the µGFX library are disabled by default. In your gfxconf.h you should set: #define GDISP_NEED_VALIDATION TRUE #define GDISP_NEED_CLIP TRUE #define GDISP_NEED_TEXT TRUE #define GDISP_INCLUDE_FONT_DEJAVUSANS10 TRUE #define GDISP_INCLUDE_FONT_DEJAVUSANS12 TRUE Normally when you enable all the right components it should compile. I am not sure if I mentioned everything here you need.

I have been struggeling with .s and .S files before in Eclipse (on Linux) because Eclipse only recognizes .s files. At that time I found that according to this thread, that the .S files are first being processed by the preprocessor when using gcc whereas .s is not. But I have no idea what has to be changed in the makefile to adopt for this change...

It was indeed missing the initialization routine. Added it to the demo. Let me know if there is anything else missing!

The repo is ready to be pulled in. I hope I didn't forget anything. Note that I left in the "os_chibios_git.mk" because I changed some things since the first commit. It still doesn't work, but I think it is complete now. The reason the file doesn't work is because ChibiOS switched form .s to .S assembly files for some startup code. This change needs to be handled in the "compiler_gcc.mk" file, but I do not have the knowledge yet to start messing around with that.

Yes of course! My account on the official repo page isn't activated so I can't do a pull request there. For now I've pushed it to GitHub: https://github.com/cpu20/uGFX-fatfs0.13 But it seems like my uGFX copy has a lot of leftover changes (3 other commits) which I must revert first. I'll look into cleaning those up tomorrow so you can easily pull in all needed changes without pulling in any leftover files or anything.