[SOLVED] Emulate whole RAM?

apullin · May 29th 2018, 3:54am

While working with large (800K+) images on a Cortex M4, I often find myself waiting a *long* time for the chip to erase and flash.
If a small piece of code is changed, it can cause everything to be shifted in the flash address space, and thus require a major erase & reflash, even with the SEGGER option to only reflash the sectors as needed.

Is there any ability to emulate a micro's entire RAM via the JLink? There would be a big runtime speed penalty, like flash with a lot of wait states, but it seems like it might be an option.
But it could potentially completely skip the flash step.

Surely this would also require the right set of remapping features from the silicon implementation, but the manual says that is some level of support for both flash and RAM remapping, and I am not familiar with the details of how much the debug port can intercept the regular internal buses.

SEGGER - Nino · May 30th 2018, 2:10pm

Hi,

Thank you for your inquiry.
To make sure we understand you correctly, you are looking for a option to use J-Link as "external RAM" for any target device so no target download needs to be triggered if the application shifts?

Best regards,
Nino

apullin · Jun 1st 2018, 8:29am

Yes, the ultimate goal is to avoid very long reflash times of the physical on-chip flash.

Now that I think about it, it would be equivalent to just using a remapped flash address block, too.
I only thought of it as "RAM emulation" just because that trick sometimes works for smaller programs and happens to exist in the makefile in the SDK that I am using, where they can be built to locate entirely in the RAM section.

As far as I understand it, I think this is how how "ICE" tools used to work way back in the day, that it truly emulated the whole chip, and effectively just used the package as the interface to the circuit?

And there is potential a feature for the Segger linker here, too, if it could be made to disperse functions throughout the flash area intentionally, and/or align to sector boundaries, in a way that could minimize the need to shift large contiguous code segments.

SEGGER - Nino · Jun 6th 2018, 9:26am

Hello,

The issue with this approach is that there is no generic way to implement this which would work for all target devices that J-Link supports.
This limits re-usability for a feature that would be rarely used that might only work with a hand full of target devices which is not viable for us from an economic point of view.

Best regards,
Nino

SEGGER - Erik · Jun 11th 2018, 11:05am

Hi,

apullin wrote:

I only thought of it as "RAM emulation" just because that trick sometimes works for smaller programs and happens to exist in the makefile in the SDK that I am using, where they can be built to locate entirely in the RAM section.

Please note that emulation is the wrong term because you refer to simply changing the linker to the internal RAM of the device instead of the flash section.
Emulation would mean that the application will not be downloaded to the target but to some kind of RAM on PC / host side. In this scenario, the entire execution would need to be emulated by the J-Link as well because the CPU would not have access to the emulated memory on the PC side thus cannot execute the code. At the latest when it comes to device specifics like peripheral functions or SFRs, emulating will not work as the CPU needs to execute the instructions.

There are two different options (both are supported by the J-Link):
a) The application is downloaded to the flash
b) You configure your linker to link the application into the RAM of the device

If the application is too large for the internal RAM, b) is no option. Apart from this, the timing will be slightly different when executing the application from RAM compared to the execution from the flash.

Best regards
Erik

Share