chrisjn52 Posted March 26, 2016 Report Share Posted March 26, 2016 Hi, I'm trying to debug my ILI9341 driver, (standard peripheral library), and I am getting this message in the console window: Quote Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1217). Workaround: increase "set remotetimeout" in GDB Is this an issue? I am using the Eclipse System Workbench (Ac6) and the code hangs in gdisp.c at the following location: 1058 for(; area; area--) 1059 gdisp_lld_write_color(g); 1060 gdisp_lld_write_stop(g); line 1060 never gets executed. The following link shows how to increase the timeout but in the System Workbench version this option isn't available. http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.cdt.debug.application.doc/reference/cdt_u_gdb_mi.htm I tried changing the Command Timeout (mS) option as shown in the attached image but it didn't help, the code still appeared to hang in the same place after a few hundred write cycles so I am not sure if this is a GDB debugger issue hampering my attempts at debug? Any help appreciated. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted March 26, 2016 Report Share Posted March 26, 2016 I'm afraid we can't help you with your debugging environment. However, we can try to figure out what the problem your driver is. For this, can you please open the driver configuration file (the file /drivers/gdisp/ILI9341/gdisp_lld_config.h) and change the value of GDISP_HARDWARE_STREAM_WRITE from TRUE to FALSE? This will prevent using the streaming interface and therefore not try to execute the code that is making you problems. However, this is of course just a work-around to track down the problem and not a permanent fix/solution. Have you ever been able to use the display with µGFX? Is this a new issue? Can you draw other things? Does it happen directly or just after a couple of minutes? Also: What underlying system are you using? Are you doing other stuff as well or is this a bare, basic project with nothing else but µGFX in it? Link to comment Share on other sites More sharing options...
chrisjn52 Posted March 26, 2016 Author Report Share Posted March 26, 2016 Hi Joel, I see no change to the behaviour when the value of GDISP_HARDWARE_STREAM_WRITE is set to FALSE in /drivers/gdisp/ILI9341/gdisp_lld_config.h . The code is executing gfxInit() in main(), and the vmt->postinit(pd) funtion in gdriver.c executes gdispGClear(gd, GDISP_STARTUP_COLOR) in order to clear the screen. At line 1058 in gdisp.c the code and/or debugger fails after quite a number of SPI writes, (~300), as it tries to clear all 76800 pixels. Running the code without using the debugger does not result in any display and the number of SPI writes appears to be similar in number when viewed on the logic analyser This is a base project, STM32F103C8T6 Bare Metal with no other stuff, and I started the debug process before connection the display to check that all the SPI signals etc. were as required but unfortunately I am unable to track down the problem, possibly because of the debugger issue but probably because I have errors elsewhere. I have attached my board_ILI9341.h file, it's a little untidy as I initially thought this problem was due to a SPI timing issue, (Peripheral clock has also been reduced to 8Mhz). I am currently attempting to read the controller chip to verify it is in fact a ILI9341 device by executing a 0x04 command although I don't believe this is the issue as the Clearscreen function appears not to complete. board_ILI9341.h Link to comment Share on other sites More sharing options...
chrisjn52 Posted March 26, 2016 Author Report Share Posted March 26, 2016 Hi Joel, just in case you are scratching your head and contrary to my last post, I get the following message in the console after a clean and re-compiling.......... #error "GDISP Driver: Either GDISP_HARDWARE_STREAM_WRITE or GDISP_HARDWARE_DRAWPIXEL must be TRUE" Thanks Link to comment Share on other sites More sharing options...
chrisjn52 Posted March 28, 2016 Author Report Share Posted March 28, 2016 To cut a long story short I finally managed to get my display to run a simple demo after chasing many ghosts in an effort to track down what seemed to be an intermittent SPI issue. After many hours of debug that led nowhere I went back to basics and re-read some of the documentation whereupon I surmised that the problem might be due to an unserviced interrupt. The solution, (I am almost too embarrassed to say), was that I had somehow deleted the interrupt handler source file from my project, (probably during the period when I was trying to get the Eclipse System Workbench environment setup to compile). The ILI9341 board file was fine all along and I spent quite awhile with a logic analyser in order to prove that the SPI bus was working as it should, and even then I struggled to convince myself that the problem lay elsewhere. Sometimes it's good to have a few problems, it taught me a lot! Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted March 29, 2016 Report Share Posted March 29, 2016 Sorry for the late reply. We were out of office over Easter. We are glad to hear that you got it working! And we are also glad to hear that it was no problem on the uGFX side of things Enjoy your display! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now