stm32: Shell module sample doesn't work on nucleo_l152re

[takumiando]

Shell module sample doesn't work on nucleo_l152re with latest Zephyr.

$ west build -p auto -b nucleo_l152re zephyr/samples/subsys/shell/shell_module
$ west flash

[00:00:00.000,000] <err> os: ***** MPU FAULT *****
[00:00:00.000,000] <err> os:   Instruction Access Violation
[00:00:00.000,000] <err> os: r0/a1:  0x00000000  r1/a2:  0x20000580  r2/a3:  0x00000000
[00:00:00.000,000] <err> os: r3/a4:  0x00000000 r12/ip:  0xaaaaaaaa r14/lr:  0xfffffffd
[00:00:00.000,000] <err> os:  xpsr:  0x61000036
[00:00:00.000,000] <err> os: Faulting instruction address (r15/pc): 0xe7ecfc56
[00:00:00.001,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.001,000] <err> os: Fault during interrupt handling

[00:00:00.001,000] <err> os: Current thread: 0x200005d0 (idle)
[00:00:00.070,000] <err> os: Halting system

Environment

• OS: Debian GNU/Linux 10 amd64
• Toolchain: zephyr-sdk 0.10.3
• Commit SHA: 68a2359

[takumiando]

The integration sample also doesn't work.
Does this bug depends on board specific implementations?

*** Booting Zephyr OS build zephyr-v2.1.0-1246-g68a235932f93  ***
Running test suite framework_tests
===================================================================
starting test - test_assert
PASS - test_assert
===================================================================
Test suite framework_tests succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL
E: ***** MPU FAULT *****
E:   Instruction Access Violation
E: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x20000184
E: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0xfffffffd
E:  xpsr:  0x6100000f
E: Faulting instruction address (r15/pc): 0xbf0306da
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x20000184 (idle)
E: Halting system

[takumiando]

At f144e39, it also doesn't work.
Of course I added CONFIG_EEPROM_SHELL=y to prj.conf like this commit message...

[erwango]

@takumiando, I suspect an issue with the clock_control driver.
Can you try using following clock settings:
CONFIG_CLOCK_STM32_SYSCLK_SRC_HSI=y
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=16000000

[maxschuh]

@takumiando, I suspect an issue with the clock_control driver.
Can you try using following clock settings:
CONFIG_CLOCK_STM32_SYSCLK_SRC_HSI=y
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=16000000

yes, this seems to solve the problem on my side. Both 'samples/synchronization' and 'samples/philosophers' work with these settings

[erwango]

Further testing shows that we're facing the same issue on nucleo_l053r8.
Issue seems linked to setting SYSCLK to 32MHz (whatever the clock source PLL HSE/HSI or direct HSI).

[frantony]

@takumiando

E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x20000184 (idle)
E: Halting system

Please try to turn the board power off and then on just after burning zephyr image.
The sample should run successfully after power cycle.

[erwango]

Please try to turn the board power off and then on just after burning zephyr image.
The sample should run successfully after power cycle.

@frantony thanks for the hint but this is not how it is supposed to work.
Any idea on the possible root cause for this ?

[takumiando]

@erwango, thanks for your idea of workaround!
It works successfully.

[erwango]

@takumiando, I've replaced zephyr code with code from STM32Cube using LL API to set up the clock and faced the same issue.
So, while it looks correlated with a clock control issue it is not an issue in zephyr clock control driver. Either this is a SoC issue, either this is linked with another part of zephyr code.
This will require deeper investigation.

[tagunil]

These 32MHz faults go away after commenting out WFI instruction in arch_cpu_idle(), so I guess it is some weird kind of interaction between sleep mode and debugging. Looks similar to unanswered question here: https://community.st.com/s/question/0D50X00009XkXgd/stm32l1-hardfault-when-returning-from-wfi-only-when-debugger-attached

[tagunil]

Replacing WFI instruction with CPSID i; WFI; CPSIE i sequence also helps somehow, but I have no idea why it is so.

[tagunil]

Looks like FreeRTOS Cortex-M ports actually mask interrupts before going to sleep (e.g. https:/FreeRTOS/FreeRTOS-Kernel/blob/master/portable/GCC/ARM_CM3/port.c#L476). Maybe that should be discussed with ARM maintainers.

[erwango]

Looks like FreeRTOS Cortex-M ports actually mask interrupts before going to sleep (e.g. https:/FreeRTOS/FreeRTOS-Kernel/blob/master/portable/GCC/ARM_CM3/port.c#L476). Maybe that should be discussed with ARM maintainers.

@ioannisg any opinion on this ?

[ioannisg]

@tagunil (FYI @erwango)
The interrupt masking you proposed above has the following effect: the system wakes up before the ISR is executed. This is needed, in general, if we wish to execute code after the system is woken up by the interrupt, but before the ISR interrupt is executed. In the case of Zephyr ARM's arch_cpu_idle() there is nothing executed after wfi (the function simply returns) so I don't think this would play any significant role in your case.

What is indeed missing here is a __DSB() instruction before calling WFI - I wonder if you can try that an report your findings.

[tagunil]

@ioannisg
I've tested your barriers-related commit from #23436. Unfortunately, that didn't fix the problem.

[stephanosio]

@tagunil Could you check if #23511 fixes the problem?

[tagunil]

@stephanosio Yeah, #23511 works, although I still can't understand why.

[ioannisg]

@takumiando can you check, now, if this can be closed? #23511 is merged.

[takumiando]

@ioannisg It works correctly on my nucleo_l152re ;)

[erwango]

@takumiando could you create an issue to get nucleo_l152re working at full speed now? (reverting #22308)

[takumiando]

@erwango Okay #23762

[LQchengdu]

For me, disable debug-mode by LL is also work fine.

    LL_DBGMCU_DisableDBGSleepMode();
    LL_DBGMCU_DisableDBGStandbyMode();
    LL_DBGMCU_DisableDBGStopMode();