Import from Keil MDK into STMCubeIDE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎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.
- Labels:
-
STM32CubeIDE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-15 05:09 AM
Hi,
No, I just have the HEX file for the bootloader, is it possible to make use of this on STM32CubeIDE?
I am using the software system reset for the reset mode and under reset for connect mode. However, I have already tried different reset modes and debugger options with no success.
The function DGB_Init() looks like (DEBUG is defined in this case):
void DBG_Init( void )
{
#if defined (DEBUG)
__HAL_RCC_DBGMCU_CLK_ENABLE( );
HAL_DBGMCU_EnableDBGSleepMode( );
HAL_DBGMCU_EnableDBGStopMode( );
HAL_DBGMCU_EnableDBGStandbyMode( );
#else /* DEBUG */
__HAL_RCC_DBGMCU_CLK_ENABLE( );
HAL_DBGMCU_DisableDBGSleepMode( );
HAL_DBGMCU_DisableDBGStopMode( );
HAL_DBGMCU_DisableDBGStandbyMode( );
__HAL_RCC_DBGMCU_CLK_DISABLE( );
GPIO_InitTypeDef initStruct={0};
/* Configure analog inputs */
initStruct.Mode = GPIO_MODE_ANALOG;
initStruct.Pull = GPIO_NOPULL;
HW_GPIO_Init(SW_CLK_Port, SW_CLK_Pin, &initStruct);
HW_GPIO_Init(SW_DAT_Port, SW_DAT_Pin, &initStruct);
#endif
}
Besides, I realocate the vector table as follows (DEF_APP is defined) in the system_stm32l1xx.c file
#ifdef DEF_APP
#define VECT_TAB_OFFSET 0x5000 /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
#else
#define VECT_TAB_OFFSET 0x0 /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
#endif
And in the linker file I have:
MEMORY
{
FLASH (rx) : ORIGIN = 0x8005000, LENGTH = 364K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 48K
}
It is my understanding, I can download the program without having the bootloader. This from a cleaned-memory chip. I have done and I still have the same error. Obviously, in this case, my flash starts at 0x0800 0000 and the Vector Table base offset field is set to 0x0.
Since I have the HEX file of the original project on Keil, I can download it into the board and it works fine; for this I use STM32CubeProgrammer. But when I try downloading the project imported to STM32CudeIDE, I got an error stating that memory exceeds limits.
As a result, I believe the error is in the startup files and linker. I attach the initiliaziation files on STM32CubeIDE and their counterparts on Keil.
Thank you very much for your help.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-16 06:35 AM
There is one issue on this project, it erases segment 0 so addr 0x800 0000 so it will erase your bootloader part.
The startup file is ok.
The linker you show seems ok.
You have to check in the map file why it is putting data between addr 0x800 0000 and 0x800 5000.
Check your "defines" to have the correct Vectors stuff.
For the bootloader program, I suggest you do the same as you did on the appli prj, import files and try to debug it first.
Rgds,
Laurent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-17 09:34 AM
Hi,
I have managed to have the bootloader running on STM32CubeIDE and downloading into my board.
Regarding the app project, I have been reading the reference manual for STM32L152xD. The thing is that when I set VECT_TAB_OFFSET to any value, this value is not taken into account when compiling and when I set FLASH (rx) : ORIGIN = 0x8005000, LENGTH = 364K in the linker file, such a shift does happen in the memory map.
Based on my understanding, there is one extra change I have have not made: I should change the option byte to boot from 0x8005000.
After checking in my project, the files stm32l1xx_hal.h, stm32l1xx_hal_flash_ex.c and stm32l152xd.h contain those functions to modify option bytes, but i do not see how to perform such a change in the code and where.
Thank you.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-17 09:45 AM
Hi,
I don't think you must modify the option byte boot address.
You still want to boot on your bootloader.
If you update the option byte boot, you will never be able to use your bootloader anymore.
There is maybe something else to configure on system
Search for example of bootloader and application on STM32L1.
Rgds,
Laurent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-20 11:10 AM
Hi,
I still have issues trying to download the app into the board. From my application project, the resulting bin file always starts at 0x800 0000 although the memory shows that the app memory starts at 0x800 5208
And the output.map looks like:
I have modified the script files as follows.
Linker file in my bootloader project:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 48K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 21K
}
Linker file in my app project:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 48K
FLASH (rx) : ORIGIN = 0x8005208, LENGTH = 363K // total flash in STM32L152xD 384 KB
}
In system_stm32l1xx.c, I define:
#define VECT_TAB_OFFSET 0x5208U
Furthermore, I know I can 'force' the debugger to work from the address where the vectors are defined (set the program counter), but this does not fix the problem either.
I have also modified the RAM memory but I think this is not the problem. Even if I do not use the bootloader, my app image is corrupting the bootloader area.
To give an example, when I read the elf file on STM32CubeProgrammer, I have the following info from my app project:
As can be seen, the app projects starts at 0x800 0000. There must be a subtle issue with my code but I do not figure out where.
Thank you for your help.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-09-21 09:44 AM
The flash can be erased by sector so you must look at the STM32L152xD device reference manual and find the flash page size (sector size in kb) to allocate multiple of sector size for the bootloader.
If the sector size is 4K, you can keep 20K for bootloader for example. Or 24K if you need 21K.
Then, the same to begin the application in linker script, don't start appli at 0x0800 5208 but rather at 0x0800 5000 or 0x0800 6000 if it's a 4K sector size and that bootloader's limit is just before.
For the RAM, starting the 2 appli at the same address is maybe ok.
The startup file will copy data initialization in ram after the botloader has jump into the appli so maybe ok.
For the elf file seen in STM32CubeProgrammer, We can see .ELF in ascii in the first addresses so it is definitively not a good file.
You should see the stack at address 0x0800 0000 (value should be after 0x2000 0000) and then the reset vector at 0x0800 0004 (value should be after 0x0800 0000) and then all isr vectors...
Rgds,
Laurent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-10-17 11:35 AM
Hi,
I have made those changes you pointed out and I have not been able to solve my problem yet.
Now, I am trying with OpenCD and it looks like it can talk "more" to the micro-controller.
I have come up with the idea that probably when migrating from Keil, the boot pins behave differently (BOOT pins, I do not have a .ioc file, where can I look for these pins' definition/configuration in a file).
I checked and the .map file is ok regarding where the reset vector starts. I still find myself in the situation where the app accesses diffrent starting address even when the linker and startup file are well defined.
For this reason, where should I look up to find other lines where such behavior could be modified?
This is what I get when using opencd:
Open On-Chip Debugger 0.11.0-rc2+dev-00044-g8340bb0 (2021-06-02-17:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swv
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.215213
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : STM32L152VDTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : STM32L152VDTx.cpu: external reset detected
Info : starting gdb server for STM32L152VDTx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800017c msp: 0x2000c000
STM32L: Enabling HSI
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
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
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800017c msp: 0x2000c000
STM32L: Enabling HSI
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
OK:7d0;1;8ca0,12,ffff;
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800017c msp: 0x2000c000
STM32L: Enabling HSI
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Padding image section 0 at 0x08005124 with 4 bytes
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (5411 ms). Workaround: increase "set remotetimeout" in GDB
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800017c msp: 0x2000c000
Info : starting trace server for STM32L152VDTx.tpiu on 3344
Info : Listening on port 3344 for tpiu_swo_trace connections
OK
Info : accepting 'tpiu_swo_trace' connection on tcp/3344
Error: Fail reading CTRL/STAT register. Force reconnect
Warn : target STM32L152VDTx.cpu is not halted (gdb fileio)
Polling target STM32L152VDTx.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1011 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1009 ms). Workaround: increase "set remotetimeout" in GDB
Polling target STM32L152VDTx.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1008 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1012 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1014 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1008 ms). Workaround: increase "set remotetimeout" in GDB
Polling target STM32L152VDTx.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 700ms
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1122 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1113 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1120 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1118 ms). Workaround: increase "set remotetimeout" in GDB
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: bulk trace read failed
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1123 ms). Workaround: increase "set remotetimeout" in GDB
I can talk to the micro controller and read out what it is in its memory with no problem, so not sure if what I think the solution can be is actually a good idea.
Let me know your comments.
Thank you.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-10-18 01:45 AM
Hello,
We can see in the log that you activated SWV trace, I don't know if it is an issue but we see errors just after activating SWV.
So, maybe desactivate SWV first and see if you can go further.
For the boot pins, there are option bytes to select boot from bank2 but I don't think you are using that.
I didn't see any option bytes to select boot address on this device.
Then, check on your hardware where you have routed these boot pins.
But it seems ok on the log, we see that it halts first at 0x0800017c so not a strange value.
Rgds,
Laurent
- « Previous
- Next »