I have an STM3220g-EVAL board. It doesn't seem to have a preloaded image in it now, as it was used for other purposes.
When I power it on, the display is shown blank.
I dont have a STLINK/V2 hardware. I am using Trace32 and Lauterbach for flashing and debugging the code.
I created a simple C program, created an elf file by using arm-none-eabi-gcc toolchain, and was able to flash it into the STM3220g-EVAL board using a cmm script for stm32 provided in demo folder of Trace32.
What I require is to flash default image for STM3220g-eval using Trace32.
Can someone provide me the link to get the boot image and cmm script to flash the same.
I tried the demonstration builder platform and demonstration firmware provided in the following link
http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF250374
As they are providing hex file, I used Trace 32 command data.load.asciihex to load the hex file. When I press go, am getting error( emulation poer fail).
Can somesome provide me the correct cmm script to flash the .hex file to the board.
If I understand you correctly you are trying to flash the "STM3220G-EVAL demonstration firmware" on your STM3220G-EVAL board.
So the hex-file you are talking about is "STM322xG_EVAL_FW_V1.2.0.hex", right?
This hex-file is in Intel HEX file format. (See https://en.wikipedia.org/wiki/Intel_HEX)
To load a file in Intel HEX format, you should use Data.LOAD.IntelHex
So this is how to flash the file in your CPU:
Select your CPU with SYStem.CPU STM32F207IG
Connect to your CPU with SYStem.Up
Prepare flash-programming with DO ~~/demo/arm/flash/stm32f2xx.cmm PREPAREONLY
Arm flash programming with FLASH.ReProgram ALL
Load your Intel Hex file with Data.LOAD.IntelHex STM322xG_EVAL_FW_V1.2.0.hex
Finalize flash programming with FLASH.ReProgram OFF (This will start the actual programming.)
The STM3220 comes with the STLink hardware built in via the USB port. See section 2.20 from here
Version 2 of the ST-LINK, called ST-LINK/V2, is embedded on the board.
This tool allows onboard program loading and debugging of the STM32F
using the JTAG or SWD interface. Third-party debug tools are also
supported by the JTAG (CN14) or Trace (CN13) connectors. To
communicate with the embedded ST-LINK/V2, a specific driver needs to
be installed on your PC. To download and install this driver, refer
to the software and development tools page for the STM32F family
available on www.st.com (the install shield is called
ST-LINK_V2_USBdriver.exe).
Related
This is a question for people familiar with the Nucleo H745ZI, or H7 in common.
When I received the Nucleo H745ZI it had the blinking LED program on it. This was working fine.
Now I'm trying to upload my own program and it's not doing anything at all. Both the LEDs and UART aren't giving output. This is after generating a fresh project in CubeMXIDE. Everything default.
My code;
HAL_GPIO_TogglePin (GPIOB, GPIO_PIN_14);
HAL_Delay(50);
HAL_GPIO_TogglePin (GPIOE, GPIO_PIN_1);
HAL_Delay(100);
HAL_GPIO_TogglePin (GPIOB, GPIO_PIN_0);
HAL_Delay(200);
uint8_t buff[4] = {3, 4, 5, 6};
HAL_UART_Transmit(&huart3, buff, sizeof(buff), HAL_MAX_DELAY);
I've tried both building and manually uploading the CM7.bin file and using the debug tool in the CubeMXIDE. Both not working.
Firmware has been updated.
By the way, does anyone know where I can find this default program?
Found solution for NUCLEO-H745ZI-Q:
Do not drag and drop CM4 or CM7 bin file in Nucleo board storage. Use STM32CubeIDE to upload program to each one. Use default NUCLEO-H745ZI-Q board settings when creating new projects. You only need to connect ST Link USB.
When we are working on NUCLEO-H745ZI-Q remember that we have a dual core architecture so we must configure the peripherals for each core in the CubeMX project or in the Cube IDE configuration window on the tab of System Core > GPIO for the LEDS and the same for UART
Once you have generate the code, then you'll core M4 and M7 subproject directory whit their own source and main.c files.
Also, on my experience, I have notice that you must compile and upload both core-main.c-program to run your code on board, specially when you program at core M4 because the code uploaded does not execute until you upload M7 program.
I have the following problem. Once i generate Keil project using ST CubeMX and write project into STM32F103C8 MCU, everything goes well; However, after this first flashing i'am not able to flash it anymore as it throws the following error:
Error: Flash Download failed - Target DLL has been cancelled
I have pulled Boot0 pin, activated it, and erased MCU. This procedure helps only for one time flashing; however, if i flash MCU with bare metal or CMSIS code (which was not generated by CubeMX) it works fine and i can flash as many times as i want without errors.
Could you please advice, what could be wrong and how can i fix this?
Problem was in default configuration of STM CubeMx. In System core -> Sys Debug was switched off by default. After i changed it to Serial Wire it worked.
I am attempting to upload my written program for the STM32F411RE from my TrueStudio for STM32 IDE to the board itself. The board is connected via the mini USB b cable and the intent is to program it via SWD.
Setup
Atollic provides a nice tutorial on how to perform this programming via it's TrueStudio IDE and the ST-Link_CLI (Command Line Interface), as described in the document at this link. This requires the following steps, which I have followed and checked multiple times:
First and foremost the output (binary) file needs to be an intel .HEX and
not the TrueStudio .elf default. To change this go to Project properties -> c/c++ build -> settings -> tool settings tab -> other -> Output format
and tick the option 'Convert build output', ensure that the Intel Hex
option is selected in the dropdown.
To call the ST-Link_CLI from inside the IDE requires making an external
tools configuration. To make this config I go to Run -> External Tools ->
External Tools Configurations .... and create a new configuration, lets
call it ST-Link_CLI. For the Working Directory I specify the directory of my ST-LINK_CLI
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility)
whilst for the Location I specify this directory and the file name
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK
Utility\ST-LINK_CLI.exe).
Lastly, I add the following parameters to
identify the STM32 board, have it connect via SWD and under reset, whilst
telling it to upload the .HEX file built by TrueStudio
(-c ID=0 SWD UR LPM -P ${project_loc}\Debug\${project_name}.hex -v).
Output
When I then call this external tool configuration via the Run -> External Tools -> ST-Link_CLI link just created I get the output listed below:
STM32 ST-LINK CLI v3.4.0.0
STM32 ST-LINK Command Line Interface
ST-LINK SN: 066EFF525750877267092042
ST-LINK Firmware version: V2J33M25
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Connect Under Reset
Reset mode: Hardware reset
Debug in Low Power mode enabled
Device ID: 0x431
Device flash Size: 512 Kbytes
Device family: STM32F411xC/E
Loading file...
Unable to open file!
Clearly the ST-Link_CLI is succesfully called from inside the IDE, but it somehow cannot digest the .hex file (inside the debug folder) and upload it to the STM32 board.
Even flashing a completely new generated project from CubeMX and setting the options above (including setting it to a .hex file) will not let this toolchain upload it to the board.
Manual code flashing
I have been able to succesfully upload the .HEX file built by TrueStudio via manually uploading it to the STM32 Board with the use of the ST-Link GUI, so I do not think the problem is in the ST-Link itself. I cannot however debug it in this manner, since I need the TrueStudio IDE tools for that and thus need the external tool configuration to work succesfully.
Instead I suspect the issue lies with my own setup, where is somehow is missing a call or has an option set incorrectly. It could also be that the GUI and CLI clients operate in a completely different fashion allowing one to read and upload the file whilst the other cannot, but that seems unreasonable to me.
I am kind of at a loss here however, as I cannot seem to figure out why others can make this work via the provided Atollic documentation and mine is throwing up these errors.
You try to reinvent the wheel using the triangle.
Everything is configured in the TrueStudio:
Just in add the debug configuration and you are done.
What benefits would OpenOCD offer at this point
One essencial : debugging
given how much I have already learned about TrueStudio?
This knowledge (how to configure external tools etc) is rather useless in 99.9999% of circumstances. It is only the configuration of the Eclipse. Not too complex actually needed here.
In regards to my own code, I have not been able to get the ST-Link_CLI to work as an external tool the way I intended, [but I have been able to get the STCubeProgrammer (CLI) to work in the same respective manner as I was attempting to do with the ST-Link].(http://gotland.atollic.com/resources/applicationnotes/AN1801_cubeprogrammer_in_truestudio.pdf).
Seeing as I literally used the same procedure as before but instead specifying the location and executable for the STCubeProgrammer (rather than the ST-Link), I suspect the issue may indeed be the ST-Link CLI (connection to TrueStudio).
It now uploads successfully and immediately after boots me into the debug environment of TrueStudio :)
I simply commented "load" command in the startup script and debugging worked. I only had to load the hex using the st link first.
/# Load the program executable
#load <---//added "#"
I bought a cheap "st-link v2 emulator programmer" and an STM32f013C8T6 of Ebay. Using Atollic on Windows 8 and the SWD interface of the MCU, I am able to upload and run code, set breakpoints and watch variables but I can´t use printf over ITM or SWV Trace.
I have also tried using a genuine ST-LINK v2 of a Nucleo stm32l152re board with the same results.
The connections between ST-LINK and MCU are as follows:
ST-LINK - MCU:
SWDIO - SWDIO,
GND - GND,
SWCLK - SWCLK,
3.3V - 3.3V
Unused pins on the ebay ST-LINK:
RST, SWIM
Unused pins on the genuine ST-LINK:
NRST, SWO
Any advice in this matter would be appreciated and I would be happy to provide more information if needed.
Try reading Adding Trace support to ST-Link clones. Common cheap ST-Link clones must be modified at the hardware level to expose the SWO pin which ITM tracing depends upon. (Then, of course, you must also hook up that signal.)
I've got two different ST-Link clones, both of which connect nothing to the PA10 pin, like in the linked article.
I understand this question is very old. I hope you found the solution but I'd still like to put in my two cents because I came across the same problem.
My understanding is that for SWV functionality you need the SWO pin connected. When you had this problem were you able to view exception trace logs or any SWV feature other than the printf redirect?
In light of this realization I am modifying my hardware to support the SWO pin for future use.
I assume you have already done what Atollic says in this link?
Basically, ITM require the following things to redirect printf()
The application should send printf() output to an ITM channel
The JTAG probe must support SWV
The debugger must have SWV tracing with the corresponding ITM channel enabled
Despite your vendor, I assume all the ST-Links should support printf redirection. (Otherwise, use ST-Link utility and update your ST Link firmware)
Hope this helps.
I have faced the same problem today. I'm using the STLink V2 clone which doesn't have the SWO(SWV) pin, and I found two solutions:
HW modification for the clone board as other people answered her which is hereAdding Trace support to ST-Link clones.
Semihosting technique using openOCD:
2.1 in debug configurations select "ST-LINK (OpenOCD)" from Debug probe list as shown here debugger.
2.2 in startup tab, scroll down and in Run Commands placeholder, type "monitor arm semihosting enable" as shown here Run Commands.
2.3 click on apply and then close debug configurations.
2.4 open project properties. From C/C++ Build, open Tool settings. From MCU GCC Linker, select Miscellaneous. on Other flags, click on Add button and type "-specs=rdimon.specs -lc -lrdimon" as shown here arguments.
2.5 click Apply, then Apply and Close.
2.6 then you need to exclude syscalls.c. open it's properties. from C/C++ Build, select Settings and check button Exclude source from build, then click Apply and Close as shown here Exclude syscalls.c.
2.7 The finall step is before any printf, you should call initialise_monitor_handles(), and it's prototype should be included as shown below and after building and entering debug mode and hit resume, the message is printed on the console itself as shown here printing.
I'm currently working on a project on STM32F4 and I'm using Eclipse. I've got some problems with the program - it seems to have a random behavior - sometimes it works fine, other times it has some errors. Sometimes when I try do debug with breakpoints I get the beautiful HardFault Handler and it really messes with my brains.
Sorry for the little off-topic paragraph, just wanted to let you know why I decided to use printing to a log file at some key moments in the program so I can see in which states and in which functions does the problem occur. I'm debugging through a JTAG interface with Eclipse (gdb) and I need to know if there is an easy method integrated in Eclipse that may help me use fprintf-like functions inside my program to write to a file on the disk.
If no, any other solutions?
Thanks
I do not like to connect the debug output log to the Jtag communication port because the log will not be available after development.
I usually build an SystemLog library that can send the log messages through any medium that is available (UART, USB, Ethernet or SDCARD). That's what I'd recommend you to do. It will help you through the development, and the support team on the event of any failure on field.
If stdlib is available in your project you should use the snprintf family functions to build your SystemLog.
Also, you can integrate the log output to the eclipse console by calling a serial console communicator (if you use UART) on you makefile, in this case, your makefile will have to flash the target as well.