2021-04-26 12:38 PM
Hello,
I have been trying to import an already-existing project into CubeIDE. This project was created on Keil MDK. So, when I import the project, CubeIDE does not recognize the drivers for the board I am program, nor the source files. How can I use the project on CubeIDE?
Any insight is appreciated
Thank you.
2021-08-19 02:29 PM
Cube provides for different startup.s files under the CMSIS\Device trees
Keil's linker creates a scatter list for the content that needs initializing and the scatter loader is called via __main, with SystemInit called first to bring up external memories, clocks, etc.
ST's GNU implementation has a far cruder initialization method using a bodge of symbols to convey source/destination locations and sizes.
Perhaps look towards how Arduino did this as they build a tabular initialization method closer to that used by Keil.
The .ELF/.AXF/.O/.A are all sufficiently similar that they might bind, but more often than not it is other dependencies or libraries, or intrinsics (memcpy, memset, floating point, etc) that break the linker. In porting objects you might need some "wedge" functions that map the differences, either pointing at the right symbol, or implementing enough functionality to allow it to work. This can be further complicated by floating point methods and hard/soft FPU ABI choices and flagging within the objects. Sometimes it's worth the bother, others it is not. When it gets to the "impossible, but necessary" stage there are often other approaches.
It's a pretty sad indictment of a tool vendor that they can't import from a text or XML based project file of a competitive product directly.
2021-08-20 05:57 PM
Competitive product? Do you think that ST wants to compete with Keil or IAR?
2021-08-27 11:49 AM
Hi,
After struggling a bit with importing my project from MDK Keil, I have been able to load and compile it into STM32CubeIDE. Now, I am debugging my code but I get the following error:
STMicroelectronics ST-LINK GDB server. Version 5.8.0
Copyright (c) 2020, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.7.0-RC1
-------------------------------------------------------------------
ST-LINK SN : 36FF6C064D59303630542543
ST-LINK FW : V2J37S7
Board : --
Voltage : 3.24V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x436
Revision ID : Rev X
Device name : STM32L15xxD/STM32L162xD
Flash size : 128 KBytes (default)
Device type : MCU
Device CPU : Cortex-M3
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_Ou8nm0.srec
File : ST-LINK_GDB_server_Ou8nm0.srec
Size : 203541 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Error: Operation exceeds memory limits
Error: failed to erase memory
Encountered Error when opening /opt/st/stm32cubeide_1.6.1_2/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.6.0.202101291314/tools/bin/STM32_Programmer_CLI
Error in STM32CubeProgrammer
Debugger connection lost.
Shutting down...
According to the datasheet, the flash memory is 348 KB (such a value is also in the linker file) but the STM32CubeProgrammer states that the Flash size is 128KB. I have already updated the St-link v2 debugger.
Does anybody know how I can fix this? The micro-controller I am working with belongs to the family STM32L152xD (precisely STM32L152VDT6)
Thank you for your help.
Regards.
2021-08-30 12:17 AM
Hi,
Give a try with STM32CubeIde 1.7.0, it has the latest STM32CubeProgrammer (v2.8.0) hopefully fixing this issue.
Rgds,
Laurent
2021-08-30 08:16 AM
Hi @LaurentL ,
I have updated STM32CubeIDe to 1.7.0 and STM32CubeProgrammer to v2.8.0 but the same problem remains. I have tried using different reset behaviors with no success. Furthermore, I checked the linker script and there is is stated that:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 48K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 384K
}
Any insight on how I can work this out? Can this problem be related to the initialization files too?
Thank you.
Regards.
2021-08-30 10:40 AM
It seems to be an STM32CubeProgrammer issue.
Try with Openocd gdb server (in debugger tab of Debug config), it doesn't use STM32CubeProgrammer.
Rgds,
Laurent
2021-09-01 04:48 AM
Hi,
When I switch to Opencd debug probe, I get the following error message:
Open On-Chip Debugger 0.11.0-rc2+dev-00044-g8340bb0 (2021-06-02-17:27)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J38S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.244561
Info : clock speed 480 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : STM32L152VDTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32L152VDTx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : Device: STM32L1xx (Cat.4/Cat.3 - Medium+/High Density)
Info : STM32L flash has dual banks. Bank (0) size is 192kb, base address is 0x8000000
Info : Device: STM32L1xx (Cat.4/Cat.3 - Medium+/High Density)
Info : STM32L flash has dual banks. Bank (1) size is 192kb, base address is 0x8030000
undefined debug reason 8 - target needs reset
Info : accepting 'gdb' connection on tcp/3333
undefined debug reason 8 - target needs reset
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800f218 msp: 0x2000c000
STM32L: Enabling HSI
Info : Padding image section 0 at 0x0800013c with 4 bytes
Info : Padding image section 1 at 0x0802fe84 with 4 bytes
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (13956 ms). Workaround: increase "set remotetimeout" in GDB
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800f218 msp: 0x2000c000
Error: STM32L152VDTx.cpu -- clearing lockup after double fault
Polling target STM32L152VDTx.cpu failed, trying to reexamine
Info : STM32L152VDTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Besides, I have tried using STM32CubeProgrammer and even there the flash memory size is incorrect. Both platforms show that the flash memory size is 128 KBytes; I am using a STM32L152VD micro-controller. I have verified that the chip RDP is 0xAA (Level 0, no protection). For Openocd and ST-link GDB serve, I have tried different resent modes too.
In the Memory Regions tab, I have the following:
So, I do not know whether it is a code/program or a platform issue.
Thank you for your help.
Regards.
2021-09-01 05:18 AM
Hello,
I have checked internally and the fix will be available on next STM32CubeProgrammer version 2.9.0.
As a workaround, you can fix the file in your current version :
File STM32CubeProgrammer_2_8_0\Data_Base\STM32_Prog_DB_0x436.xml
Replace :
<FlashSize address="0x1FF800CC" default="0x20000"/>
By
<FlashSize address="0x1FF800CC" default="0x60000"/>
For STM32CubeIde, same fix to apply on same file in STM32CubeProgrammer plugin.
For Openocd, did you try "software system reset" ?
If you didn't connect the STLink reset line to mcu's reset pin, you must use this reset strategy.
Rgds,
Laurent
2021-09-14 04:14 AM
Hi @LaurentL,
I have modified the file you suggested and now the size of the memory flash is correct.
However, I am still getting the same error as follows:
STM32CubeProgrammer v2.8.0
-------------------------------------------------------------------
ST-LINK SN : 36FF6C064D59303630542543
ST-LINK FW : V2J38S7
Board : --
Voltage : 3.21V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x436
Revision ID : Rev X
Device name : STM32L15xxD/STM32L162xD
Flash size : 384 KBytes (default)
Device type : MCU
Device CPU : Cortex-M3
BL Version : 0x__
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a09308.srec
File : ST-LINK_GDB_server_a09308.srec
Size : 207865 Bytes
Address : 0x08005000
Erasing memory corresponding to segment 0:
Error: Operation exceeds memory limits
Error: failed to erase memory
Debugger connection lost.
Shutting down...
I am pretty sure the memory my program needs fits the available physical memory. When I use Opencd, I get errors too.
Furthermore, I have the bootloader as a HEX file. How can I make use of this file into the project? On Keil, this is used by invoking hexmate "bootloader.hex" after bulding. When I build the code I do not have any error messages, so I believe the code is working properly. Besides, I have disabled all breakpoints. I think it is important to mention that there is a debug.h and debug.c files in my project and the main function looks like:
int main( void )
{
// The bootloader activates the 3V3 switcher
/* STM32 HAL library initialization*/
HAL_Init( );
/* Configure the system clock to 32 MHz*/
SystemClock_Config( );
/* Configure the debug mode*/
DBG_Init( );
/* Configure the hardware*/
HW_Init(__HAL_RCC_GET_FLAG(RCC_FLAG_PORRST));
/* Application initialized here */
appInit();
/* MAIN LOOP */
while( 1 )
{
/* check the different timers and events */
appDo();
/* if an interrupt has occurred after DISABLE_IRQ, it is kept pending
* and cortex will not enter low power anyway */
DISABLE_IRQ( );
if (!appHasWork()){
#ifndef LOW_POWER_DISABLE
/* Sleep or Stop */
LowPower_Handler( );
#endif
}
ENABLE_IRQ();
}
}
Thank you for your support.
Regards.
2021-09-14 07:14 AM
Hi,
So you have 2 projects, one for the bootloader and one for the application ?
Strange to see the erase sector 0 for the application starting at addr 0x08005000.
Are you sure you are starting the application at the right address ?
Did you modify the linker script or it starts at 0x0800 0000 as a default application ?
For the bootloader, you can download it if you have an elf file (you can add the elf download prior to the application in application's debug configuration (startup tab)).
Did you connect the reset line from STLink to the STM32 reset pin on your board ?
If not, don't use "Connect under reset" but "Software System reset".
For the DBG_Init, I don't know what you are doing inside but it might kill the communication.
So,you should better connect the reset line and use "connect under reset" and check that you have the debug in low power mode active.
Maybe do a mass erase with STM32CubeProgrammer to start with a clean state.
Rgds,
Laurent