Please add support for Keil #877

myjtag · 2022-06-21T11:38:08Z

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 · 2022-06-30T23:49:04Z

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 · 2022-07-03T06:37:48Z

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 <#877 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECNZSP5ZPJJDUVOS7IZAUDVRYW7XANCNFSM5ZMAQAMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

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

JamesH65 · 2022-07-03T09:58:33Z

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 · 2022-07-04T10:16:13Z

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 <#877 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECNZSK74SEMLZZU5FC67FDVSFP5HANCNFSM5ZMAQAMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

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

bgolab · 2022-07-14T08:30:17Z

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 · 2022-07-14T08:34:55Z

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 · 2022-07-18T09:08:05Z

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 <#877 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECNZSNBVSYSOWVSGOHGDMDVT7GLVANCNFSM5ZMAQAMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

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

bgolab · 2023-03-15T18:42:40Z

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

GorgonMeducer · 2023-03-15T19:53:53Z

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

myjtag · 2023-03-16T07:54:13Z

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 <#877 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECNZSPBAIJ4YM4EG272E4TW4IM5XANCNFSM5ZMAQAMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

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

will-v-pi · 2024-05-21T14:31:59Z

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 · 2024-05-21T16:27:57Z

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 · 2024-05-21T16:35:39Z

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 · 2024-05-21T16:44:25Z

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 · 2024-05-21T17:03:13Z

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 · 2024-05-21T18:00:11Z

I reinstalled Keil uVision (previously removed it).
I removed ALL packs located at: C:\users%username%\AppData\Local\Arm\Packs
selected RP2040 and install Rp2040 DFP.
Copied PICO example
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 · 2024-05-21T18:25:49Z

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 · 2024-05-21T22:51:09Z

@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 · 2024-05-21T23:27:31Z

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 · 2024-05-21T23:32:40Z

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

GorgonMeducer · 2024-05-21T23:33:17Z

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

But there are something missing as shown here:

GorgonMeducer · 2024-05-21T23:43:00Z

@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 · 2024-05-22T05:04:38Z

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.

will-v-pi · 2024-05-22T09:50:08Z

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 · 2024-05-22T10:05:25Z

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

GorgonMeducer · 2024-05-22T10:27:45Z

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

bgolab · 2024-05-22T13:16:40Z

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 · 2024-05-22T13:31:09Z

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 · 2024-05-22T13:34:20Z

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

GorgonMeducer · 2024-05-22T13:40:45Z

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 · 2024-05-22T13:48:00Z

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 · 2024-05-22T16:24:59Z

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 · 2024-05-22T16:39:00Z

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 · 2024-05-22T17:04:30Z

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 · 2024-05-22T17:12:15Z

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 · 2024-05-22T19:25:20Z

@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 · 2024-05-22T19:29:51Z

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 · 2024-05-22T19:43:38Z

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 · 2024-05-22T20:11:57Z

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 · 2024-05-22T22:43:53Z

@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 · 2024-05-23T05:00:34Z

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 · 2024-05-23T11:51:29Z

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 · 2024-05-23T12:01:58Z

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

GorgonMeducer · 2024-05-23T13:34:01Z

@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

