Using local PACK packages

HalfSweet commented 11 months ago

Type: Feature Request Some Chinese vendors' packs are not uploaded to the CMSIS-PACK package management system, but such packs exist locally. i would like to have some way to use the local packs directly, so that more MCUs can be supported.

thegecko commented 11 months ago

@HalfSweet

Apologies it's not obvious, but you can enter a path to your pack (.pack) or folder in that box.

Kind regards,

Rob

HalfSweet commented 11 months ago

Thank you very much, I entered the absolute path to find the package. But I'm still confused, how should I set the parameters of the debugger? For example, whether to use the SWD interface or JTAG, and the maximum frequency the debugger can use and other related parameters.

thegecko commented 11 months ago

If you add a debug launch task, some of those debug options are available to set.

It's early days, so don't expect all parameters just yet. Please have a play and let us know what missing parameters are most important to you.

HalfSweet commented 11 months ago

I tried to download using the RUN button, but it doesn't seem to work, here is the error log

Parse debug description...
Create system description...
Connect to debug unit (CMSIS-DAP)...
Configure debug unit (SWD @ 10000000 Hz)...
Create device map...
Add Flash Algorithm...
        'AIR001xx 32kB Flash' (0x08000000 - 0x08007fff)
Connect ('haltOnConnect') to device AIR001Dev...
Device connected
Halt...
Device halted after connect
Reset ('system')...
Reset completed
Load application...
Erase full chip...
ERROR: RAM function did not stop
ERROR: Core register write failed
ERROR: Core register write failed
ERROR: Failed to erase flash
Skipped reset & run target
Disconnect from device...
Disconnect from debug unit...
Flash failed

But the puzzling thing is that if I use Debug (NO flash) for debugging, I can do breakpoints and view variable and stack information normally.

And, the debugging console prints out a series of errors - but the debugging functionality is actually fully available.

Device Selected: 070000011a5a5bb600000000000aeff4a5a5a5a597969908
Parse debug description...
Create system description...
Connect to debug unit (CMSIS-DAP)...
Configure debug unit (SWD @ 10000000 Hz)...
Create device map...
Parse dbgconf file...
Connect ('haltOnConnect') to device AIR001Dev...
Device connected
Halt...
Device halted after connect
Reset ('auto')...
Reset completed
Load application...
Warning: Compilation unit with unsupported DWARF v3 info: 'D:/GitHub/luatos-soc-air001/ModuleDemo/GPIO/Example_HAL/MDK6_Test/MDK-ARM/startup_air001_dev.s'
Verify loaded image...
    Code section: 0x08000000 - 0x0800083f
ERROR: Contents mismatch at: 0x8000008  (Target=0xeb  Required=0xf7) !
ERROR: Contents mismatch at: 0x800000c  (Target=0xe7  Required=0xf3) !
ERROR: Contents mismatch at: 0x800002c  (Target=0x73  Required=0x7f) !
ERROR: Contents mismatch at: 0x8000038  (Target=0x71  Required=0x7d) !
ERROR: Contents mismatch at: 0x800003c  (Target=0xc5  Required=0xd1) !
ERROR: Contents mismatch at: 0x80000cc  (Target=0x55  Required=0x61) !
ERROR: Contents mismatch at: 0x80000e8  (Target=0xcd  Required=0xd9) !
ERROR: Contents mismatch at: 0x8000130  (Target=0x6  Required=0x1c) !
ERROR: Contents mismatch at: 0x8000131  (Target=0x4c  Required=0xb5) !
ERROR: Contents mismatch at: 0x8000132  (Target=0x1  Required=0x9) !
ERROR: Contents mismatch at: 0x8000133  (Target=0x25  Required=0x48) !
ERROR: Too many errors to display !
Verify done
Set code breakpoint...
Go to 'main'...
Halted on breakpoint

thegecko commented 11 months ago

Thanks for the feedback. @jreineckearm do you have any pointers?

jreineckearm commented 11 months ago

Hi,

The erase operation time out could have various root causes. It could be a too small timeout defined in the FLM file that works with other toolchains due to different timings. Or the function genuinely doesn't come to an end (could have run into a fault or something else in the system interrupts it). Unfortunately, I don't have access to the board or the CMSIS pack. So, I cannot try to reproduce.

