I'm doing memory optimization and replacing the HAL implementation with commands that directly change bits in registers. To validate these changes, I'm changing the functions, debugging and putting the breakpoint after the function is executed, then taking snapshots of the peripheral registers through the SFR (Special Function Registers) feature of the CUBE IDE.
These snapshots are made with printscreen, my intention would be to snapshot with a log file, export all registers in a text file to use a difference program analyse. I do this for both the code using HAL and my version, then I can validate if it is stable, assuming that if the registers are equally configured, everything will work as expected.
See some sample:
implementation direct in register
implementation using HAL lib
I discovered a software (winIDEA Community Edition) that has this functionality to export to text file, it needs a little maintenance, last release was made in 06/2020. Using the examples themselves I had some problems, including one of them the software breaks and closes.
winIDEA Community Edition exporting SFR option
Does anyone have an alternative? Eclipse plugin or even a third-party tool that debugs with stlink and captures register values.
Related
I am currently working on a library that abstracts the use of a stm board (specifically the NUCLEO-H723ZG) and we are on the profiling phase. I did get to make the profiling with the SWV after a big headache with the SB26 bridge that comes with the aforementioned board, using the auto generated code from stm32cubeIDE.
Now i need to do the same but abstracting the auto generated code from the stm32cubeIDE into a method that does all the configuration for you, but i cannot pin point what is really missing. I already have copied the SystemClock config, the PeriphCommonClock config, both SCB_Enable Cache and the MPU_Config (and yes both are using the same copy of the ioc configuration). Any ideas of what i could be missing?
I tried to profile an autogenerated main.c and after some configuration it worked perfectly.
Then i tried to do the same with a main.cpp and copying the methods form the autogenerated main one by one (just to see whose were needed) and after copying them all it didn t work. The code executes and the live expressions work. The configurations are the same on the .ioc and the debugging.
I m now looking for the minimum necessary for an SWV configuration method, preferably non dependant from HAL.
This question already has answers here:
CMSIS & STM32, How to begin? [closed]
(2 answers)
Closed 1 year ago.
As I want to write an efficient program to use minimal RAM & Flash, I want to remove HAL library completely from my project & program only in registers.
I want to use cubeIDE for compiling & Debugging but I do not know how to remove HAL library from my project(It seems that HAL library created and attached to project by default when generating project).
Is there any practical way?
Best!
There is an option in STM32CubeIDE project generation which allows you to create empty projects.
The empty project comes with the following:
main.c : Mostly empty
syscalls.c : I don't know what it is for but probably useless.
sysmem.c : Implements _sbrk() function, which is used by malloc() & new()
startup_stm32[xxxxxxxx].s : Startup file in assembly. You can leave it as it is
[xxxxxx]_FLASH.ld : Linker script file. Most of the time, this can be left unchanged.
But you need some additional libraries & files.
CMSIS Library : This includes some core functions common to all Cortex M devices. The core library is header only, and it's the only one you need to get started. There are some additional CMSIS libraries, like the DSP library which you may need depending on your project requirements. I suggest downloading it from its official repository.
Official STM32 headers from ST : This is actually called STM32Cube[xx] (STM32CubeF4 for example) and includes the Cube & HAL framework you want to get rid off. But we're interested in CMSIS compliant device headers. You can delete the rest. It also includes a version of CMSIS which lags behind the official one. Since you can download the latest CMSIS from its official repository, you don't need the one included in Cube package. You can download the relevant package from ST. For example, this one is for F4 series.
Once you have the needed packages, you need to configure STM32CubeIDE such that your project uses the newly obtained libraries. Basically, you need to add some additional include directories and symbol definitions. And there is an additional system_stm32[xxxxx].c file, which can be found in STM32Cube package and needs to be included in your project.
Here you can find a somewhat related answer.
Here is an example STM32CubeIDE blinky project I've created for the Blue Pill board (STM32F103C8). It may be somewhat outdated but it's probably still useful.
The method I've described probably isn't very practical. Some people suggest creating a normal Cube & HAL project and than pruning the unused parts.
Recently, I decided to learn a new programming language and I know that C++(which is the language I am going to learn) is really good and fast.(fast execution)
And now I have a question about C++(and maybe C)
Is it possible to make a program that runs on every device?
like bypassing the OS and run commands/0s and 1s directly on the CPU?
or
run on a computer that does not have an OS installed, like creating your own OS?
And if it's possible then what is the difference between the .exes(windows executables) and the programs with No-OS support? (On compilation and on the file as file)
C is older than C++ but you are right that it is similar to C++ because it is compiled to binary code. When you write a C/C++ program you compile it to binary using a compiler.
Today, most desktop computers run on a variant of x86 architecture processor which started with Intel's 8086. The x86 processors are well documented. I never implemented an assembler so I can't tell exactly how to go from high level code (C/C++) to binary but I can link to the documentation which tells you how to do that. Here you have the download link for the Intel software developer manual: https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html. Appendix B of volume 2 of this download link has the instruction encoding explanations. Here's a picture of the format of an instruction:
On x86 (and all other architectures like ARM), the instructions have a certain conventional encoding that the compiler knows and that it will use to compile your high level code to binary code. Today, when you write an OS, you use a screen and a compiler and other tools readily available to compile to binary code. With gcc/g++ on Linux you have the freestanding and static flags which allow to include all the code in your final executable and to make sure the code is self-standing.
If you write code on Linux and want to develop an OS, you need to know C/C++ quite well because you cannot use anything which relies on the standard libraries like printf() or cout. This means that you are left with the basic C/C++ like pointers (which are very important) and function calls and other stuff. You need to know quite well how the language works to control memory properly and to be able to not use stuff of the language which depends on the presence of an OS.
The .exe file is a conventional format which contains binary code. The Linux equivalent of a .exe file is a .elf file. There's nothing wrong about compiling an OS to a .exe file (or a .elf file) and parsing that file from a bootloader to jump to its entry point. The difference is that you need to tell your compiler and you need to write a program which doesn't rely on the presence of an OS to work (because you are the one who writes the OS). You are thus left with the basic C/C++ like pointers and structs. With C++ you can use classes as well because they are compiled to function calls.
For freestanding C/C++ code to work, you need to set up a hardware stack with the RSP register of the CPU. This will allow your code to call functions (other than main()). Freestanding C/C++ code relies on the presence of a stack but nothing else to work properly because all high level lines of code that you write will be compiled to CPU instructions which don't rely on anything else. If you wanted, you could even forget the stack and do everything in the main function and forget about functions. You would thus be left with pointers and structs. I think a minimum is to have functions so that you can organize your code properly. Linux is really just a freestanding, statically linked C program compiled to a .elf file and compressed with gzip. Linux follows the multiboot specification which tells how to boot it. It means that, to write Linux, the developers used only pointers, structs and functions. Pointers are compiled to memory fetch code which is one instruction in itself. Structs are compiled to data. Functions are compiled to relative jumps (short jumps), pop and push instructions (using the stack for the arguments). This is pretty much it.
You can definitely write your own OS because otherwise how would Microsoft develop Windows. To write an OS, you need to use tools at your disposition and compile freestanding and static code. Then you need to write a custom bootloader like a legacy bootloader in assembly or a UEFI bootloader in C compiled with specialized tools like EDK2. EDK2 is a compiler for UEFI bootloaders. Once you have an EFI app, you can launch that app and parse a statically linked freestanding .elf file (or .exe file) from the app. Then you can jump to the entry point of that .elf file. You can use the UEFI environment to load the .elf file from the hard disk.
Remember when you last installed an OS. You basically use a tool like Media Creation Tool from microsoft to write a small OS on a USB stick. Then you choose that USB stick to boot from the BIOS and you install the OS to an hard disk. Developing and OS is the same. You use an existing compiler and existing OS to write custom OS code. Then you write that code to a USB stick (or an hard disk) and then you test the code. A better option is emulation. You do that using specialized virtualization software like QEMU or Virtual Box to test your custom OS.
With the default VSCode Arduino configuration the compiler is optimizing the generated code as fully optimized, so debugging using Cortex-Debug is pretty much impossible as code is optimized out and stepping jumps around everywhere.
Any pointers on how to disable all compiler optimizations?
I don't know what development board you are using, I am using an Adafruit M0 Express. Adafruit has create board configuration options for I think is most of their SAMD boards. If you edit the boards.txt file. The image below is the standard board selector for VSCode Arduino for a Feather M0 Express, note the additional debug option. Adafruit has implemented a more extensive choice for optimizations on their M4 boards. Modeling from there example you could switch debug and optimizations separately.
Click here to see example in VSCode
My Adafruit boards are found here:
C:\Users\GregTerrell\AppData\Local\Arduino15\packages\adafruit\hardware\samd\1.5.11
The boards.txt default for
.menu.debug.on.build.flags.debug=-g
Change that to
.menu.debug.on.build.flags.debug=-g -O0
If you look at the build details the compiler command lines will have -Os and later you should find "-g -O0". GCC documentation states that if multiple occurrences of a flag are encountered, the last version of a compiler flag is used for the build.
Notes:
You will have to restart VSCode for the change to be effective.
Back up or take notes on how you change the boards.txt files. Updating your boards from within the Arduino IDE will overwrite your changes.
I add the UnityEngine.UI.dll and UnityEditor.UI.dll to my assets folder with their mdb files . also i add the both project to my current project. i am sure all the unity engine ugui code build success, because i debug log in the event system, and it print message. when i want to step into the event system class, i always failed . I find unity will load the code from a build path ,rather than i original code. Why does it do this ? if i want to debug unity engine ugui code, what should i do ?
To debug code, you need two things:
Symbols, the list of all functions, classes, variables used throughout the module. When using C++ symbols are stored in special .pdb files on Windows (and you obviously are using Windows since you are talking about dlls). Symbols in C# (.NET in general) are stored in the .dll itself. Having symbols will let you see the name of functions on the call stack and possibly some variables but nothing more.
Source code of the module.
U3D's source code is proprietary - you need to spend a good amount of money to receive it. And if I am guess to - UnityEngine.UI.dll is a C++ module with stripped (removed) symbols removed.
Thus you have neither, so you can't debug U3D's code at all.
Why would you need to that anyway? If you want to see how the internals of a big game engine work, there are plenty of other options (for example UE4 and Lumberyard). If you are struggling with a problem and you'd like to be able to solve it through debugging...well though luck. Your best bet would be to ask in unity community.