We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Our team has developed a custom SoC with embedded flash blocks and a Cortex M0. Given that the code flash download routine will have to be customized, I am looking for some help and information on how to get started. The SoC as a 2 wire SWD interface built-in.
We are planning to use the Keil IDE and a Jlink debugger hardware. I am relatively new in this and might not be using the right technical terms, so do correct me if some of the questions are ambiguous.
Questions I have are
1. Given that most of the IDEs and Flash Programmers only define routines for known mainstream products; how do I get my compiled code into my custom Soc through the SWD interface?
2. Is there a platform where we can write SWD commands and include it into Keil as part of flash download routine?
3. Will code debugging / breakpoint still work with a custom routine?
4. Otherwise, do I need to run a separate Flash Programmer software ?
Thank you in advance for all inputs.
The interface will work the same. The ITM/DWT/FPB stuff should work the same. The CM0 will generally lack features you didn't explicitly include.
You should be able to download and run from RAM, you could use a debugger script to LOAD the AXF rather than use the Flash Algorithm.
To go to flash you're going to have to write a custom loader, and select that as your Flash Algorithm under the Debug/Flash settings.
See C:\Keil528\ARM\Flash\_Template
http://www.keil.com/support/docs/3656.htm
http://www.keil.com/support/man/docs/uv4/uv4_fl_flash_algorithms.htm
https://arm-software.github.io/CMSIS_5/Pack/html/flashAlgorithm.html
Thanks for the reply, I will look through those links you included.
I understand running from RAM would be straightforward, but would not be ideal as we have a much smaller RAM space compared to the Flash. The initial intention is for code to run directly from Flash and RAM only used as temp storage for variables etc. It is still an option for testing/verification is the code size is small enough to fit in to the RAM.
Based on your suggestion, I will have to write a custom loader and download to the flash through Keil.
I have a few follow on questions regarding that.
1. I might have missed this in your answer but would all the debug features (breakpoints/etc) still work when running from flash directly as a read-only memory?
2. Where exactly does the custom flash loader routine get loaded? Is it on Keil or on the debugger micro or on the actual target SoC?
3. Which Keil MDK supports custom flashloaders? Was thinking of starting out with the free version for evaluation.
Appreaciate your help.
Debug features are dictated by the build options for the core. You have not specified any detail about that. Keil isn't modifying the FLASH on the fly, it will use core features like the FPB unit to do the breakpoints. The debugger is agnostic to the memory in use.
The loaders are small applets, they get loaded in target's RAM, and the debugger/flashing method interacts with them to write into your FLASH memory.
They are relatively small in size, but difficult to debug, you should be able to build the with the Eval/Lite versions.
Hi West,
Thanks for the quick reply. Things are starting to get a little clearer now.
I will have to find out what debug build options were used for our core, thanks for pointing that out.
Also good to know the debugger is code memory agnostic.
I suppose having 8K of internal RAM is sufficient for the flash loader applet?
I have always thought that the flash loader is something done at Keil or the debugger Jlink level and what it does is to generate corresponding SWD operations directly the M0 processor.
Is there some material somewhere that I can refer to have an idea how the flash loader applet (in the target) interacts with commands/inputs coming in from Keil/Jlink through the SWD?
ARM provides SWD protocol information to IP licencees, there are also application notes / docs for debugger writers.
Suffice to say the connection allows registers within the core to be read, written, access to memory/buses, and execution of code. Links to flash loader development docs/info were provided earlier, additional material can be searched from there.
The FLASH implementation is outside the core, what and how it works depends on how it was designed, and is not the responsibility of ARM, Keil or Segger to implement. Usually SoC development teams have staff with responsibilities for various implementation, integration, testing and coding. Keil and TI, for example, might work together on parts that sell millions of units. ACME Random ASIC Co. less so, and likely to incur NRE charges to provide engineering support/services.
Noted. Will explore those links you provided.
Thank you for your help so far.