STM32CubeF7 BSP LCD attempt

Question

I'm trying to display a string on stm32f769i-disco's LED with BSP libraries from STM32CubeF7. However, nothing happens. Here is the code:

#include "stm32f7xx_hal.h"
#include "stm32f769i_discovery.h"
#include "stm32f769i_discovery_lcd.h"
#include "stm32f7xx.h"
#include <stdio.h>

char str[] = "Hello from BSP LCD demo!";

void LCDInit() {
    // Initialize the LCD using the BSP_LCD_Init() function.
    BSP_LCD_Init();

    // Select the LCD layer to be used using the BSP_LCD_SelectLayer() function.
    //BSP_LCD_SelectLayer(0);
    BSP_LCD_LayerDefaultInit(LTDC_DEFAULT_ACTIVE_LAYER, LCD_FB_START_ADDRESS);
    BSP_LCD_SelectLayer(LTDC_DEFAULT_ACTIVE_LAYER);

    // Enable the LCD display using the BSP_LCD_DisplayOn() function.
    BSP_LCD_DisplayOn();

    // Clear the whole LCD using BSP_LCD_Clear() function or only one specified string line using the BSP_LCD_ClearStringLine() function.
    BSP_LCD_Clear(LCD_COLOR_LIGHTGRAY);
    HAL_Delay(1000);

    BSP_LCD_SetBackColor(LCD_COLOR_LIGHTGRAY);
    BSP_LCD_SetTextColor(LCD_COLOR_WHITE);

    // Display a character on the specified line and column using the BSP_LCD_DisplayChar() function or a complete string line using the BSP_LCD_DisplayStringAtLine() function.
    BSP_LCD_DisplayStringAt(100, 100, str, CENTER_MODE);
}

int main(void) {
    LCDInit();
    BSP_LED_Init(LED_GREEN);

    while(1) {
        for (int i=0;i<1000000;i++);
        BSP_LED_Toggle(LED_GREEN);
    }

    return 0;
}

