IAR Code is working in Debug mode but not in release mode - iar

I am working on a LPC1857 controller programming using IAR workbench. The code which I have developed is working in debug mode as expected, but when I switch to release mode, the code is not giving response.
My bootloader & application code is different, Is there anything which could be related to memory? I am not aware where can I monitor this or configure it during code download in controller.
I have turned ON LED on the board at bootup and written a code such that when it will receive any input, it will turn off the LED. In release mode, the board is turning ON the LED but after receiving the command it is not turning OFF it, while same scenario is working in debug mode of operation.
Need to modify the code/settings such that it would work in release mode as well.
Please guide
Thank you

Related

How to debug host code in mixed cuda C++ program?

My work platforms are VS2010 and Nsight 3.1.
With Nsight, breakpoints can be set in cuda kernel and the debugger works well. If the breakpoints are set in host code, Nsight just ignores them.
I don't know if it is possible to set breakpoints in host code and use the debugger provided by VS2010. I tried, but the program stops when it meets the first cudaMalloc function. Could someone please tell me how to debug host code in a mixed cuda and c++ program?
Thanks a lot.
I'm afraid you could not debug both CUDA and c++ program in on VS. Here is a workaround. Hope it could help you
Launch a Windows command line. Set NSIGHT_CUDA_DEBUGGER=1
In this command line, execute your CUDA application (Here I suppose it's a long-term execution).
Open a VS. Tools menu ->Attach to Process. Choose transport as Nsight CPU Debugger and attach to your application. Then you could debug CUDA code
Open another VS. Choose transport as Default. Attach to the application then you could debug C++ code
Please pay attention, if the application is suspended by a VS, it could not be debugged by the other VS. You must resume current one and then switch to the other.

How to burn a program in flash in IAR Workbench?

I am using IAR Embedded Workbench IDE to develop an embedded solution for the Renesas RL78/G13. I am able to compile and run the project in debug mode. Now I would like to burn the program to flash in release mode. Can someone tell me how to do this?
Maybe the answer is a little bit late, but another option straight from IAR is to go to Make [F7 key] the project and the go to Menu Project -> Download -> Download active application.
Be carefull that the Reset line of the microncontroller is free so nothing sets it to OV, which will stop the microcontroller from running
IAR version for RL78 1.40.1
Certainly, you can use the Renesas Flash Programmer for downloading the hex file into the microcontroller. The Renesas flash Programmer install package, you can get from the website from supplier.

Release build debugging issue

I have a fairly standard C++/QT app that works fine in debug and release on my development PC. When trying out the release version on a clean PC it runs but part of the functionality (showing video via a USB connection) just doesn't run. Well, seen this before and my standard technique is to add debug information to the release build, setup remote debugging and have a look. Much to my surprise, it runs fine as a release build with debug info (.pdb)
I have never seen this before.
using dependency walker shows no problems with any dependencies. Using the profiler that is a part of Dependency Walker and it also runs perfectly.
I have run out of debugging techniques and the only thing I can think of is to add message boxes at various places which in a multi threaded application does not seem a good idea.
Is there a debugging technique that could help me find this problem? We're using VS2008 and Qt 4.7.1.
Refine your message boxes - use a log file.
From your description, it seems to me that there may be some sort of race condition/timing issue that gets solved when some thread or other gets slowed down by being observed by something. Or by adding debug info to the binary.
Using a log file with timestamps, you should be able to keep track of when things happen.
I think logging is your friend. If you have multiple threads you may want to log each thread to different log file.

How to debug using RTSM simulator in eclipse (for DS-5) for FreeRTOS?

I am new to FreeRTOS and RTSM simulator. I loaded the code of FreeRTOS and am trying to use the RTSM simulator (simulates ARM Cortex A9). When I change to DS-5 debug perspective and press Debug from Debug Configurations, the simulator seems to be running. The problem I am facing is that I am not able to step through my source code (for debugging). I put a break point in the first statement in main, and the control doesn't seem to be reaching there. (I am able to step through the assembly language code produced after compilation, but that is not what I need).
Any idea how to do this?

Dealing with full-screen crashes on Mac, using command-line LLDB

I'm trying to debug a crash in a full-screen Mac game I'm working on, but when I have LLDB attached it just causes the game to freeze when the crash happens, and I can't get away from the game - I need to do a hard reset on the computer. Is there any kind of tool or preference for doing this? The computer I'm using to reproduce the crash doesn't have multiple monitors.
Can you do two-computer debugging? Set up an ssh account on the game-running machine, log in to it remotely (command line in Terminal) from your not-game-running machine, run command line lldb on your game. (process attach -n <appname>)
In the past, with gdb, Xcode had support for "remote debugging" which was this arrangement (Xcode running on one Mac, your full-screen game on the other) assuming you already had ssh configured correctly. I don't believe Xcode currently supports remote debugging with lldb - I'd encourage you to file a bug report at http://bugreport.apple.com/ registering your need for this feature if it's something you need in your workflow.
I'm afraid I can't think of any answers for you off-hand if you're doing single-machine debugging.