Invalid data read in sleep mode (WFI) about stmviewer HOT 26 CLOSED

Thanks for the clarification. Please try out the attached installer, or this commit. Zeros were the effect of stlink failing to read data during WFI, the memory readout part definitely needs better error handling.

Regarding the building process please do the following:

1. make sure you've got MinGw installed
2. mkdir build && cd build
3. cmake .. -G"MinGW Makefiles"
4. mingw32-make.exe -j

Please let me know if if worked :)

STMViewer_installer.zip

from stmviewer.

You are right! Problem was in old compiler. I've got confused with MinGW installation...
I deleted MinGW and MSYS2, and reinstall MSYS2.
Into MSYS2 terminal I updated packages:
pacman -Syu
Then I installed GCC toolchain:
pacman -S base-devel mingw-w64-ucrt-x86_64-toolchain
But when I tried to compile I've got an error about missing llvm-ar. So I installed llvm:
pacman -S mingw-w64-ucrt-x86_64-llvm
Then I tried to compile again but had an error about missing ld. Then I've found the flag -fuse-ld=lld in CMakeLists, so I installed lld too.
pacman -S mingw-w64-x86_64-lld
Also I added compiler and tools to PATH
C:\msys64\mingw64\bin
C:\msys64\ucrt64\bin
C:\msys64\usr\bin
And now I am able to build a project!
Now I am going to figure out how stlink_read_debug32 function differs from stlink_read_mem32, or find a way how to fix it.
If you have any idea how is better to fix this issue, let me know (if you are not working on it right now)

from stmviewer.

Hello! Sorry, I haven't yet tested the data readout in WFI. Could you provide a minimal example, or provide more details on the problem? For example how does the data get corrupted, is it often or not? Is it only in WFI mode and always works fine when not in sleep mode? Have you tested it on both J-Link and ST-Link? Which branch are you on?

The same goes with the compilation - I really would like to help you but I'm not able to do so without more details (terminal output, branch etc).

from stmviewer.

I use version 0.5.0-alpha from Releases page and while MCU slepping data always reads as 0. This problem is also present in old STMStudio by ST. Here is a video how it looks:
https://github.com/klonyyy/STMViewer/assets/15126602/dfabb8c5-9da1-4d2b-90fb-b15b956f099a

I made test firmware for STM32F401, it is really simple and requires only SysTick timer, so can be ported on any STM32 chip. All magic is in main function. Logic of test is that testVar counts from 0 to 10000, and I am watching it in STMViewer.
https://github.com/wckdwzrd/test_sleep

I also added delay 1ms instead of sleep, and about 1-2 times per second I get 0 instead of correct value. I tried to change sample period to 500ms, but problem still present. I attached video how it looks without sleep:
https://github.com/klonyyy/STMViewer/assets/15126602/cb3dca11-0d40-47b3-ae8f-5ca62dcaa3a5

I tried to use JLink instead of STLink, but on 0.5.0 my JLink only resets and FW is not running, I checked on another JLink and another project and have same behavior. Maybe if you have some branch where it is working I would like to build and check it

About compilation: I used tag 0.5.0-alpha commit: f65dd13
I compile it on Windows with MinGW, but also tried with CLang and MSVC and wasn't able to build.

PS C:\workspace\STMViewer> cmake -B build -S . -G "Unix Makefiles"
Compiling for native system
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/MinGW/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/MinGW/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at third_party/nfd/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


