STM32F767 freeze on chibios update Topic is solved

[tsm]

Those things are out of my visibility, can't really help with that.

My generic advice is to remove everything then re-introduce things one at time.

Giovanni

Thanks anyway. I'll try to keep this updated

[tsm]

- I'm compilling an extra file chibios/os/hal/ports/STM32/LLD/EXTIv1
- I had -mthumb mode enabled. I've restored this which entailed removing -mthumb and adding -mno-thumb-interwork -DTHUMB_NO_INTERWORKING. But still the same behaviour

If you need the "EXTIv1 driver", (or not) you seem to be using and STM32xxxx CPU. These are "cortex-M" arm-variants. These do not have the original ARM instruction set, but only the thumb instruction set.
So... I would expect that you NEED the -mthumb option to the compiler.

Alright didn't know that, I'll keep them on

[tsm]

The following doesn't work (micro seems to be "jammed") and debugger is always at ResetHandler. I've looked into the registers and GDB doesn't seem have read them by this point.
Nonetheless by moving p1 outside of global scope (e.g. inside of main)) everything works fine. This makes think of memory problems, but I have way to few experience on embedded to know where to look at or be sure. Any tip on how to use the map and elf file to understand if something's wrong?

Code: Select all

// C++ headers.
#include <cstdio>
#include <ch.h>
#include <hal.h>
#include <SerialPort.hpp>

SerialPort p1 = SerialPort(&SD1);

int
main()
{
      // Initialize subsystems.
      halInit();
      chSysInit();
    
      palClearLine(LED_1);
      palClearLine(LED_2);
      palClearLine(LED_3);
      while (!chThdShouldTerminateX())
      {
        chThdSleepMilliseconds(1000);
        palToggleLine(LED_1);
        palToggleLine(LED_2);
        palToggleLine(LED_3);
      }
}

[Giovanni]

Static constructors are invoked before main() is called.

Giovanni

[tsm]

I think that constructor issue was caused by some bad linker options I changed when trying to debug. I've cleaned up the staging area, and started over with chibios-ver19.1.3.
Now I'm back at the original error: the micro seems to stop before calling chTMStartMeasurementX. I've switched on all the debug definitions, except for CH_DBG_THREADS_PROFILING because I'm in tickless mode, and now while stepping with the debugger it goes to:

Code: Select all

// chtrace.c @ line 143
void _trace_isr_leave(const char *isr) {
  if ((ch.dbg.trace_buffer.suspended & CH_DBG_TRACE_MASK_ISR) == 0U) {
    port_lock_from_isr();
    ch.dbg.trace_buffer.ptr->type        = CH_TRACE_TYPE_ISR_LEAVE;
    ch.dbg.trace_buffer.ptr->state       = 0U;
    ch.dbg.trace_buffer.ptr->u.isr.name  = isr;
    trace_next();
    port_unlock_from_isr();
  }
}

and the panic message is SV#4. According to the documentation this means: "The function chSysLock() has been called from an ISR or from within a critical zone. This can happen, for example, if you call chSysLock() twice.". Nonetheless I'm not able to figure out anything with it

[steved]

If you're using static objects you need to update file \os\common\startup\ARMCMx\compilers\GCC\ld\rules_code.ld from the repository; or download it from a link in this thread: viewtopic.php?p=37201

[tsm]

Hi steved this solved the problem perfectly. I patched my local ver19.1.3 with the files at os/common/startup/ARMCMx/compilers/GCC/ and the problem got fixed.

Thank you both for helping!