Starting QEMU with -S to await a GDB connection

[dcabanis]

Hello all,

I am not sure if this is a bug or more an un-expected behaviour.

When using QEMU for emulation (Blue Pill board), especially in the context of embedded development, you might often need to debug early initialisation code. This is particularly useful in Bare metal (Rust in my case). To start QEMU in a mode where it waits for a GDB connection before starting execution I typically use the -S option. This option makes QEMU not start the execution of the guest until you explicitly give the command in GDB.

When I use the Blue Pill board. The program starts execution as soon as the binary is loaded (even when the Debug mode is enabled).

I might be doing something wrong but I would be expecting the execution of the model to only start when GDB is attached to it. Certainly, this is how its usually done when using QEMU for bare metal development.

Am I miss understanding something?

Kindly,

David.

[lcgamboa]

Hi @dcabanis ,

PICSimLab aims to work as close as possible to the real boards it simulates. In the case of qemu's -S flag, even passing it as an argument, it has no effect because the start of the simulation is a system_reset in qemu. The simplest way to get around this limitation is to do as on real boards, place a breakpoint at the beginning of the code and press the reset button. I don't know your use case, but disabling reset (commenting out this line of code) and adding -S makes the simulator stop waiting for gdb to connect.

Best regards,

Luis Claudio.

[dcabanis]

Thank you Luis,

I have tried the inline assembly bkpt instruction ( asm::bkpt() ). The execution jumps to hardfault immediately. It could just be a limitation of the QEMU model. Keeping in mind that Arm states that the BKPT instruction should not be used in user code since its behaviour is not guarenteed from one core to another. In your message you have mentioned the ability to add a -S argument to the invocation of QEMU. I have to admit I have only used PicSimLab graphically so far. Is there a config file I can use to append this argument? Or is it something I need to alter in the source file along with commenting the system_reset line before recompiling PicSimLab? By the way I am using PicSimLab for a embedded Rust class I am creating. So far I am absolutely amazed by the work you have done (mainly on the Cortex-M based platforms). Thank you so much for this. If you wanted to demonstrate how to use your program in a Rust environment (as an alternative to C/C++) I would be happy to provide you with a small tutorial on the blue pill PicSimLab board.

Thanks again, David.

[lcgamboa]

Hi @dcabanis ,

