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

[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

[Elfving]

Hi again, and thanks for waiting during the Easter holidays,

Is there any update on this issue from your side?

So there seems to be two issues here, Ozone blaming the path, and VSC debugging being slow. I can reproduce the former, not the latter. The relevant R&D team have also not seen anything about the latter problem before. It could be that it stems from you getting the source code from a vendor-packaged source, like you mentioned. The relevant R&D team suggests that experimenting with "west debug" from CLI might be a way forward.

Though if you are mainly interested in Ozone, I guess we can just focus on that part, since I can also reproduce that on my side.

listenYes said:

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.

It did seem that way, though I find that when I try on my side it blames something else in my path.

Regards,

Elfving