Trace L3RR 1 Unable to find the string of the remote trace in the file (ID = 4102)
Trace L3RR 1 Unable to find the string of the remote trace in the file (ID = 4795)
Trace 1 Unable to find the string of the remote trace in the file (ID = 22626)
Trace L3RR 1 Unable to find the string of the remote trace in the file (ID = 5573)
Trace CUS4 1 Arm exception 1 1059fb2 a0000
ADS Bckt -> mem_AppReleaseMemory : 0x0021AE13
ADS Bckt -> adlint_osReleaseHeapMemory : 0x002274A6
after that module resets. There is an ARM exception which is possibly caused by illegal memory access. But I want to learn exact place of exception in my code. How can I do that?
Hi Piedos
The quickest way that I found to trace an exception error is to put alot of traces in my code and then I look at what was the last one executed before the “crash” and then you put more traces after last executed trace and then can you narrow it down to the excact “CRASH”
The problem is I can’t monitor the
TRACE( ( 1, “my message” ) );
strings in TMT. I have 500 TRACEs in my code.
in AUG_ADL_User_Guide_for_Open_AT_V310_rev007.pdf document page 39:
When the Debug configuration is selected in the used IDE (or with the wmmake
command), the DEBUG_APP compilation flag is defined, and also the
following macros.
• TRACE (( u8 TL, ascii * T, … ))
I use visual C++ 6 (IDE) not the cygwin command line environment. So how can I enable my traces in visual C++ ?
Reset caused by illegal RAM WRITE ,since TRACES don’t work , I cannot find the error point.
Hi Piedos
I am confused now because I use trace in RTE and target mode without problems.
I do not understand why it will not work?
What happens when you run the hello_world app?
Do you get traces then?
Hi Piedos
I think your firmware is corrupted.
Use the firmware supplied with the Open AT version to reload the fimware
in this order [color=red]dwl.dwl then [color=red]full.dwl and then the [color=red]w.dwl file.
After reloading the firmware then you can retry to run the openat app.
did you use the standard generate Traces workspace ? you will find the file on path \gcc\out\tmt\gcc.wks of your project path.
Open this file first of all in Target Monitoring Tool (instead of default GPRS-GSM.wks) and then start to choose your trace level in CUS 4. This is the base to develop with OpenAT.
Furtherly,
if you experience such kind of problems, often you can identify the problem nature : mem_AppReleaseMemory means that in a function you called adl_memGet function to allocate memory to a variable but you forgot to call adl_memRelease(… ) at the end of the func.
When you want to know what is behind obscure traces like “Unable to find the string…” you have to ask wavecom or your distributor if you can obtain the complete traces workspace. But this is helpful only when you have very strange GSM behaviour and not simple OpenAT programming errors.
Re-compile your software, reflash the module, configure the TMT as I described and try again.