In PICSimLab, ESP32 qemu-based boards have a configuration window where extra parameters can be passed to qemu. This window has not yet been added for STM32. I will add this support. I did some tests and commenting out the previous line code of what I had informed makes the -S option work. I will let you know when I make these updates. Your examples will be handy for testing (I know, but I haven't used Rust yet).

Best regards, Luis Claudio.

[lcgamboa]

Hi @dcabanis ,

I have added the qemu configuration window to STM32 boards with the option to wait for GDB. You can test on the latest version.

Best regards, Luis Claudio.

[dcabanis]

Hello Luis,

This works great for me. I can run an debug session right from the first execution with an untouched memory. It's exactly what I needed. I noticed that you have now also included the ability to add arguments to the QEMU command. This opens a lot of new exciting options. One option that is very useful in deeply embedded SW development is the ability to use semi-hosting. For one of a better word, its the poor man's printf. Right now I cannot output semi-hosted messages using PicSimLab, there is no console that can output it (as far as I can see). As a result I have to implement my print messages via the UART. For info, semi-hosting uses the SW/JTAG logic to communicate with the debug host so you don't have to use (or have a UART) on your board. I commonly use semi-hosting with the official QEMU using the command line argument: -semihosting-config enable=on .

like this: qemu-stm32 -M stm32-f103c8-picsimlab-new -drive file=/home/dcabanis/.picsimlab/mdump_Blue_Pill_stm32f103c8t6.bin,if=pflash,format=raw -rtc clock=vm -serial /dev/tnt2 -gdb tcp::1234 -icount shift=auto,align=off,sleep=off -S -semihosting-config enable=on

Doing this allows me to print message to the QEMU console (Just like a UART if you want). So if you were looking for features to add to PicSimLab, I think the ability to see the QEMU console output would be useful to bare-metal developers like me. Many thanks again for this work you do. This is a wonderful educational tool. I'll create a small Rust project you can use to demonstrate it on your platform. Last word, in the context of education, if you are looking for boards to add to the PicSimLab environment, may I suggest you consider a board with an MCU that has a memory protection unit inside it like the cortex-M4 inside the netduinoplus2 board(supported by qemu). Being able to demonstrate memory management and how to prevent stack-overflow with an MPU is very enlightening.

Kindly,

David.

[lcgamboa]

Hi @dcabanis ,

Qemu semihosting support works with PICSimLab. But by default, the console output is redirected to the log file. You can read the log file in Linux with the tail command for example: picsimlab & tail -f ~/.picsimlab/picsimlab_log0.txt This will redirect the log file to the console. On Windows it should be possible to do something similar. Another option is to recompile PICSimLab with logging disabled using the-D_CONSOLE_LOG_option, in the case of Windows it is also necessary to enable the console with the -Wl,--subsystem,console -mconsoleoptions. With the log turned off, PICSimLab loses the ability to automatically recover from a crash, requiring manual intervention in the settings to get it working again. As for adding new boards like netduinoplus2, it is a difficult task, in Qemu only the CPU is simulated, and no peripherals for that board, for example. It would be necessary to code all peripherals such as UART, Timers, GPIO, ... to work in PICSimLab. My time to support PICSimLab is limited, I am a full-time undergraduate professor and I have almost no other external help.

Best regards,

Luis Claudio.

[dcabanis]

Hello Luis,

Thank you for the additional information. I will try the semi-hosting trick, it might be all that I need.

As mentioned earlier I have created a Rust project and an instruction file to get people started in Embedded Rust using PICSimLab. If you are interested in looking at it or including it somewhere, to help people getting started with embedded Rust on your platform, I would be more than happy to send it to you. I would just need to know what is the best way to share the Zip file with you (1.6MB). In this demo, I have the blue pill scanning for I2C devices, Identify the BMP180 sensor, then calibrate and periodically sample its value and finally send the readings onto the UART. Nothing too extraordinary but good enough for a beginner.

I also used to work for a university during my PhD studies. I used to teach digital design techniques (VLSI) to students doing their master degree. It's a long time ago but I do have good memories of those days.

Oh one last thing I have not mentioned earlier about the behavoiur of PICSimLab that I have struggled with. I am doing a lot of low level coding and invariably, at times I would do something that causes PICSimLab to crash (probably QEMU), like doing an access to an assembly instruction not yet implemented. Unfortunately when this happens, PICSimLab dies which is fine, but when I try to restart PICSimLab, it reloads itself with the same binary that caused the original crash and crashes itself in a dead loop. The way that I have used to work around this dead loop problem, was to remove the .picsimlab directory in my $HOME directory. This way I start afresh. I don't know what to suggest but in my case I would prefer to load the binary each time instead of having the model starting automatically with the previous binary pre-loaded. I guess I could make the .picsimlab directory read-only, but I haven't tried that yet.

Thanks again for your work on PICSimLab, I am very much enjoying using it.

David.

On Thu, Jul 11, 2024 at 3:14 PM lcgamboa @.***> wrote:

Hi @dcabanis https://github.com/dcabanis ,

Qemu semihosting support works with PICSimLab. But by default, the console output is redirected to the log file. You can read the log file in Linux with the tail command for example: picsimlab & tail -f ~/.picsimlab/picsimlab_log0.txt This will redirect the log file to the console. On Windows it should be possible to do something similar. Another option is to recompile PICSimLab with logging disabled using the -D_CONSOLE_LOG_option, in the case of Windows it is also necessary to enable the console with the -Wl,--subsystem,console -mconsole options. With the log turned off, PICSimLab loses the ability to automatically recover from a crash, requiring manual intervention in the settings to get it working again. As for adding new boards like netduinoplus2, it is a difficult task, in Qemu only the CPU is simulated, and no peripherals for that board, for example. It would be necessary to code all peripherals such as UART, Timers, GPIO, ... to work in PICSimLab. My time to support PICSimLab is limited, I am a full-time undergraduate professor and I have almost no other external help.

Best regards,

Luis Claudio.

— Reply to this email directly, view it on GitHub https://github.com/lcgamboa/picsimlab/issues/116#issuecomment-2222910262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52GEMIG4V3LVXWQBJTUATZL2AJTAVCNFSM6AAAAABKLB6FNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRSHEYTAMRWGI . You are receiving this because you were mentioned.Message ID: @.***>

-- Les sages sont instruits par la raison, les esprits moyens par l 'expérience, le stupide par la nécessité et la brute par l'instinct.

Cicero.

[lcgamboa]

Hi @dcabanis ,

One way to publicize your example would be to create a repository on Github with information on how to use it and the code. I can make an example in the picsimlab_examples repository and point the description to your repository.

Regarding the problem of loading invalid firmware, you are right. I think that automatically erasing the firmware in case of an error is the best option, I will try to implement this. To fix this problem manually you do not need to delete the entire .picsimlab directory, just the firmware file, with the command: rm -rf .picsimlab/mdump_Blue_Pill_stm32f103c8t6*.bin.

You can also directly load firmware to overwrite the faulty one using the command line: picsimlab Blue_Pill stm32f103c8t6 firmware.bin or loading one workspace file: picsimlab workspace.pzw

Thank you for your considerations that are helping to improve PICSimLab.

Best regards, Luis Claudio.

[dcabanis]

Hello Luis,

Just a short message to tell you that I eventually got round to putting the tutorial online at this address:

https://github.com/Doulos/Embedded-Rust-with-PicSimLab/tree/main

Feel free to suggest improvements if needed.

Kindly,

David.

On Sat, Jul 13, 2024 at 2:25 AM lcgamboa @.***> wrote:

Hi @dcabanis https://github.com/dcabanis ,

One way to publicize your example would be to create a repository on Github with information on how to use it and the code. I can make an example in the picsimlab_examples https://github.com/lcgamboa/picsimlab_examples repository and point the description to your repository.

Regarding the problem of loading invalid firmware, you are right. I think that automatically erasing the firmware in case of an error is the best option, I will try to implement this. To fix this problem manually you do not need to delete the entire .picsimlab directory, just the firmware file, with the command: rm -rf .picsimlab/mdump_Blue_Pill_stm32f103c8t6*.bin.

You can also directly load firmware to overwrite the faulty one using the command line: picsimlab Blue_Pill stm32f103c8t6 firmware.bin or loading one workspace file: picsimlab workspace.pzw

Thank you for your considerations that are helping to improve PICSimLab.

Best regards, Luis Claudio.

— Reply to this email directly, view it on GitHub https://github.com/lcgamboa/picsimlab/issues/116#issuecomment-2226569330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52GEPNTWXRFPEPX54J4FLZMBXWJAVCNFSM6AAAAABKLB6FNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWGU3DSMZTGA . You are receiving this because you were mentioned.Message ID: @.***>

-- Les sages sont instruits par la raison, les esprits moyens par l 'expérience, le stupide par la nécessité et la brute par l'instinct.

Cicero.