RAM Retention Troubleshooting

RE: RAM Retention Troubleshooting

EyalR — Mon, 28 Apr 2025 15:07:05 GMT

I spoke to an embOS representative and they indeed confirmed that OS_InitKern() initializes RAM section that is defined as stack, which just happens to be RAM7 section 1 in my implementation. I'll mark this as answered, thanks for the help

RE: RAM Retention Troubleshooting

EyalR — Mon, 28 Apr 2025 08:30:29 GMT

No I can't access that function, nor do I see any specific details about it in embOS guide. I can only assume there is some different memory map\linker file for embOS in the project files.

Do you have any idea why writing to 0x2000F000 causes system crash but writing to 0x2000F001 is fine?

RE: RAM Retention Troubleshooting

Simonr — Mon, 28 Apr 2025 07:40:50 GMT

Okay, then it does indeed sound like something is trying to initialize this part of the RAM somewhere, but not being well versed in embOS, it's difficult to pinpoint where that might be, and I guess it will be for you as well if you didn't write the code/project in the first place. Are you able to see where the RAM is initialized exactly?

Best regards,

Simon

RE: RAM Retention Troubleshooting

EyalR — Sun, 27 Apr 2025 11:26:07 GMT

I managed to see now that RAM is indeed retained but after the call to OS_InitKern(), which is the very first line of code, the RAM is then initialized to 0xCDCDCDCD. I assume then that this is an embOS related issue. We are using embOS-Safe in our project

RE: RAM Retention Troubleshooting

EyalR — Sun, 27 Apr 2025 07:10:04 GMT

Hi Simon,

Currently 48k out of 64k RAM is used when building the project.
I've attached the RAM breakdown from the build. I'm looking into RAM7 Section 1 which starts at 0x2000F000

When is this heap initialization to 0xCDCDCDCD happening? It persists through reset so it's not just from the initial build.

About what the device does, it has BLE capabilities but specifically in the section I am testing the BLE task isn't running and GAP and such aren't even initialized.

Before going to sleep the device saves an expected wake up reason to GPREGRET. It then goes to sleep and I wake it up by GPIO by pressing a button. The device wakes up, initializes embOS, and then compares the wake up reason from RESETREAS to the one retained in GPREGRET. If it doesn't match then it goes back to sleep. Part of the going to sleep routine is also to retain RAM7 section 1. The device does many other things but this is the current functionality that I'm testing.

About using the example, like I said this is not my code. Someone else wrote it and we've discovered a bug and now I'm trying to reverse engineer it - I don't have the option to start a new project based on an example because this is an existing device.

RE: RAM Retention Troubleshooting

Simonr — Fri, 25 Apr 2025 11:22:42 GMT

When building your application, how much RAM does the application itself take? I think somewhere in your application you have reserved the area you're trying to write to. 0xCDCDCDCD is used by C/C++ malloc() to mark uninitialized heap memory, so that could be a point in the right direction. Have you used the RAM retention example project in the SDK for reference or are you implementing the RAM retention "free hand"? https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ram_retention_example.html

I'd strongly suggest you refer to the RAM retention sample, and then trying to implement it step by step and see at what point it crashes. What else than RAM retention does your project do? I assume you do some radio operations as well since you are using the SoftDevice.

Best regards,

Simon