nfd Platform: PLATFORM_WIN32
nfd Compiler: COMPILER_GNU
-- Configuring done (6.1s)
-- Generating done (0.1s)
-- Build files have been written to: C:/workspace/STMViewer/build
PS C:\workspace\STMViewer> cd build
PS C:\workspace\STMViewer\build> make
[  2%] Building CXX object third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj
C:/workspace/STMViewer/third_party/nfd/src/nfd_win.cpp:81:32: error: '::IFileDialog' has not been declared
 nfdresult_t AddFiltersToDialog(::IFileDialog* fileOpenDialog,
                                ^~
compilation terminated due to -Wfatal-errors.
third_party/nfd/src/CMakeFiles/nfd.dir/build.make:76: recipe for target 'third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj' failed
make[2]: *** [third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj] Error 1
CMakeFiles/Makefile2:168: recipe for target 'third_party/nfd/src/CMakeFiles/nfd.dir/all' failed
make[1]: *** [third_party/nfd/src/CMakeFiles/nfd.dir/all] Error 2
Makefile:155: recipe for target 'all' failed
make: *** [all] Error 2

from stmviewer.

I also added delay 1ms instead of sleep, and about 1-2 times per second I get 0 instead of correct value. I tried to change sample period to 500ms, but problem still present. I attached video how it looks without sleep:
https://github.com/klonyyy/STMViewer/assets/15126602/cb3dca11-0d40-47b3-ae8f-5ca62dcaa3a5

One more thing. I also checked this FW without sleep on old STMStudio, it worked fine, so I guess FW is ok

from stmviewer.

Hi! I tried this new build 0.5.0 JLink works well! Even with WFI it works great!
Thank you!

Unfortunately, I couldn't build a project with those commands :(
But anyway, thank you for fixing JLink!

from stmviewer.

Glad you got it working with JLink!

Could you show me the output of the failed compilation? I'd like to make sure I know about all dependencies/issues to build STMViewer on other devices.

from stmviewer.

PS C:\workspace\STMViewer> mkdir build


    Directory: C:\workspace\STMViewer


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        22.04.2024     13:29                build


PS C:\workspace\STMViewer> cd build
PS C:\workspace\STMViewer\build> cmake .. -G"MinGW Makefiles"
Compiling for native system
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/MinGW/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/MinGW/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at third_party/nfd/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


nfd Platform: PLATFORM_WIN32
nfd Compiler: COMPILER_GNU
-- Configuring done (6.1s)
-- Generating done (0.2s)
-- Build files have been written to: C:/workspace/STMViewer/build
PS C:\workspace\STMViewer\build> mingw32-make -j
[  2%] Generating gitversion.hpp...
[  5%] Building CXX object third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj
[  5%] Built target addGitVersion
C:\workspace\STMViewer\third_party\nfd\src\nfd_win.cpp:81:32: error: '::IFileDialog' has not been declared
 nfdresult_t AddFiltersToDialog(::IFileDialog* fileOpenDialog,
                                ^~
compilation terminated due to -Wfatal-errors.
third_party\nfd\src\CMakeFiles\nfd.dir\build.make:75: recipe for target 'third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj' failed
mingw32-make[2]: *** [third_party/nfd/src/CMakeFiles/nfd.dir/nfd_win.cpp.obj] Error 1
CMakeFiles\Makefile2:167: recipe for target 'third_party/nfd/src/CMakeFiles/nfd.dir/all' failed
mingw32-make[1]: *** [third_party/nfd/src/CMakeFiles/nfd.dir/all] Error 2
Makefile:154: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
PS C:\workspace\STMViewer\build>

I guess it is something related to NFD library

from stmviewer.

I use VS Code and I installed MinGW and MSYS2 according to this guide https://code.visualstudio.com/docs/cpp/config-mingw
Do I need to install some other tools?

from stmviewer.

It looks like you're using a very old gcc/g++ toolchain (6.3.0). You've got yo use at least a version that supports C++20.

from stmviewer.

Thank you for such a thorough description, I'll base the README.md build tutorial on it!

So regarding the ST-Link problem it still persists in WFI, am I right? If you find any solution to this problem please let me know. Right now I won't able to dig deeper into it as I'm working on the J-Link HSS feature.

from stmviewer.

So regarding the ST-Link problem it still persists in WFI, am I right?

Yes, nothing changed

If you find any solution to this problem please let me know

I will take a look this week, if I find any solution I'll let you know

from stmviewer.

Hi!

JLink works well! Even with WFI it works great!

Unfortunately, I didn't flash FW while testing it... So it works but without reading in WFI. UPD: it works well)
But I've made a fix for that, and for STLink too.
How can I do a pull request? I tried to push a branch with fix but got Permission Denied error

from stmviewer.

Hello, you first have to fork the repo, make the changes you want to include on the branch you experimented on and then create a pull request.

from stmviewer.

Hi, I made Pull Request, but I based on your last build that you sent f381cdc
So this PR contains too much files...
Can you manage this and change destination branch? It is hard to understand where should I push.

from stmviewer.

Thank you for the PR. I will look through it later on and let you know!

Could you explain why reading data while the core is halted (waking it up for the read) is of interest to you? It seems like it is somehow interfering with the regular program flow? Are you sure Jlink wakes up the core during a read? It seems it should not be necesarry as we're accessing the memory using debug interface?

Is it really about reading data in the sleep mode, or rather not getting zeros, but previous values when the mode is entered in a intermittent fasion?

from stmviewer.

Could you explain why reading data while the core is halted (waking it up for the read) is of interest to you?

We were using STMStudio for manufacturing, QC, QA and service teams. In one of previous releases I've added low power mode, and now STMStudio is unusable for our purposes. I can fix it by disabling sleep when debugger connected, but it would be better if just software works good. So now, I guess, we will migrate to STMViewer.

It seems like it is somehow interfering with the regular program flow?

If core is not in sleep mode - nothing changed. It may change program flow by waking up from sleep, usually it is not a problem, but in case when there are specific logic (for example when core MUST sleep for EXACTLY 1sec) it may change this flow.
JLink works well for this case, I guess, SEGGER somehow put chip back to sleep after reading data.

Are you sure Jlink wakes up the core during a read?

No, I'm not sure, it is hidden in JLink internals. Maybe they use other way to read. But reversing JLink is too long way to fix this bug.
I've read some articles and that document by ARM:
https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Debug-register-support-in-the-SCS/Debug-Halting-Control-and-Status-Register--DHCSR
It said about sleep flag that The debugger must set the C_HALT bit to 1 to gain control, or wait for an interrupt or other wakeup event to wakeup the system., so I went this way, and it works. It may slow program flow because of halt/resume, but I've added a few if conditions to prevent halt/resume if core is not in sleep mode. In case when it was in sleep, it wouldn't slow anything (because it wasn't running).

It seems it should not be necesarry as we're accessing the memory using debug interface?

I don't get this question. We still use debug interface to read data, we use same functions to get data. Halt/Resume is not used if core is not in sleep mode. When core is in sleep (and no Halt happen) data reads returns 0 (on those chips that I tested) and success error code, this is exactly we can see on this video

SleepEnabled.mp4

Is it really about reading data in the sleep mode, or rather not getting zeros, but previous values when the mode is entered in a intermittent fasion?

Values looks valid in my case. There is a possibility that it is an old data stored before sleep. But I change data using core, so even if it's values that was before entering sleep it is still valid. Only way I know how data can be changed not using core - is DMA or other peripherals, but I haven't test it yet, and I'm not sure in what case it make sense

I will look through it later on and let you know!

Thanks, I'm also wondering if you'll accept this fix, when do you plan to release 0.5.0?

from stmviewer.

Thank you for the additional explanation. I understand that the video shows behavior at this commit or a later one? I'm asking because I've explicitly implemented that the series value stays at the last valid sample so there should be no "jumping to zero" as shown in the video. BTW: you can check the commit hash in the about tab. When I tested it locally on a G4 STM32 it worked fine.

Would such solution be enough for you? I think there is no real benefit from resuming the core and reading the values, compared to reading it when the core is awake in the next cycle (so that the probe does not interfere with the natural application sleep cycle of the core). Could you explain the difference if I don't understand it correctly? Let's assume, as you said, that the memory can be only modified by the core, not DMA or other peripherals.

Thanks, I'm also wondering if you'll accept this fix, when do you plan to release 0.5.0?

I will need some more time for this to make sure the resume-halt is the correct solution, as my main priority now is the HSS feature for the J-Link. I plan on merging it to devel soon, and merging to main around June 2024.

from stmviewer.

I understand that the video shows behavior at this commit or a later one? I'm asking because I've explicitly implemented that the series value stays at the last valid sample so there should be no "jumping to zero" as shown in the video.

Yes, I based my branch on this commit. Your solution is to not display value if this function returns false

bool StlinkHandler::readMemory(uint32_t address, uint32_t* value)
{
	if (!isRunning)
		return false;
	return stlink_read_debug32(sl, address, value) == 0;
}

but in case when core is sleeping it returns true and value is 0. And the plot is "jumping to zero"

I think there is no real benefit from resuming the core and reading the values, compared to reading it when the core is awake in the next cycle

Even if the solution above worked, the problem is that we display the last value that we read by stlink, not last value modified by core. In case when core sleep around 90% of the time it is hard to get real value, and if we drawing curve it won't show real picture what is going on with variable

from stmviewer.

I will need more time to understand how the sleep modes affect the debug capabilities. I do not want to push a solution that none of us really understands. If you have some spare time you can help me research why stlink has trouble reading in the sleep mode. I wasn't yet able to 100% reproduce the issue you're facing - I'm seeing a similar behavior on both ST-Link and J-Link, but I might be doing something wrong in putting the MCU to sleep. Anyways, for the next week or two I won't have much time to work on this issue.

from stmviewer.

Ok, sure, but can you do a test build with that fix? Like 0.5.0-testSleep or 0.5.0-alpha2? So we can use like "official" build instead of my local one.

from stmviewer.

I'm sorry but I would like to avoid confusion for regular users - this release is full of new untested features, and you're the only one who requested it. If it had a larger interest it would go up on my priority list. In the meantime I'd propose you use the fork that works for you and I will release a proper release after researching the topic more.

from stmviewer.

Ok, I see. But can you build at least an installer for this commit?

from stmviewer.

Actually you should be able to enable automatic builds using actions in the forked repo somehow (maybe the repo settings?) this way you can create releases yourself. It seems they are turned off for your fork of STMViewer somehow. The installer should be created on each pushed commit, as in STMViewer's "actions" tab.

from stmviewer.

Hello, did you manage to set up the actions in the forked repo?

from stmviewer.

Closing due to inactivity. Please reopen if needed.

from stmviewer.