Did you reset the target between the 2 tests?
Did you reset the target between the 2 tests? No.
I did the test in the order specified and without interruption 
Ok, so let me change the steps 
- Give a try with the preference checked: after some tries you should fall in timeout.
- If you fall in timeout, reset the target and make sure it answers to AT commands again.
- Give a try with the preference unchecked: and please tell if it is OK or not…
Power cycled the device. opened DS and checked preference.
1. Give a try with the preference checked: after some tries you should fall in timeout. Refreshed 10 times without problem
compile and upload MMS demo with preference unchecked. Timeout error after DWL file uploaded.
recheck preference
1. Give a try with the preference checked: after some tries you should fall in timeout. Timeout error first attempt
2. If you fall in timeout, reset the target and make sure it answers to AT commands again. Cycled power. Answered OK to AT
3. Give a try with the preference unchecked: Refreshed 10 times without problem
immediately tried step 1 again
1. Give a try with the preference checked: after some tries you should fall in timeout. HAPC AT test error first attempt
OK so let’s keep the preference unchecked.
And also, as soon as you get a timeout error, please:
- check if AT command answers in the console
- if not, cycle power and check again
Now, let’s have a look to the download issue.
How do you download your application?
We should make a test to check if the application behavior at initialization is disturbing the information loading or not…
Phase A: make sure the application is stopped
Please do 10 times:
- reset the unit
- just after, try to reload information in the target status view
Phase B: make sure the application is started
Please redo the same steps…
What I’m suspecting is that when the application starts, and DS try to reload information at the same time, it seems that this is an additional cause for the “Development Mode frozen” bug to occur…
How do you download your application? In Run Configuration double click “MMS [Target]_ARM_EABI_GCC_Debug”
We should make a test to check if the application behavior at initialization is disturbing the information loading or not…
Phase A: make sure the application is stopped following on from actions in last post. stopping application timeout, Cycled power, AT ok, stopped application ok[i]
Please do 10 times:
- reset the unit[/i] Cycled power, … then
* just after, try to reload information in the target status view OK, … x 10
Phase B: make sure the application is started OK running
[i]Please do 10 times: - reset the unit[/i] Cycled power, … then
* just after, try to reload information in the target status view OK, … x 10
What I’m suspecting is that when the application starts, and DS try to reload information at the same time, it seems that this is an additional cause for the “Development Mode frozen” bug to occur…
I think there are other issues as well. Even when send AT returns ok and app is running can’t get app to respond to commands
Are you using any low power modes in your application (e.g. W32K sleep mode)?
Please can you try to download your app through other ways (right-click menu on the project, or download action in the Open AT Application section of the Target Status view)?
With and without the app running?
The steps are not exactly the same than when the Run Configuration is used…
Did that for both successfully.
Test was OK too
Ok so it sounds like something going wrong with the Run Configuration only…
While you don’t need to debug the app, as a workaround I suggest you to use the download facilities rather than the Run Configuration.
Meanwhile, we’re going to dig deeper to find a solution for the Run Configuration handling…
I do need to debug the app. It does not work.
The adl_atSendResponse function in any of the call backs does not respond to the console.
Do you have any ideas?
/* AT+GPRS="apn","uname","passw" */
static void gprs_hdlr ( adl_atCmdPreParser_t* params )
{
TRACE ( ( 4, "void gprs_hdlr() enter " ) ); //Debug
adl_atSendResponse ( ADL_AT_RSP, "\r\nGPRS enter\r\n" ); //Debug. This does not show in console
if ( params->Type == ADL_CMD_TYPE_PARA )
{
if ( params->NbPara == 3 )
{
wm_strcpy ( gprs_apn, ( ascii* ) ADL_GET_PARAM ( params, 0 ) );
wm_strcpy ( gprs_uname, ( ascii* ) ADL_GET_PARAM ( params, 1 ) );
wm_strcpy ( gprs_passw, ( ascii* ) ADL_GET_PARAM ( params, 2 ) );
adl_atSendResponse ( ADL_AT_RSP, "\r\nOK\r\n" );
TRACE ( ( 4, "void gprs_hdlr() OK " ) ); //Debug
start_gprs ( gprs_apn, gprs_uname, gprs_passw );
}
else
{
TRACE ( ( 4, "void gprs_hdlr() ERROR GPRS " ) ); //Debug
adl_atSendResponse ( ADL_AT_RSP, "\r\nERROR GPRS\r\n" );
}
}
else if ( params->Type == ADL_CMD_TYPE_TEST )
{
ascii buf [ 256 ] = { 0 };
wm_sprintf ( buf, "\r\n+GPRS: 32,32,32\r\n" );
adl_atSendResponse ( ADL_AT_INT, buf );
adl_atSendResponse ( ADL_AT_RSP, "\r\nOK\r\n" );
}
TRACE ( ( 4, "void gprs_hdlr() exit " ) ); //Debug
}Trace
2013/01/16;17:39:41:212;001;ADL;4;void gprs_hdlr() enter
2013/01/16;17:39:41:213;001;ADL;4;void gprs_hdlr() OK
2013/01/16;17:39:41:215;001;ADL;2;-24 <- wip_bearerStart()
2013/01/16;17:39:41:216;001;ADL;4;void gprs_hdlr() exit
Console
Initialising …
AT+GPRS=‘mms’,‘411’,‘optus’
So what would be a workaround to compile the code and upload the dwl file successfully in the meantime?
I am also getting a WIP_CERR_INTERNAL error
if the HTTP data channel cannot be created or MMS total size exceeds 300KbTrace
2013/01/16;17:40:16:127;001;ADL;4;wip_mmsSend( ) returns -995
I am only sending a text message to test the system.
Concerning your response issue, it’s because you need to specify the port of the target where you want the response to be sent. There are macros to support this (adl_atSendRspPort AFAIR…). You can get the port identifier from which the command has been received in the adl_atCmdPreParser_t structure.
For the WIP issue, you should ask in the dedicated forum thread…
It’s true that using run configurations is convenient to build + download in one click.
A workaround can be to enable the automated build when you save a file (Project properties > C/C++ Build > Behavior > Build on resources save). It’s not perfect (trends to trigger the build several times for a single file save…) but it can make you sure that what you download (out of the Run Configuration) is always up to date…
We still have to take some time to try reproducing the troubles you have with the Run Configuration, in order to find another workaround if possible.
Can you just remind me if you’re getting troubles also with a simple Hello World app?