Query regarding crash in H7 Video initialisation on Giga with mbed built with gcc13.x

[schnoberts1]

Hi,

I've building mbed and my app with gcc13.x (flags the same and with gcc7.x) I see a crash in int dsi_init(uint8_t bus, struct edid *edid, struct display_timing *dt).

... before I investigate, is this a path others have been down?

[facchinm]

Hi @schnoberts1 ,
can you paste the crash output? We never tried compiling with gcc > 10 so it might be some new optimization kicking in.

[schnoberts1]

Hi,My h/w debugger is currently out of commission and I’m new to custom mbed builds (so I’m in 1990s style logging debug land) but I’ll figure out how to get some diagnostics out of the stack and post what I learn. If you have a good link for a “good mbed config for debugging” you’d save me some time :). It could well be an optimisation. There’s also been some struct layout changes and other ABI fixes though those seem to be in very specific situations. One of my structs changed layout by a byte which triggered a static_assert for size I had. It could obviously be my code and gcc7 just emitted a memory layout that accidentally mitigated against it :)  AndyOn 28 Aug 2024, at 08:19, Martino Facchin ***@***.***> wrote: Hi @schnoberts1 , can you paste the crash output? We never tried compiling with gcc > 10 so it might be some new optimization kicking in. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[schnoberts1]

Can I ask you, how do I configure the crash help? I'm using mbed-os-to-arduino-macos. I run it with a working directory which is the root of the ArduinoCore-mbed repo. I pass -in -a GIGA:GIGA to mbed-os-to-arduino-macos.

I have this in variants/GIGA/conf/mbed_app.json:

{
  "target_overrides": {
    "*": {
      "target.printf_lib": "std",
      "platform.stdio-buffered-serial": false,
      "platform.stdio-baud-rate": 115200,
      "platform.default-serial-baud-rate": 115200,
      "platform.callback-nontrivial": true,
      "platform.all-stats-enabled": true,
      "platform.memory-tracing-enabled": true,
      "platform.crash-capture-enabled": true,
      "platform.fatal-error-auto-reboot-enabled": true,
      "platform.error-reboot-max": 5,
      "rtos.main-thread-stack-size": 32768,
      "cordio.max-connections": 5,
      "target.mbed_app_start": "0x8040000",
      "target.macros_add": [
        "METAL_INTERNAL",
        "VIRTIO_DRIVER_ONLY",
        "NO_ATOMIC_64_SUPPORT",
        "METAL_MAX_DEVICE_REGIONS=2",
        "RPMSG_BUFFER_SIZE=512"
      ]
    }
  }
}

The mbed library compiles with crash reporting enabled (I patched mbed_error.c to check this) and so is my code(I similarly patched that). Auto reboot works but it ignores the reboot max. During mbed compile the relevant define is set to the chosen error-reboot-max. When I call mbed_get_reboot_error_info I get MBED_ERROR_ITEM_NOT_FOUND. The linker script has this before .data

    .crash_data_ram :
    {
        . = ALIGN(8);
        __CRASH_DATA_RAM__ = .;
        __CRASH_DATA_RAM_START__ = .; /* Create a global symbol at data start */
        KEEP(*(.keep.crash_data_ram))
        *(.m_crash_data_ram)     /* This is a user defined section */
        . += 0x100;
        . = ALIGN(8);
        __CRASH_DATA_RAM_END__ = .; /* Define a global symbol at data end */
    } > RAM
    ```
    
 appreciate you may not want to provide personal support for the sake of a crash dump so no offence taken if you don't have time to respond. The replacement part for my j-link should arrive tomorrow and hopefully that's more instructive - though the mbed crash reporting looks super useful if I can get it to work. 

[schnoberts1]

I get a hard fault while the code is at line 256 in dsi.cpp

  dsi_lcdClear(0);
  dsi_drawCurrentFrameBuffer();
  dsi_lcdClear(0);
  dsi_drawCurrentFrameBuffer(); <====

if I step through the code manually it gets into dsi_drawCurrentFrameBuffer and is in the while(reloadLTDC_status == 0) loop when I get a hard fault. It requires me to step past delay(1) so I think maybe this issue is in another context. MMARVALID bit is 1 and DACCVIOL bit is 1 in the exception registers.

Stepping through the code it only fails when I press go over something that might yield.

This is with gcc-arm-none-eabi-10.3-2021.10

[schnoberts1]

... so I returned to the gcc7 Arduino supplied compiler and it seemed stable, but if I restarted the device a number of times while connected via Serial and not connected to the debugger I would get occasional freezes. I suspect therefore it's something about my build that's at issue here. I'll close this issue and re-open it if I conclude otherwise.

[schnoberts1]

So the gcc7 issue was the problem with the developer profile mbed that I mentioned on another issue where mbed error functions go into infinite loops on anything other than a release build due to semaphore asserts. I fixed that and I've verified the dsi issue stops if I compile with -O0. I have the same issue on gcc8. I'm going to do another 2 days of diagnosis then abandoned this as mbed is EOL.

[schnoberts1]

I think this is an optimiser issue but it seems present from gcc8 onwards in various guises. The stack dumps are mostly in the same place but when you step through the code (in my h/w debugger at least) you end up stepping into delay() which goes into osDelay() which steps through some thread switching code which when it returns seems to crash the system.

I'd be interested in knowing if you've tested the Giga display with anything over gcc7 and whether you are confident it works. If you are, feel free to post a link to the working source code. Outside of that, I guess I better walk back to gcc7. Whilst I like the better optimiser and language features, they aren't gonna get my project finished.

[schnoberts1]

@facchinm I believe I have found the issue. The dsi_init call does not return a value. This is undefined behaviour and the optimiser can do whatever it wants. So I am reasonably sure this is blowing up the stack when a modern compiler is used. At least, my app starts the gui with gcc13

[schnoberts1]

@facchinm Incidentally, I have a fix for this here:

schnoberts1@497ae2c

and I have fixed aka suppressed all the warnings being generated in my projects build of ArduinoCore-mbed here: schnoberts1@b97ef31

My fork has diverged from yours so there some items in that commit where I've removed compiler warning suppression pragmas that I'd added before deciding this wasn't a good idea.

As a convention:

'C' .c/h files got __attribute__ modifiers
C++ headers for[[attribute]] modifiers
C++ source files where function args were never used had their name removed and if they were conditionally used (e.g. debug macros) they got [[maybe_unused]]

Where there were no relevant modifies I used #pragma GCC diagnostic (following the convention in the codebase)

I haven't raised a PR as, like I said, my repo has diverged a bit and this should be good enough for someone to cherry-pick into the main code if anyone wants to.

Feel free to close this when someone has cherry picked the fix across.