I use the Nucleo L476RG board with the X-Nucleo IDB05A1 expansion board from ST Microelectronics and want to test and communicate with it using the BlueNRG GUI.
But I have problems to connect with the GUI. I choose the right COM Port, open it and then it always says:
"No device detected!" and "No firmware detected. Update firmware on the motherboard (Under tools menu)."
I tried to use that tool called "Flash Motherboard FW" and followed the steps and there it always says "No DFU Bootloader found"
Anyone has some advice to solve that problem?
Thanks in advance!
Try to build this example
C:\Program Files\STMicroelectronics\BlueNRG DK 1.7.1\Projects\Project\Virtual_COM_Port\ and upload it with conventional st-link utility.
DK 1.7.1 is somewhat old.
Please use v2.02 if possible:
http://www.st.com/content/st_com/en/products/embedded-software/evaluation-tool-software/stsw-bluenrg-dk.html
There are pre-built images in DK for MCU (Mother board).
Please try C:\Program Files (x86)\STMicroelectronics\BlueNRG DK 2.0.2\Firmware\STM32L1_prebuilt_images\BlueNRG_VCOM_1_8.hex
If you are using BlrNRG-1 then reset the device before opening the comport.
Related
I've just started to study UEFI development, as a playground I've got a custom AARCH64 platform with EDK2-based sources provided for building full firmware image (to be burned into flash).
"Hello world" in DXE driver is already done, so I've selected a practical task: to include iPXE into firmware to avoid chain loading.
The idea is to build iPXE EFI application and put it into firmware volume.
Then I hope to be able to call it from UEFI shell, the final step is to add it to boot manager.
And here I stuck: I can't find any information on how to add EFI application to FV.
Please advise if it possible at all and where to read about it.
Thank you!
Okay, the solution was close in this inf file: https://github.com/tianocore/edk2-non-osi/blob/master/Drivers/Realtek/Bus/Usb/UsbNetworking/RtkUsbUndiDxe.inf
I've put pre-compiled ipxe.efi and now it's included in firmware volume.
I am currently using mac OS to set up a debugger to debug Mbed OS application , I followed the instruction from https://os.mbed.com/docs/mbed-os/v5.12/tutorials/eclipse.html .
I successfully set up the local debug toolchain and I am stuck at this error for quite awhile already. I install "make" as written in the documentary using homebrew and also set the path as suggested but still getting this error
00:13:27 **** Incremental Build of configuration Default for project mbed-os-example-blinky ****
make all
Cannot run program “make”: Unknown reason
Error: Program “make” not found in PATH
PATH=[/Users/roseyv/Developer/gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-g++]
00:13:27 Build Failed. 1 errors, 0 warnings. (took 4ms)
Any idea how to resolve this issue? or if there is any other better way we can set up debugger to debug MBED os application
Your help will be greatly appreciated, Thank you in advance!
In the mean time Mbed has updated their website. The link you posted is no longer valid. My suggestion now would be to use Mbed Studio.
Unfortunately Mbed is moving away from supporting Eclipse and only supports IDE's for which you have to be logged in with your account, Mbed Studio or the online compiler.
You could build from the command line option. Next use something like a Segger j-link and Segger Ozone to debug. I found Ozone easier to setup with random code compared to embedded debugging on Eclipse. This is what you pay for.
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 install these Plug-in in eclipse to build the stm32 develop environment:
GNU ARM Eclipse Plug-in
CDT GNU Cross Development Tools
Sourcery CodeBench Lite 2014.05-28 for ARM EABI
J-Link ARM V4.15e
I am trying to run a USART1 program in eclipse and check the output of the USART1,but when I debug this code,I got the wrong output message. The message I send is "DECA0130",but what I got is "???????"，this is obviously a garbled.
At first, I think the problem is I didn't write a write code .I checked my project again.But didn't find any error.
Then I build a new project in Keil Mdk use the same code.This time I got the right message from USATR1.I receive the string "DECA0130".
It's very strange. Because I'm not familiar with eclipse environment,I used Keil do my coding before.But the recent projects have forced me to write code .I think maybe somewhere I forgot to configure.
Because it's a new user，I don't know how to insert the program。If there is any need, please tell me.I will try my best to let you see
Thanks in advance
Seems to be a clock issue. Check the clock settings. The eclipse ARM plugin generates some configs for that. Check the function SetSysClock in the system/src/cmsis/system_stm32*.c file. I think the Keil MDK does this too, but with differnt config.
Edit: The function SetSysClock i mentioned is wrong. The clock config is done in the configure_system_clock function (file _initialize_hardware.c).
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.