Uploaded code not executing on the Nucleo H745ZI - stm32

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.

Related

Raspberry pi pico w unable to import dht module

I was using a dht22 sensor in my raspberry pi pico w board but suddenly I can't anymore
I get the following error when trying to import dht module:
ValueError: incompatible .mpy file
I tried updating the micropython firmware to the latest version but the problem persists.
My DHT22 module is a bit faulty since I connected it backwards the first time, but it was working ok, sometimes it emits a high pitched noise, but after reconnecting it it worked normally, now It emits the sound constantly.
However the error appears regardless of the sensor being connected or not, just by calling "import dht" without any extra code.
The rest of the functions of the board are still working, I can blink the led, drive a relay module, run a web server, all the other functions of my application work normally.
After looking at the files loaded in my board an extra file was present:
dht.mpy
The file had contents from my log function (a function I use to write exceptions to a file)
I have no clue how this happened, but deleting it solved the problem

STM32F103C8T6 board not flashing with Keil 5

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.

How to fix 'Unable to open file' when uploading to STM32 in TrueStudio

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 "#"

No SWV or ITM with st-link v2 emulator programmer and stm32f103c8t6

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.

Flashing image to STM3220g-EVAL board using Trace 32

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).