Memory Map of the image

  Image Entry point : 0x200000c1

  Load Region LR_IROM1 (Base: 0x20000000, Size: 0x000052e0, Max: 0x0003e000, ABSOLUTE)

    Execution Region ER_BINRAY_INFO (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_FLASH (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x00000900, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x20000000   0x000000c0   Data   RO          709    RESET               lto-llvm-5f2a3e.o
    0x200000c0   0x200000c0   0x00000008   Code   RO          220  * !!!main             c_p.l(__main.o)
    0x200000c8   0x200000c8   0x00000054   Code   RO          729    !!!scatter          c_p.l(__scatter.o)
    0x2000011c   0x2000011c   0x0000001a   Code   RO          733    !!handler_copy      c_p.l(__scatter_copy.o)

This is the one on myside:

Memory Map of the image

  Image Entry point : 0x20000001

  Load Region LR_IROM1 (Base: 0x20000000, Size: 0x00005430, Max: 0x0003e000, ABSOLUTE)

    Execution Region ER_BINRAY_INFO (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x0000002c, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x20000000   0x0000002c   Code   RO          751  * .text.Reset_Handler  lto-llvm-483d6d.o


    Execution Region ER_RAM_VECTOR_TABLE (Exec base: 0x20000100, Load base: 0x20000100, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_FLASH (Exec base: 0x20000100, Load base: 0x20000100, Size: 0x00000858, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000100   0x20000100   0x000000c0   Data   RO          795    RESET               lto-llvm-483d6d.o
    0x200001c0   0x200001c0   0x00000008   Code   RO          268  * !!!main             c_p.l(__main.o)
    0x200001c8   0x200001c8   0x00000054   Code   RO          834    !!!scatter          c_p.l(__scatter.o)
    0x2000021c   0x2000021c   0x0000001a   Code   RO          838    !!handler_copy      c_p.l(__scatter_copy.o)

You might notice that the key difference is the Reset_Handler is placed at the start of the 0x20000000

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x20000000   0x0000002c   Code   RO          751  * .text.Reset_Handler  lto-llvm-483d6d.o

This is the key difference.

In your map file, I found this:

Reset_Handler                            0x200031e9   Thumb Code    24  lto-llvm-5f2a3e.o(.text.Reset_Handler)

This is the location of Reset_Handler in my map file:

Reset_Handler                            0x20000001   Thumb Code    24  lto-llvm-483d6d.o(.text.Reset_Handler)

Based on this, I really want to check the linker script you actually use.

bgolab · 2024-05-23T13:45:30Z

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)

GorgonMeducer · 2024-05-23T13:46:40Z

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

bgolab · 2024-05-23T13:51:25Z

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

bgolab · 2024-05-23T13:51:50Z

rp2040_example.map (2).txt

GorgonMeducer · 2024-05-23T17:12:15Z

@bgolab I managed to replicate the same issue on myside, please add --entry=Reset_Handler to the Misc Controls in the linker tab as shown below:

Without this option:

Memory Map of the image

  Image Entry point : 0x200000c1

  Load Region LR_IROM1 (Base: 0x20000000, Size: 0x00005358, Max: 0x0003e000, ABSOLUTE)

    Execution Region ER_BINRAY_INFO (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_RAM_VECTOR_TABLE (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_FLASH (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x00000858, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x20000000   0x000000c0   Data   RO          795    RESET               lto-llvm-f71e40.o
    0x200000c0   0x200000c0   0x00000008   Code   RO          268  * !!!main             c_p.l(__main.o)
    0x200000c8   0x200000c8   0x00000054   Code   RO          834    !!!scatter          c_p.l(__scatter.o)
    0x2000011c   0x2000011c   0x0000001a   Code   RO          838    !!handler_copy      c_p.l(__scatter_copy.o)
    0x20000136   0x20000136   0x00000002   PAD
    0x20000138   0x20000138   0x00000002   Code   RO          835    !!handler_null      c_p.l(__scatter.o)
    0x2000013a   0x2000013a   0x00000002   PAD
    0x2000013c   0x2000013c   0x0000001c   Code   RO          840    !!handler_zi        c_p.l(__scatter_zi.o)

With this option:

Memory Map of the image

  Image Entry point : 0x20000001

  Load Region LR_IROM1 (Base: 0x20000000, Size: 0x00005430, Max: 0x0003e000, ABSOLUTE)

    Execution Region ER_BINRAY_INFO (Exec base: 0x20000000, Load base: 0x20000000, Size: 0x0000002c, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x20000000   0x0000002c   Code   RO          751  * .text.Reset_Handler  lto-llvm-ed53d8.o


    Execution Region ER_RAM_VECTOR_TABLE (Exec base: 0x20000100, Load base: 0x20000100, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_FLASH (Exec base: 0x20000100, Load base: 0x20000100, Size: 0x00000858, Max: 0xffffffff, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000100   0x20000100   0x000000c0   Data   RO          795    RESET               lto-llvm-ed53d8.o
    0x200001c0   0x200001c0   0x00000008   Code   RO          268  * !!!main             c_p.l(__main.o)
    0x200001c8   0x200001c8   0x00000054   Code   RO          834    !!!scatter          c_p.l(__scatter.o)
    0x2000021c   0x2000021c   0x0000001a   Code   RO          838    !!handler_copy      c_p.l(__scatter_copy.o)
    0x20000236   0x20000236   0x00000002   PAD
    0x20000238   0x20000238   0x00000002   Code   RO          835    !!handler_null      c_p.l(__scatter.o)
    0x2000023a   0x2000023a   0x00000002   PAD

bgolab · 2024-05-23T17:22:51Z

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.

bgolab · 2024-05-23T17:25:42Z

UF2 verified by my script that the code is located in SRAM:
rp2040_example.uf2.log

GorgonMeducer · 2024-05-23T17:35:52Z

@bgolab You mixed different things up.

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

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.

bgolab · 2024-05-23T17:36:54Z

Yes, I see. Got used to STM32;)

GorgonMeducer · 2024-05-23T17:38:14Z

Current solution, i.e. using --entry=Reset_Handler is just a workaround. PRi team needs a more elegant way to place Reset_Handler at 0x2000-0000

bgolab · 2024-05-23T17:42:52Z

It looks like the RP2 is not officially supported yet:
https://www.keil.com/dd/

GorgonMeducer · 2024-05-23T18:31:52Z

@bgolab It is the legacy list...
Please check here: https://www.keil.arm.com/packs/rp2xxx_dfp-raspberrypi/boards/

kilograham added this to the none milestone Jul 11, 2022

kilograham assigned P33M Feb 9, 2023

kilograham added the non-gcc label May 19, 2024

kilograham assigned will-v-pi May 19, 2024

Please add support for Keil #877

Please add support for Keil #877

Comments

myjtag commented Jun 21, 2022

GorgonMeducer commented Jun 30, 2022

myjtag commented Jul 3, 2022 via email

JamesH65 commented Jul 3, 2022

myjtag commented Jul 4, 2022 via email

bgolab commented Jul 14, 2022

JamesH65 commented Jul 14, 2022

myjtag commented Jul 18, 2022 via email

bgolab commented Mar 15, 2023

GorgonMeducer commented Mar 15, 2023 • edited Loading

myjtag commented Mar 16, 2023 via email

will-v-pi commented May 21, 2024

bgolab commented May 21, 2024

will-v-pi commented May 21, 2024

bgolab commented May 21, 2024

will-v-pi commented May 21, 2024

bgolab commented May 21, 2024

will-v-pi commented May 21, 2024

GorgonMeducer commented May 21, 2024 • edited Loading

GorgonMeducer commented May 21, 2024

lurch commented May 21, 2024

GorgonMeducer commented May 21, 2024 • edited Loading

GorgonMeducer commented May 21, 2024 • edited Loading

bgolab commented May 22, 2024 • edited Loading

will-v-pi commented May 22, 2024 • edited Loading

bgolab commented May 22, 2024

GorgonMeducer commented May 22, 2024

bgolab commented May 22, 2024

GorgonMeducer commented May 22, 2024

bgolab commented May 22, 2024

GorgonMeducer commented May 22, 2024

bgolab commented May 22, 2024

bgolab commented May 22, 2024

GorgonMeducer commented May 22, 2024 • edited Loading

bgolab commented May 22, 2024

I have a script which checks the uf2 file to retrieve code memory locations. Also it looks like that the map file confirms it.

bgolab commented May 22, 2024

GorgonMeducer commented May 22, 2024

GorgonMeducer commented May 22, 2024 • edited Loading

bgolab commented May 22, 2024

lurch commented May 22, 2024

GorgonMeducer commented May 22, 2024 • edited Loading

bgolab commented May 23, 2024 • edited Loading

GorgonMeducer commented May 23, 2024 • edited Loading

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024 • edited Loading

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024 • edited Loading

bgolab commented May 23, 2024

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024 • edited Loading

bgolab commented May 23, 2024

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024 • edited Loading

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024

bgolab commented May 23, 2024

GorgonMeducer commented May 23, 2024

GorgonMeducer commented Mar 15, 2023 •

edited

Loading

GorgonMeducer commented May 21, 2024 •

edited

Loading

GorgonMeducer commented May 21, 2024 •

edited

Loading

GorgonMeducer commented May 21, 2024 •

edited

Loading

bgolab commented May 22, 2024 •

edited

Loading

will-v-pi commented May 22, 2024 •

edited

Loading

GorgonMeducer commented May 22, 2024 •

edited

Loading

GorgonMeducer commented May 22, 2024 •

edited

Loading

GorgonMeducer commented May 22, 2024 •

edited

Loading

bgolab commented May 23, 2024 •

edited

Loading

GorgonMeducer commented May 23, 2024 •

edited

Loading

GorgonMeducer commented May 23, 2024 •

edited

Loading

GorgonMeducer commented May 23, 2024 •

edited

Loading

GorgonMeducer commented May 23, 2024 •

edited

Loading

GorgonMeducer commented May 23, 2024 •

edited

Loading