Was the same or a very similar application downloaded to flash with a different tool before? This could explain that debug seems to work well enough.

The verify errors could again have multiple root causes. Some of them are guesses because I don't know details about the device or the used debugger:

The previously loaded and the current application are really slightly different.
The device stops after reset at a bootloader, and the flash memory gets re-mapped to the same address range when exiting the bootloader. But I don't know if the device has such a bootloader or memory re-mapping.
There is a genuine issue with the debugger communication. I see in a screenshot that this is a DAPLink debugger. Which interface version is it based on?

HalfSweet commented 10 months ago

Thank you very much for your help, but the problem has not been solved. I tried several different chips, including STM32F303R8, STM32FG474RB, but the puzzling thing is that no matter using the built-in Package Manager or using the local packages, all of them can be flashed correctly. then I use the Chinese chip Air32 and Air001. The local packs of Air32 and Air001 that I used from China could not be downloaded, and the errors that I was prompted with appeared when I erased the flash, something like this

Erase full chip...
ERROR: RAM function did not stop
ERROR: Core register write failed
ERROR: Core register write failed
ERROR: Failed to erase flash
Skipped reset & run target
Disconnect from device...
Disconnect from debug unit...
Flash failed

I'm guessing it might have something to do with the fact that the CMSIS-PACK package they provide is not standardized? I'll attach the packs provided with both chips at the end of this article, and if you want, I can give you some development boards for testing - just provide the addresses.

What is confusing though, is that both packs can be flashed properly in the MDK 5.38a software.

Thank you very much for your help! Keil.AIR32F103_DFP.1.1.7.zip Keil.AIR001_DFP.1.0.1.zip

HalfSweet commented 10 months ago

I will answer your questions gradually

First of all, I used PyOCD to download the compiled binary to my MCU, which seems to explain why it is possible to debug - because the binary is indeed downloaded to the MCU.

Regarding the FLM file issue, I'm guessing that maybe I didn't do the writeup in my CMSIS-PACK with enough specification, causing this plugin to not be parsed or maybe it's something else?

The device doesn't have any bootloader or memory remapping!

It's a DAPLink-V2 debugger and I tried using STLink-V2.1 and got the same results.

And I tried to use a local PACK with a similar download algorithm - Keil.STM32F1xx_DFP.2.0.0.pack - and he seems to work fine and does what I expect perfectly.

Finally, if you would like to get the physical one available for actual debugging, feel free to contact me to provide the address. Have a nice working life.

HalfSweet commented 10 months ago

Can you guys help me out? If you guys need the appropriate hardware, I can provide it to you. I really want to solve this problem. @thegecko @jreineckearm

jreineckearm commented 10 months ago

@HalfSweet , thanks for providing more information.

The timeouts in the FLM sources (FlashDev.c) look OK, but it could be worth a try to increase it for a test and rebuild the FLM files.

Another thing worth to try is to modify the elements in the PDSC file and add RAMstart and RAMsize attributes. See https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_family_pg.html#element_algorithm This gives the debugger clearer instructions where to place and execute the flash algorithms during programming, than with the legacy way of determining the RAM from the elements.

HalfSweet commented 10 months ago

Great! I can download my program normally at the moment.

But I have another question, how do I change the frequency of the debugger? I don't seem to find any similar configuration in tasks.json.

Finally, thank you for your reply!

jreineckearm commented 10 months ago

Glad to hear it is working now, @HalfSweet .

But I have another question, how do I change the frequency of the debugger?

We currently do not expose a debug clock setting in the task/launch configurations. We use the default clock that is provided with https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_family_pg.html#element_debugconfig

Extending those configurations is on our roadmap. Would you mind raising an feature request here: https://github.com/ARM-software/vscode-embedded-debug/issues/new/choose ? This would help us with prioritization.

Thanks!

HalfSweet commented 10 months ago

Okay, I'll create a new issue.

jreineckearm commented 10 months ago

Thank you!

ARM-software / vscode-device-manager

Using local PACK packages #4