If I remove the call to LCDInit, my LED toggles, if I call the LCDInit, nothing happens (the LED doesn't toggle) and the LCD stays black. Any ideas?

I've basically tried following the instructions in stm32f769i_discovery_lcd.c, without luck:

2. Driver description:
---------------------
  + Initialization steps:
     o Initialize the LCD using the BSP_LCD_Init() function.
     o Select the LCD layer to be used using the BSP_LCD_SelectLayer() function.
     o Enable the LCD display using the BSP_LCD_DisplayOn() function.

  + Options
     o Configure and enable the color keying functionality using the
       BSP_LCD_SetColorKeying() function.
     o Modify in the fly the transparency and/or the frame buffer address
       using the following functions:
       - BSP_LCD_SetTransparency()
       - BSP_LCD_SetLayerAddress()

  + Display on LCD
     o Clear the whole LCD using BSP_LCD_Clear() function or only one specified string
       line using the BSP_LCD_ClearStringLine() function.
     o Display a character on the specified line and column using the BSP_LCD_DisplayChar()
       function or a complete string line using the BSP_LCD_DisplayStringAtLine() function.
     o Display a string line on the specified position (x,y in pixel) and align mode
       using the BSP_LCD_DisplayStringAtLine() function.
     o Draw and fill a basic shapes (dot, line, rectangle, circle, ellipse, .. bitmap)
       on LCD using the available set of functions.

EDIT: When debugging with OpenOCD, gdb hangs if I set the breakpoint at the BSP_LCD_Init() line. If I run the debugger again, I can see the program is stuck at the WWDG_IRQHandler ().

'Any ideas?' sure. 'LCDInit' does not return. Debugger, step though LCDInit(). — Martin James, Jul 29 '17 at 10:34
If you have no debugger, (you're stuft, overall), but you could put the LED toggle in a function, then call it in the middle of LCDInit(). If it toggles, move the toggle call down, if it does not toggle, move it up, in the manner of a binary chop. Soon, you will know which line fails. This is how you debug stuff - you have to be creative with what you have and, if you don't have a JTAG debugger, or the like, get one now. — Martin James, Jul 29 '17 at 10:39
@MartinJames did you Google the OPs board? It has the debugger on board. No additional hardware needed. — 0___________, Jul 29 '17 at 10:47
@PeterJ no, I did not. Since the OP did not use a debugger to isolate the problem, I assumed they did not have one. Now they get a downvote for not using the tools avaiiable to them:( — Martin James, Jul 29 '17 at 10:49
You need to make the buffer visible. It is done by transfering the content of the buffer to the LCD. Find the proper function. You write and draw in the boards RAM. Then you need to transfer the drawn frame to the display. — 0___________, Jul 29 '17 at 10:52
My guess is that 'BSP_LCD_Init();' is looping internally but, not having access to the hardware or debugger, we don't know anything for sure. For all we know, it may have shot off to some abort loop after a hardware exception:( — Martin James, Jul 29 '17 at 10:53
@MartinJames It cannot be done automatically as the hardware does not know when you finish drawing the frame. This uC has a very decent LCD interfaces (DMA2D, LCD). I just do not remember the function names from the examples. — 0___________, Jul 29 '17 at 11:04
@MartinJames Setting up the debugger on my windows 10 machine has turned out to be a task I really don't know how to achieve as I have tried st-util, Atollic gdb-server, OpenOCD and not a single one of them worked - for example OpenOCD is throwing this error: Info : accepting 'telnet' connection on tcp/4444 Error: error during read: Bad file descriptor Info : dropped 'telnet' connection (error -400) & while st-util doesn't even recognize my board, so the only thing that works for me is flashing the board via st-link_cli from stmicroelectronics. — xtrinch, Jul 30 '17 at 08:52
@PeterJ so are the BSP instructions on how to set up the LED just way off? Because I would assume that bsp_led_init would take care of that.. — xtrinch, Jul 30 '17 at 08:55
@MartinJames I understand the downvote, I suppose I should have phrased my question on how to setup the debugging environment — xtrinch, Jul 30 '17 at 08:58
ST-link works almost always out of the box. Never had any problems. — 0___________, Jul 30 '17 at 09:03
Why attolic? It is just eclipse + some plugins. Better install openSTM32 as you use STM micros, boards and debug probe. Same eclipse - just another plugins - but you do need to configure anything. When you get more experience - use anything you wish. Hardware debugging is essential in the uC programming — 0___________, Jul 30 '17 at 09:08
@PeterJ Atollic because it has st-link_gdbserver cli tool, not for the IDE — xtrinch, Jul 30 '17 at 09:12
But it does not work for you. So what is the point? Install openSTM32 and start from there. — 0___________, Jul 30 '17 at 09:14
@PeterJ I will give it a try & already downlading it, although I was really hoping to achieve this with command line tools, I always get a little lost when using an IDE until I understand what's happening in the background (at least a little bit) — xtrinch, Jul 30 '17 at 09:17
From command line? What for? To make your life more difficult? IDEs are for the programmer convenience and productivity. Low level command line gdb or OpenOCD communication you can learn when you have more experience, and you are sure that everything works ok. — 0___________, Jul 30 '17 at 09:22
@PeterJ I love IDE's for code completion, but as a build tool I always preferred the command line, so much easier to set up once you understand it, and you don't get stuck at 0x4356ffff unknown error that the IDE makers didn't really bother to document, and it adds another layer of 'things to understand' when you're dealing with something new.. I could be completely off, that was just my experience so far — xtrinch, Jul 30 '17 at 09:31
@Nirri please stop. There is no difference in the error messaging in the IDE like Eclipse and command line, as Eclipse plugins just call and interpret the same command line utilities. You have it all in the terminal windows. Eclipse is just the text editor, debugger front end + framework for calling external tools like compilers, debuggers etc. and writing own automation plugins — 0___________, Jul 30 '17 at 09:39
@PeterJ Alright, will stop :) Managed to make OpenOCD work on port 3333, rather than 4444 which did not work for me. Now the debugger hangs at the BSP_LCD_Init() line, and if I run the debugger again, I can see it stuck at WWDG_IRQHandler(). I can debug (step into) other functions just fine, for example BSP_LED_Init(), which works. — xtrinch, Jul 30 '17 at 10:33
Switch off the watchdog. But it is possible that is caused by any other exeption, because in the standard vector table they all point to the same function, and the name is sometimes taken from the last linked,. — 0___________, Jul 30 '17 at 10:36
@PeterJ Disabled the watchdog with __HAL_DBGMCU_UNFREEZE_IWDG() && __HAL_DBGMCU_UNFREEZE_WWDG(), no change. Why does the debugger hang at all, shouldn't I be able to step through until the exception ocurrs? — xtrinch, Jul 30 '17 at 10:54
It is difficult to explain in couple of words. Write your own handlers with the names same as in your startup file (where the vector table is defined & initialised). Then you will see what has caused the hardfault. You can check the registers on the stack but it is more complicated and I am unable t explain it in the comment. I do not use HAL so I do not know what those functions/macros do. — 0___________, Jul 30 '17 at 11:03
@PeterJ macros do this: (DBGMCU->APB1FZ |= (DBGMCU_APB1_FZ_DBG_WWDG_STOP)). The handlers have no arguments, how am I supposed to find out where the fault ocurred? — xtrinch, Jul 30 '17 at 11:22
From the data on the stack and register values. But you will know even without it what was the the source of the fault (at least you will have some indication). What is on the stack and how to use it: google it there is a lot information. — 0___________, Jul 30 '17 at 11:29
@PeterJ Thank you very much, your comments have been most helpful with diagnosing this problem. Traced it down to the comment I posted below, when I realized the same code actually works in SWSTM32. — xtrinch, Jul 31 '17 at 08:08

score 3 · Accepted Answer · answered Jul 31 '17 at 08:03

In case this ever helps anyone, I'm going to post what turned out to be my issue (with the HAL library):

I have not particularly added any code that deals with overriding interrupt handlers, turns out even the HAL_init() call was blocked, because I had not added the following:

void SysTick_Handler(void)
{
     HAL_IncTick();
}

Because of this, my HAL_Delay's would be waiting forever. Probably best to use the templates provided in the STM32CubeF7 templates folder, when starting out, so you don't make the same mistakes as I did..

STM32CubeF7 BSP LCD attempt

1 Answers1

Linked