how can I debug STM32 board using gdb without stlink or any other device.
actually I am trying to design an equipment which can replace the STMC device, since ST was stopped making this devices
You cannot debug a bare metal system without a debugger. STM32 support JTAG, SWD debuggers. You still can program it without a programmer/debugger (using the integrated bootloader if present in your model) and put your debug string on an uart, but no conventional debuggin, so no gdb.
Related
I want to reprogram the external flash of a raspberry Pico via SWD line.
This feature must be implemented in a different microcontroller, not from a Linux computer so the OpenOCD library cannot be used.
I already wrote a C library that is able to read and write in RAM and in core registers via SWD and I'm able to put the Cortex-M0+ into halt state.
I read many tutorials and documentation and those that are useful are:
http://markding.github.io/swd_programing_sram/
https://www.silabs.com/documents/public/application-notes/an0062.pdf
https://community.silabs.com/s/article/how-to-program-internal-sram-over-swd?language=en_US
but unfortunately they aren't clear enough.
Can you explain the sequence of commands that I should send to RP2040 to correctly upload the new firmware?
Thanks for your help!
I'm trying to boot a kernel (extracted from a firmware) using QEMU.
Qemu emulation seems to start at 0x0.
The problem is that the memory from 0x0 to 0x04000000 is only filled with 0.
How can i debug the bootloader?
You don't say what your command line is. The address where QEMU starts execution depends on many things:
the guest CPU architecture
which board model you are emulating
whether you passed QEMU a BIOS image file
the file format of any file passed to -kernel (ELF, plain kernel image, uImage, etc)
In general, though, you should not expect to be able to pull a random kernel image out of a firmware dump for a piece of Arm hardware and run it under QEMU. This is because every Arm board or machine is different -- RAM may be in different places, the devices such as the serial port are at different addresses, and so on -- and the kernel will only boot on systems which it has been compiled to support. The chances are very high that (a) QEMU does not have a specific emulation of the bit of hardware that the firmware dump is for and (b) the kernel from the firmware has not been built to also run on any of the board types that QEMU does support. So it will almost certainly simply crash very early on in bootup without producing any output.
If you want to debug what's going on in early bootup, the best approach is probably to use QEMU's built in gdbstub, and attach a guest-architecture-aware gdb to it. You may also find QEMU's internal logging via the '-d' option useful, though it requires some familiarity with how QEMU works to make sense of the output.
I successfully implemented an "[accelerator in 15 minutes]"1 on parallella board. Now I need to send an interrupt from pl to ps. So I connected it to IRQ_F2P of Zynq processing system.
Now, how can I get this interrupt in arm processor?
Usual interrupt example using "XILINX SDK" tool which uses a JTAG. But in parallella , I don't have a JTAG. (I am coping the program to SD card and execute it from SD card using Ubuntu). So any suggestions are most welcome.
So for parallella, I tried to use the Xilinx SDK, but the header files are creating an error..
My one more doubt is "Is it possible to create a bsp using sdk tool and copy it into sd card and then make it run on parallella board. Will it work ?
If not, how do we get this interrupt in arm processor, because all example uses Xilinx header files like "xparameters.h, xil_printf.h, xcugic.h, etc" and these are connected to many other Xilinx functions.
I am using arm-none-eabi toolchain to create binary file for Nucleo which I then flash to the Nucleo using the USB virtual storage device it provides.
I am compiling the program with -ggdb. But how could I possibly connect to the nucleo and execute breakpoints on it? I can't even imagine how could it work, but I'm complete beginner.
Can I connect? How?
Yes you can connect, at least from a Linux host. I never tried from Windows system. Use OpenOCD to open a debug port and connect gdb (used arm-none-eabi-gdb) to this port with "gdb extended-remote" command. I am using this method from Linux host PC to connect to a custom board based on STM32L4 series for debugging and collecting log messages. Nucleo boards are also using the same series of STM controller.
For what it's worth there's a free IDE call EMBlocks that I've used in the past. I think the new version is called EMBitz https://www.embitz.org/
I've used it to both flash the STM32 Nucleo boards as well as debug the flashed image file.
A quick search also turns up this website that seems to indicate you can use GDB with the stlink utility. https://openenergymonitor.org/emon/node/6189
I have LPC2148 daughter board but I am not able to dump/burn code into it, and it doesn't have any usb connector to dump code.
I read on internet by using FT232RL I can able dump code into LPC2148 but I am not able to do so.
please give me solution
thank you..!
The chip supports In-System Programming (ISP) via an on-chip boot loader ROM.
From the User Manual UM10139:
Programming of the Flash memory may be accomplished in several ways:
over the serial built-in JTAG interface, using In System Programming
(ISP) and UART0, or by means of In Application Programming (IAP)
capabilities.
The function of the FT232RL you mentioned is to act as a USB/UART bridge and is necessary primarily because modern PCs lack legacy RS-232 serial ports. You can in fact purchase a USB-Serial cable or adapter which will contain a bridge chip such as the FT232RL. Most of these use RS-232 line level signals, so you would still need an RS-232 line driver/receiver to connect then to your board (if your board has a serial port, it probably already has a line transceiver and you can connect directly to that). It is possible from specialist suppliers including FTDI themselves to get a USB cable with integrated FT232 and bare TTL level connections to connect directly to LPC2148 UART0 Rx/Tx lines.
If your board does not already expose a UART0 serial port and the necessart control to start the boot loader, a Serial Port Bootloader Interface board is available. For that you may then also need a USB/Serial adapter or a PC with a legacy serial ports.
Once you have a suitable serial connection, you will need the LPC2000 Flash Utility software to run on the PC.
The JTAG option is however faster, and more powerful since the JTAG is both a programming and debugging port. With a suitable toolchain and JTAG adapter it is possible to program and execute code with source-level PC hosted debugging including break pointing, data watching and single stepping of the code.