Please add support for Keil #877
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk#877
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
Since we have lots of libraries and code on ARM Keil tools, it would be very helpful if you could add support for it.
Please let the Pico team concentrate on what they should do. They don't have sufficient resources to add support for MDK.
For MDK support, please try this one:
https://github.com/GorgonMeducer/Pico_Template
Hi
But you are under valuing the Keil tool chain, if you add support for it, I
guarantee your sales would be boosted by 2-3X
Best Regards
On Fri, Jul 1, 2022 at 4:19 AM Gabriel Wang @.***>
wrote:
--
دوست دار شما
علی اسدزاده
That is a very ambitious claim since you don't actually know what our sales actually are...
We are looking in to alternative toolchains.
I've been using Keil for more than 10 years,and it's the standard tool for
Cortex M development, and I know they have many users, also they have
released the free version a few months ago, before that we had many many
many users with cracks! So I think My guess is not that ambitious.
I hope you would assign some team members to add the official support for
keil too.
Best Regards
On Sun, Jul 3, 2022 at 2:28 PM James Hughes @.***>
wrote:
--
دوست دار شما
علی اسدزاده
I am also interested in Keil support as I am heavy user of Keil for STM32 and so on.
I tried some some you can find here:
https://github.com/GorgonMeducer/Pico_Template
So some ground works is already done...
This is being looked in to. We do need support from ARM for certain things, which they will not be able to provide until the end of the year, unfortunately. In the meantime, lots of the toolchain already works.
Thanks, for the update, I hope we will see the official support sooner.
Regards
On Thu, Jul 14, 2022 at 1:05 PM James Hughes @.***>
wrote:
--
دوست دار شما
علی اسدزاده
I wonder if there is any update on this issue available.
@bgolab, The latest version of Pico-Template now supports flash downloading in MDK.
Please feel free to have a try.
Dear Raspberrypi/Pico-Sdk
Hi,
Thanks for the update.
Best regards
On Wed, Mar 15, 2023 at 11:24 PM Gabriel Wang @.***>
wrote:
--
دوست دار شما
علی اسدزاده
We have now released an RP2xxx_DFP, which should work as a CMSIS solution for Keil tools. Feel free to give that a go and see if it works for you
Thank you for letting me know.
I wonder if you tested the PICO basic example (the one delivered within DFP) on Keil with Community Licence enabled:
https://www.keil.arm.com/mdk-community/
I use fresh Keil 5.39.0.0 installation with the Community License activated as per the link above.
In my case I got to many compilation errors to proceed.
I wonder If you could share some details how this basic example was tested.
Thank you.
It has been tested in Keil uVision 5.39.0.0 with the Community License on Windows 11 and works fine, with no compilation errors. Did you install the DFP through the Pack Installer, and then copy the example from that?
The test process was simply to install uVision, use the Pack Installer to install the DFP, and then use the Pack Installer to copy the example and build/run it
Yes, I followed standard approach through the Pack installer then copied the basic example like I do for other MCUs like STM32. Win10.
Did you install all optional components available in the Pack Installer? I mean optional stuff like tensor flow etc?
OR what minimal components are enough apart from DFP and at least CMSIS stuff...
Will try again then.
Thank you.
I didn't install anything other than the RP2xxx_DFP, so no other optional components. The example project has the required components for it selected by default, which are
The Event Recorder is just for the retargeted stdout so it can be read over the SWD connection
I do not see and Pack dependencies errors anymore.
I tried to compile the PICO example and got 92 errors with repeating sections like this:
Build started: Project: rp2040_example
*** Using Compiler 'V6.21', folder: 'C:\Keil_v5\ARM\ARMCLANG\Bin'
Build target 'Pico'
compiling env_wrapper.c...
C:/Users/abg015/AppData/Local/Arm/Packs/RaspberryPi/RP2xxx_DFP/0.9.4/pico-sdk/src/common/pico_sync/lock_core.c(7): warning: In file included from...
C:/Users/abg015/AppData/Local/Arm/Packs/RaspberryPi/RP2xxx_DFP/0.9.4/pico-sdk/src/common/pico_sync/include\pico/lock_core.h(12): warning: In file included from...
C:/Users/abg015/AppData/Local/Arm/Packs/RaspberryPi/RP2xxx_DFP/0.9.4/pico-sdk/src/rp2_common/hardware_sync/include\hardware/sync.h(118): error: static declaration of '__builtin_arm_sev' follows non-static declaration
118 | __force_inline static void __sev(void) {
| ^
././RTE/Device/RP2040_Core0/env_wrapper.h(177): note: expanded from macro '__sev'
177 | #define __sev __builtin_arm_sev
| ^
C:\Keil_v5\ARM\ARMCLANG\Bin..\include\arm_acle.h(52): note: '__builtin_arm_sev' is a builtin with type 'void (void)'
52 | __builtin_arm_sev();
Maybe your setup had some packs already installed - before you started Keil installation - when you remove the Keil uVisions the packs are NOT removed automatically...
I have just retried these steps on a clean Windows 11 install, and it worked fine, so I'm not sure what's causing your issues
@bgolab Which cmsis version do you use?
Can you give us a screenshot about your RTE view.
I can replicate the issue you encountered. Please select cmsis 5.9.0 as a workaround.
The issue you encountered is caused by the latest cmsis 6.0.0 and 6.1.0
I managed to fix the issue with the following changes:
After adding those changes, it is possible to get along with both cmsis 5.9.0 and cmsis 6.x.0
@GorgonMeducer Related to #1710 , or is that something entirely different?
@lurch Sorry, after double check, it is the same.
But there are something missing as shown here:
@bgolab @will-v-pi I have created an fixed pack, please have a try.
RaspberryPi.RP2xxx_DFP.0.9.5-dev.pack.zip
NOTE: this isn't an official release.
After install this cmsis-pack, you need to update the env_wrapper.h as shown below:
I use brand new Keil 5.39.0.0 installation, with CMSIS 6.1.0. The default installation.
I cannot figure out why in my case I failed but in case of @will-v-pi (if the same CMSIS version was really used) everything is fine? What's the difference?
@GorgonMeducer Yes, selecting CMSIS 5.9.0 fixes the problem. Thank you.
I can confirm that I was using a slightly older installer of uVision, which still installed uVision 5.39.0.0, but defaulted to CMSIS version 5.9.0 rather than 6.1.0, which was causing the discrepancy. Will update the pack to work with 6.1.0
Edit: It looks like I was using the current version of the installer, it just installs 5.9.0 by default rather than 6.1.0 on my system, so I'm not sure why @bgolab gets 6.1.0 by default when I get 5.9.0?
Yes, in my case I had to install CMSIS 5.9.0 manually. The 6.1.0 was out of the box.
@bgolab can you check whether the cmsis-pack I attached could solve the problem or not?
When people run pack-installer and see there is newer version of cmsis-pack, it is normal to click the update button.
And Arm recommends people to use the latest cmsis also.
I wrote earlier that CMSIS 5.9.0 fixes the issue.
More interesting problem - if you change the linker setting and try to link the code to SRAM area you will get some errors:
_Build started: Project: test1
*** Using Compiler 'V6.21', folder: 'C:\Keil_v5\ARM\ARMCLANG\Bin'
Build target 'Pico'
linking...
.\Objects\rp2040_example.axf: Error: L6915E: Library reports error: __use_no_semihosting was requested, but __user_initial_stackheap was referenced
.\Objects\rp2040_example.axf: Error: L6915E: Library reports error: The semihosting _user_initial_stackheap cannot reliably set up a usable heap region if scatter loading is in use
Not enough information to list load addresses in the image map.
Finished: 1 information, 0 warning and 2 error messages.
".\Objects\rp2040_example.axf" - 2 Error(s), 0 Warning(s).
Target not created.
@bgolab
I mean using the latest cmsis-pack (i.e. 0.9.5-dev) and work with cmsis 6.1.0
For the issue you encountered, please send the linker script you modified. Based on the error info from compiler, you might have removed the
ARM_LIB_STACKandARM_LIB_HEAPregion in the linker script.You can try this one:
https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_run_in_sram.sct
I simply used the Target tab setting as shown earlier:
-the SRAM was shared between the code and data - please see the picture above.
Nothing special - just simulated no_flash option from the original RPI SDK.
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x20000000 0x00020000 { ; load region size_region
ER_IROM1 0x20000000 0x00020000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
RW_IRAM1 0x20020000 0x00022000 { ; RW data
.ANY (+RW +ZI)
}
}
@bgolab This won't work.
You have to make sure the linker script contains
ARM_LIB_STACKandARM_LIB_HEAPIf you want to place code in SRAM, please use the linker script I have shared:
https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_run_in_sram.sct
I simply followed the STM32 way of setting the Target tab (and enabling this memory map on the linker tab) when you want to use the SRAM for keeping the code.
Ok. Will follow your advise in case of using it.
STM32 still follows the old way, i.e. using assembly startup code. In the so-called latest (and recommended way) in cmsis standard, silicon vendors should use C startup code.
The so-called "latest" way, actually can be dated back to 2016.
When using C startup code, you have to add
ARM_LIB_STACKandARM_LIB_HEAPin scatter script to describe STACK and HEAP.This is the reason and background.
I don't have any problem with following the "new" way. Just got used to the really old way.
Thank you for explanation.
For many people, knowing the reason and background helps with inner peace. : p
Yes, sure. I really appreciate your help.
I wonder what other non-old way approaches I will come across when trying the RP2040 with the Keil uVision (my favorite tool).
I tried to use the scatter file you shared with the basic PICO example and selected the sct file in Linker tab.
It looks like I need to do something else because the generated code is still linked in the flash area.
Am I missing something?
How do you know? Did you check the map file?
There are always some code in the flash (the load region) but the code is actually running in SRAM (execution region).
During the startup, the code in the load region will be copied to the execution region (in SRAM).
So except the startup_RP2040.o and Stage2 BOOT, all your code is running in SRAM (although there are stored in Flash).
With this configuration, the application can survive to the next power-up.
I hope this helps.
If you truly want everything in SRAM and don't want the application survive to the next power-up, you can try this:
https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_debug_in_sram.sct
I have a script which checks the uf2 file to retrieve code memory locations. Also it looks like that the map file confirms it.
If it comes to the RPI SDK the "no_flash" set in the CMAKE config means that no flash is involved when loading the code to the execution area (the code is loaded directly to the SRAM area without any debugger help like we do in the case of STM32).
Simple drag&drop into emulated disk does the job. And the flash is not written at all.
Yes, I see the difference between flash loaded code from code directly loaded to the SRAM case.
Thank you.
When selected the RP2040_debug_in_sram.sct scatter file I got the following errors.
We can stop the investigation here not to waste more time - probably nobody cares for SRAM use case.
After Build - User command #2: C:/Users/abg015/AppData/Local/Arm/Packs/RaspberryPi/RP2xxx_DFP/0.9.4/tools\elf2uf2.exe "C:\Users\abg015\Documents\Keil\test1-sram\Objects\rp2040_example.axf" ".\rp2040_example.uf2"
ERROR: A RAM binary should have an entry point at the beginning: 20000001 (not 200000c1)
@bgolab this RP2040_debug_in_sram.sct is used for debug, that means we don't care about the elf2uf2.exe report, i.e. we don't need uf2. The MDK will load the image (*.axf) to the RP2040 directly
The key is, what is the ultimate goal? running code in SRAM or load code to sram without involving flash.
Usually, people want to run code in sram for the best performance. What's the actual use case that you want to load code to sram without involving flash? or why running code in sram (load at startup-time) is an unaccepted solution for you?
As you can see, I really care, so that's why I am trying my best to understand the reason behind a request.
One may ask why the RPI built-in this option to the bootloader - I mean ability to load & execute the code in to the SRAM area.
Every Arm Cortex is able to do this - in the case of other non-RP2040 case we have to use external SWD or JTAG debugger. Some Cortex MCUs like STM32 can do this through the serial/I2C interface built-in into the bootloader.
So the RP2040 simply continues to support Cortex well-known feature.
I like using this option personally during the development phase, for small programs since I ran into some flash issues years ago (this was TI MCU with pretty limited number of writes).
I do not want to start the discussion about flash longevity nowdays, etc.
It was not a request - I asked about this out of curiosity to see if there is basic feature pairing between the RPI SDK and Keil uVision.
Again, please do not waste your time on this niche feature.
Thank you.
If you're looking for a simple example, see https://github.com/raspberrypi/pico-examples/tree/master/flash/nuke
It builds a UF2 file which you can drag'n'drop onto a Pico (i.e. no need for SWD or a debugger) in BOOTSEL mode. It runs entirely from SRAM and simply erases the content of Flash.
@bgolab @lurch I understand now.
I have applied a fix to the scatter script
https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_debug_in_sram.sct
and now it works perfectly on my side:
Would you mind trying the Pico-Template?
I have updated it to use RP2xxx_DFP.
Please switch to the AC6-DebugInSRAM
Linker tab: I see that you set R/O base to 0x0000000 whereas I had 0x10000000 when failed.
But changing this did not help. Got the same errors.
PS. I believe I tested your templates in the past. This time I would like to use the official release to compare.
Once we use linker script, this kind of option won't affect the final result.
Can you pass me the map file?
As I mentioned above, I have updated the Pico-Template to use official RP2xxx_DFP. The reason I asked you to try it is because this could become the common example project for us to understand the reason behind the issue you encountered.
rp2040_example.map.txt
renamed to txt to upload...
@bgolab Can you attach the linker script also? The reason I ask this is because, the map file looks strange.
I know you suppose to use the linker script I provided, but just in case, please send me the one you actually uses
This is the one on myside:
You might notice that the key difference is the Reset_Handler is placed at the start of the 0x20000000
This is the key difference.
In your map file, I found this:
This is the location of Reset_Handler in my map file:
Based on this, I really want to check the linker script you actually use.
Current settings of the Linker tab and latest / freshest file (BTW. I have not touched the content of the linker file):
[RP2040_debug_in_sra
rp2040_example.map.txt
m.sct.txt](https://github.com/raspberrypi/pico-sdk/files/15417662/RP2040_debug_in_sram.sct.txt)
@bgolab You are not using the latest RP2040_debug_in_sram.sct
Please use the latest one.
https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_debug_in_sram.sct
It is different from the one you currently using.
Thank you.
This is the one you using:
This is the latest one:
I lost control of this. This time should be ok:
Program Size: Code=18804 RO-data=2152 RW-data=260 ZI-data=41148
After Build - User command #2: C:/Users/abg015/AppData/Local/Arm/Packs/RaspberryPi/RP2xxx_DFP/0.9.4/tools\elf2uf2.exe "C:\Users\abg015\Documents\Keil\test1-sram\Objects\rp2040_example.axf" ".\rp2040_example.uf2"
ERROR: A RAM binary should have an entry point at the beginning: 20000001 (not 20000181)
".\Objects\rp2040_example.axf" - 0 Error(s), 0 Warning(s).
RP2040_debug_in_sram.sct.txt
rp2040_example.map (2).txt
@bgolab I managed to replicate the same issue on myside, please add
--entry=Reset_Handlerto the Misc Controls in the linker tab as shown below:Without this option:
With this option:
Yes, the '--entry=Reset_Handler' magic setting helped. It looks like not everything is controlled by the sct.
The old-way of controlling linker settings in such simple scenario like this (just moving the code region to SRAM area) wasn't so bad;)
Thank you.
UF2 verified by my script that the code is located in SRAM:
rp2040_example.uf2.log
@bgolab You mixed different things up.
The Old way won't help.
This is because RP2040 BOOTROM only wants the Reset_Handler to be located at a specific location. This is different from STM32, which always read Reset_handler address from the vector table (RESET section in our case).
The so called old way or new way only affects how the STACK and HEAP are configured.
Yes, I see. Got used to STM32;)
Current solution, i.e. using
--entry=Reset_Handleris just a workaround. PRi team needs a more elegant way to place Reset_Handler at 0x2000-0000It looks like the RP2 is not officially supported yet:
https://www.keil.com/dd/
@bgolab It is the legacy list...
Please check here: https://www.keil.arm.com/packs/rp2xxx_dfp-raspberrypi/boards/