I am using Keil uvison 5 Evaluation version. After Run/Stop the code in debug mode it shows 0% coverage for each function in my C project.
What steps need to be followed for getting the code coverage?
Unfortunately, common debuggers are unsuitable to trace code execution.
Tracing user code avaliable only with UlinkPro debugger (and also without real hardware - in Keil simulator).
More information: http://www2.keil.com/coresight/#etm
Related
I am using PICKIT 4, PIC16F18446 microcontroller, and MPLAB X IDE. I am following an instruction provided from Microchip, Measuring frequency
Update:
I am not entirely sure what i needs to change but I am consistently getting an output of Frequency: 25536 whether there is an input signal or not. (Image of the output, and pin configuration shown below)
The Original Poster is using a PIC18 tutorial for a PIC16F target.
The MPLABX Code Configurator (MCC) tool is an awful thing for anyone new to the Microchip development tools to use.
An MPLABX project that does what I think this tutorial is about for the PIC16F18446 target is here in my git hub repository.
MCC was used to create most of this code so you should be able to see how it was done.
This code runs in the MPLABX simulator but that is a buggy hot mess. Use it with caution.
I'm using MCUXpresso with a C++ project on a Cortex M0+.
Today I ran into an issue: my very simple try catch block was not working, it was always calling the terminate handler.
I found out the issue was due to newlib-nano having exceptions handling disabled by default. See https://answers.launchpad.net/gcc-arm-embedded/+question/230716.
In this project, I don't want to use newlib, it would simply not fit into the small flash of the chip I am using.
I am re using a lot of code using exceptions, I would rather spend some time adding the support to newlib nano than modify all the existing code base...
So for someone who has never built an ARM lib, what would be the steps to follow to build libstdc++ (nano version, toolchain version 8.3.1) with exceptions enabled on Windows?
ARM DS-5 IDE talks about separate debug and trace features. I am an app developer, who is not used to these terminologies for ARM devices.
Can someone explain what is the main difference between trace and debug on ARM based SoC and when would you use each of them?
In ARM Architecture (also in general), debugging divides into 2 modes.
Invasive Debug
Noninvasive Debug
Invasive debug is similar to what you do when you debug a desktop application. CPU (Program execution) halts, you see the CPU/Program stack and can modify it
Noninvasive debug means you are not stopping cpu/program execution, you are only observing it hence can't modify it. "Trace" falls into this type of debug mode(noninvasive).
For more information: https://developer.arm.com/documentation/ddi0433/c/debug/debugging-modes
I am developing an application that I compile with the IAR Embedded Workbench solution. In this application, I have embedded the expat library - a tiny XML parser that works fine - which uses the time() standard function to generate a salt, as you can see in this chunk of code:
static unsigned long
generate_hash_secret_salt(void)
{
unsigned int seed = time(NULL) % UINT_MAX;
srand(seed);
return rand();
}
It appears that the time() function works fine on semihosting mode (while debugging with the J-link JTAG device by Segger, I guess) but does not work at all when I am running my application without the j-link debugger.
So I've run into the assembly code of time() function - which actually appears to be a proprietary implementation by IAR - and saw this single instruction:
BPKT #0xab
By seeking information through the web, I came up with the following paragraph:
If required, a debugger can use it to store additional information
about the breakpoint. ARM does not recommend the use of the BKPT instruction with an immediate
value set to 0xAB for any purpose other than Semi-hosting.
Is it due to such an issue? I must admit that my knowledge in ARM assembler is poor, and since I cannot debug my application while it is not on semi-hosting mode, I am pretty confused.
For your information, regardless of the argument you may pass to time(), it is always freezing in non semihosting mode.
Finally, what could you suggest me to do in order to bypass such an implementation? Shall I import another one into my C project? ...
Thanks
You're right that this breakpoint instruction is being used to trigger some kind of semihosting operation. If your code contains such instructions, you'll need to always run it attached to a debugger that knows what to do when such an instruction is encountered. If you need to run the device standalone, find out what code you're using that causes the semihosting operations to take place, and make sure that code isn't in the standalone build. This situation is a good opportunity to set up "debug" and "release" builds of your software - maybe using #ifdef DEBUG or something along those lines to exclude the semihosting code from your release build.
In this specific case, it looks like your C library's time implementation is using semihosting to get the host time over the debugger connection. You'll have to come up with a different solution if you want to run your program disconnected from the debugger.
I'm trying to generate C code from a Matlab-Simulink simple model (eg.: sine wave generator with a DAC at the output). This code must be executed with Code Composer Studio
for TMS320C6748 DSP (Texas Instrument C6748). Specifically, for the development board OMAP-L138 ZOOM ™EVM DEVELOPMENT KIT.
For this, I am using the following versions:
Simulink (Version 7.7 - R2011a)
Embedded Coder (Version 6.0 - R2011a)
Code Composer Studio v3.3
I tried several options (with generic modules in Simulink and programming the C6748 timers, configuring a module "Target Preferences" with "OMAP_L138/C6748 EVM"...) but it isn't working.
Is it possible to implement this idea? Is there an example working?
Thanks
Code generation for OMAP-L138 EVM / C6748EVM is supported in Simulink in R2011a. Before opening the Target Preferences block, import the processor definitions from DSP/BIOS. On the MATLAB command line, type the following:
getDspBiosFolder % This returns which DSP/BIOS MATLAB is seeing. If the value returned matches your installation of MATLAB, then you are OK. Otherwise, you need to use setDspBiosFolder to set the installation folder for DSP/BIOS (i.e. setDspbiosFolder('C:\CCStudio_v3.3\bios_5_33_06') on MATLAB command line).
importDspbiosConfig('proc', 'all')
importDspbiosConfig('board', 'all')
After these steps, you should be able to open the Target Preferences block and examine the settings. Before proceeding with code generation, run checkEnvSetup() utility to make sure that you installed all TI software required for code generation:
checkEnvSetup('ccs', 'omapl138evm', 'list')
The command above gives you a list of what you need to install. After making sure you have all of the software installed above with correct version numbers, execute the following:
checkEnvSetup('ccs', 'omapl138evm')
This sets all environment variables needed for code generation. MATLAB sees the location of the tools through environment variables created this way.
After these steps you should be able to generate code.
Code generation for OMAP-L138 EVM and C6748 EVM is not supported for older versions than Matlab 2011a.
For the release 2011a, the setup process is not trivial and it is not well documented. But Matlab has a patch for this version supports and works with certain specific requirements.
The release 2011b has improvements (hyperlinks required for products of thirds work with CCStudio v4 for this processor) and supports code generation for OMAP-L138 EVM and C6748 EVM.
For the release 2012a, Matlab has considered adding specific sections in the documentation for configuration and automatic code generation with these processors.