Please add support for Keil

[myjtag]

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.

[GorgonMeducer]

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

[myjtag]

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:

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

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/pico-sdk/issues/877#issuecomment-1171777452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECNZSP5ZPJJDUVOS7IZAUDVRYW7XANCNFSM5ZMAQAMQ . You are receiving this because you authored the thread.Message ID: @.***>

-- دوست دار شما علی اسدزاده

[JamesH65]

That is a very ambitious claim since you don't actually know what our sales actually are...

We are looking in to alternative toolchains.

[myjtag]

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:

That is a very ambitious claim since you don't actually know what our sales actually are...

We are looking in to alternative toolchains.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/pico-sdk/issues/877#issuecomment-1173050208, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECNZSK74SEMLZZU5FC67FDVSFP5HANCNFSM5ZMAQAMQ . You are receiving this because you authored the thread.Message ID: @.***>

-- دوست دار شما علی اسدزاده

[bgolab]

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

[JamesH65]

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.

[myjtag]

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:

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.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/pico-sdk/issues/877#issuecomment-1184160320, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECNZSNBVSYSOWVSGOHGDMDVT7GLVANCNFSM5ZMAQAMQ . You are receiving this because you authored the thread.Message ID: @.***>

-- دوست دار شما علی اسدزاده

[bgolab]

I wonder if there is any update on this issue available.

[GorgonMeducer]

@bgolab, The latest version of Pico-Template now supports flash downloading in MDK. Please feel free to have a try.

[myjtag]

Dear Raspberrypi/Pico-Sdk Hi, Thanks for the update.

Best regards

On Wed, Mar 15, 2023 at 11:24 PM Gabriel Wang @.***> wrote:

@bgolab https://github.com/bgolab, The latest version of Pico-Template, now supports flash downloading in MDK. Please feel free to have a try.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/pico-sdk/issues/877#issuecomment-1470749060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECNZSPBAIJ4YM4EG272E4TW4IM5XANCNFSM5ZMAQAMQ . You are receiving this because you authored the thread.Message ID: @.***>

-- دوست دار شما علی اسدزاده

[will-v-pi]

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

[bgolab]

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.

[will-v-pi]

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

[bgolab]

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.

[will-v-pi]

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

• CMSIS
  • Core
• Compiler
  • Event Recorder (DAP)
  • I/O
  • STDOUT (EVR)
• Device
  • Startup
  • Pico Board (Pico)
  • Pico SDK

The Event Recorder is just for the retargeted stdout so it can be read over the SWD connection

[bgolab]

1. I reinstalled Keil uVision (previously removed it).
2. I removed ALL packs located at: C:\users\%username%\AppData\Local\Arm\Packs
3. selected RP2040 and install Rp2040 DFP.
4. Copied PICO example
5. added missing components automatically (CMSIS, etc). 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...

[will-v-pi]

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

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

[GorgonMeducer]

@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

[GorgonMeducer]

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

[lurch]

@GorgonMeducer Related to #1710 , or is that something entirely different?

[GorgonMeducer]

@lurch Sorry, after double check, it is the same.

But there are something missing as shown here:

[GorgonMeducer]

@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:

[bgolab]

1. 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?

2. @GorgonMeducer Yes, selecting CMSIS 5.9.0 fixes the problem. Thank you.

[will-v-pi]

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?

[bgolab]

Yes, in my case I had to install CMSIS 5.9.0 manually. The 6.1.0 was out of the box.

[GorgonMeducer]

@bgolab can you check whether the cmsis-pack I attached could solve the problem or not?

[GorgonMeducer]

so I'm not sure why @bgolab gets 6.1.0 by default when I get 5.9.0?

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.

[bgolab]

I wrote earlier that CMSIS 5.9.0 fixes the issue.

[bgolab]

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\rp2040example.axf" - 2 Error(s), 0 Warning(s). Target not created.

[GorgonMeducer]

@bgolab

I wrote earlier that CMSIS 5.9.0 fixes the issue.

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_STACK and ARM_LIB_HEAP region in the linker script.

You can try this one:

https://github.com/GorgonMeducer/Pico_Template/blob/main/project/mdk/RP2040_run_in_sram.sct

[bgolab]

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.

[bgolab]

; *** ; * 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) } }

[GorgonMeducer]

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.

@bgolab This won't work.

You have to make sure the linker script contains ARM_LIB_STACK and ARM_LIB_HEAP

If 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

[bgolab]

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.

[GorgonMeducer]

I simply followed the STM32 way of setting the Target tab

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_STACK and ARM_LIB_HEAP in scatter script to describe STACK and HEAP.

This is the reason and background.

[bgolab]

I don't have any problem with following the "new" way. Just got used to the really old way. Thank you for explanation.

[GorgonMeducer]

I don't have any problem with following the "new" way. Just got used to the really old way.

For many people, knowing the reason and background helps with inner peace. : p

[bgolab]

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

[bgolab]

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?

[GorgonMeducer]

It looks like I need to do something else because the generated code is still linked in the flash area.

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

[bgolab]

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.

[bgolab]

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)

[GorgonMeducer]

@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

[GorgonMeducer]

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

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?

• probably nobody cares for SRAM use case.

As you can see, I really care, so that's why I am trying my best to understand the reason behind a request.

[bgolab]

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.

[lurch]

As you can see, I really care, so that's why I am trying my best to understand the reason behind a request.

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.

[GorgonMeducer]

@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

[bgolab]

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.

[GorgonMeducer]

Linker tab: I see that you set R/O base to 0x0000000 whereas I had 0x10000000 when failed.

Once we use linker script, this kind of option won't affect the final result.

Got the same errors.

Can you pass me the map file?

This time I would like to use the official release to compare.

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.

[bgolab]

rp2040_example.map.txt renamed to txt to upload...