Regarding the Issue of Frequency Modification for nRF54L15

[listenYes]

Hi!
    I'm currently attempting to develop software using the nRF54L15 and NCS v2.9.0 (previously, I used the nRF52840 and NCS v2.9.0). Both development processes are carried out in the VS Code environment.
    However, I've noticed abnormal issues during BLE Mesh debugging. The specific manifestations are as follows:

1. In the nRF Connect plugin, the nRF54L15 - DK development board often cannot be erased. When I click the "erase board" button, an error occurs. At this time, the chip seems to be in a locked state, and I have to use the "Erase all" function in the "Programmer" software to fix it.
2. Every time I click the "Debug" button in the nRF Connect plugin, it takes a long time (more than 10 seconds) to enter the debugging interface. Moreover, debugging fails and cannot proceed, which is manifested as follows:
   (1) In VS Code, except for the "Stop" and "Pause" buttons, other debugging buttons are grayed out and ineffective (I think the debugging is already running at this time). After clicking the "Pause" button and then clicking the "Restart" button, subsequent debugging will most likely fail.
   (2) In OZone, when clicking the "Download & Reset Program" button, it will most likely prompt "UsageFault", and only in a few cases can it jump to the debugging interface.
   However, the nRF52840 and nRF52833 development boards work normally. My supplier told me that the reason is "since Bluetooth is used, debugging will disrupt the timing, which in turn leads to hardware failures." But this cannot explain the fact that the same project can be debugged on the nRF52840.
   So I suspect that the debugging failure is caused by the nRF54L15's CPU running too fast (because its default frequency is 128MHz). I want to reduce its frequency to 64MHz, the same as that of the nRF52840. However, I can't find the macro definition (similar to the CONFIG_xxx macro definition) to modify the frequency. But the datasheet shows that the nRF54L15 can be selected between 128MHz and 64MHz. So how can I switch to the 64MHz frequency?

[Elfving]

Hi,

Is this a completely default DK without anything soldered on or switches flipped? Does this work completely on the nRF52840DK? (I guess it could be the nrfutil or nrfjprog version that is at fault).

Do you have the newest version of the extension installed?

Regards,

Elfving

[listenYes]

Hi,

Yes!

To verify the above issues, I rebuilt the development environment on a new Windows 11 (64-bit) computer, so the software and extensions should be up-to-date. The development board is also an official board purchased from the vendor, completely unmodified. The example program used is "mesh light" (relative path: v2.9.0\nrf\samples\bluetooth\mesh\light), which was compiled and run directly without any changes. The nRF52840DK is indeed working properly for debugging. Now I want to modify the CPU frequency of the nRF54L15-DK to 64MHz to test its functionality. However, I clearly haven't found any relevant macro definitions that can reduce the main frequency from 128MHz to 64MHz.

Regards,

Listen

[listenYes]

Hi,

This issue can now be attributed to a misunderstanding. Through testing, I found that the problem described in"(1) In VS Code, except for the 'Stop' and 'Pause' buttons, other debugging buttons are grayed out and ineffective (I think the debugging is already running at this time). After clicking the 'Pause' button and then clicking the 'Restart' button, subsequent debugging will most likely fail."is caused by slow debugging startup.

Specifically, it takes approximately 10 seconds after clicking the 'Debug' button to enter the debugging interface. At this point, only the 'Stop' and 'Pause' buttons are available. I need to wait an additional 30 seconds for other buttons to become active before normal debugging can proceed. In other words, the total time from clicking the 'Debug' button to enabling full debugging functionality is excessively long.This resulted in my incorrect conclusion that debugging was impossible.

As a result, debugging in VS Code has been a disastrous experience for me. After SEGGER Embedded Studio was discontinued, I tried VS Code debugging but eventually abandoned it and switched to Ozone. Ozone worked stably on nRF52832 and nRF52840, but encountered issues with nRF54L15. Previously, I provided detailed explanations along with "Generate Support Information" as requested.
My current core question is: How to debug nRF54L15 using Ozone?

Regards,

Listen

[Elfving]

listenYes said:

As a result, debugging in VS Code has been a disastrous experience for me. After SEGGER Embedded Studio was discontinued, I tried VS Code debugging but eventually abandoned it

I am sorry to hear that. 

Since I am not seeing this on my side in VSC, I then immediately wonder if you are seeing this on other systems as well, or just this one computer. Is this something you could test? After all, how long this takes can vary a bit depending on the system, even though 30 seconds seems like way too long. The 54L might spend a bit longer than the other single-core nRFs though, like nRF52840.

Our VSC team do not immediately see what this could come from either.

listenYes said:

Ozone worked stably on nRF52832 and nRF52840, but encountered issues with nRF54L15. Previously, I provided detailed explanations along with "Generate Support Information" as requested.
My current core question is: How to debug nRF54L15 using Ozone?

Could you check the log in Ozone? Getting Ozone working should be rather straight forward, though I, like you, did see some issues when trying this on an NRF54L. If I check the log there in Ozone, I see that it complained about me having \n in my path.

Util.Log ("Downloading Program: c:\\nordic\\ownApplications\\hello_world_29\\build_1\\merged.hex"); - Invalid escaped character '\n' found in parameter 1 at position 24

Regards,

Elfving

[listenYes]

Hi

I used two computers: one is a brand-new laptop that was just activated; the other is a desktop that had been reinstalled. Both computers took an extremely long time. However, I need to clarify: since I could not directly pull the source code from the nRF Connect for Desktop software, I used the vendor-packaged source code and toolchains for local installation.

I reviewed the following Ozone logs, and it appears we encountered the same issue. The log content is as follows:

Regards,

Listen

[Elfving]

I find it strange that this is something it happens to care about now, just for the nRF54L, though does using a different path help for you?

Regards,

Elfving

[listenYes]

Hi,

I'm very sorry, but I don't quite understand what you mean. However, the issue I'm currently concerned about is still "How to debug nRF54L15 using Ozone?" Moreover, the error warnings in my Ozone logs are the same as what you've encountered. They all show the message "Invalid escaped character '\n' found in parameter 1 at position 24".

Are you saying that fixing this error can solve the problem? But it seems that I can't find a way to fix it for now.

Regards,

Listen