| View previous topic :: View next topic |
| Author |
Message |
tkm
Joined: 18 Jan 2011
Posts: 72
|
 Posted: Thu May 26, 2011 6:18 pm Post subject: How to know ME/Turbo is done with buf_B? |
 |
|
Hello,
Is there a way to know Me/SIM/Turbo has completed it's last work with buf_B()? I am asking ME to redirect an SMS in my SMS control which is duplicate to call control. However, after retval(ret), I need to send another SMS which seems to overwrite buf_B and original SMS is not send out. But the followiing/2nd SMS is being sent out. Hence, if I could find a way(return value) that ME/Turbo is done with buf_B from my previous command only then I would have executed my second send_sms which would have sorted my problem, I would think. Any help would be much appreciated. Thank you.
| Code: | void sms_control (u8 * s)
{
j = get_tag (s, T_ADDRESS);
if(stat == CALL_STAT_MODIFY)
{
}
if (stat == CALL_STAT_ALLOW)
{
}
if (stat == CALL_STAT_CANCEL)
{
}
ret = 0x9F00 | sms_resp_call_len;
dbsp ("CALL RET ");
dbih (ret);
dbc ('\n');
sms_resp_call[sms_resp_call_len] = 0x90;
sms_resp_call_len++;
sms_resp_call[sms_resp_call_len] = 0x00;
sms_resp_call_len++;
retval (ret); //sending the first sms
smsplus_sms(s);//sending second sms
} |
| Code: | void smsplus_sms (u8 * s)
{
send_sms(sms, sizeof(t_sms_ex), ms, MSISDN_ADN, 0xF6, 0, NULL, NULL);
} |
| Code: | case ACTION_FILE_APDU:
if (((File_apdu_data *) data)->prev_ins == ME_CMD_ENVELOPE
&& ((File_apdu_data *) data)->ins == ME_CMD_GET_RESPONSE)
{
u8 *r = buf_B ();
dbsp ("CALL FILE APDU SMS\n");
for (u8 i = 0; i < sms_resp_call_len; i++)
{
r[i] = sms_resp_call[i];
}
}
case ACTION_MO_SMS_CONTROL:
sms_control (data);
break;
|
Just to add: The first SMS is user driven and the second sms is application driven. |
|
| Back to top |
|
 |
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Fri May 27, 2011 10:39 am Post subject: |
|
|
Anyone/Pavel?Pls... All I need to know is that how to realize that Turbo Toolkit has completed it's previous task on ACTION_FILE_APDU so that buf_B is free to use and I can execute my next STK_Command without invalidating previous buf_B content. Many Thanks.
| Code: | u8 *r = buf_B ();
dbsp ("CALL FILE APDU SMS\n");
for (u8 i = 0; i < sms_resp_call_len; i++)
{
r[i] = sms_resp_call[i];
}
|
At which point is it safe to realize buf_B is free? |
|
| Back to top |
|
|
pz
Joined: 12 Mar 2004
Posts: 1161
|
| Posted: Mon May 30, 2011 5:52 am Post subject: |
|
|
buf_B() is a general buffer used for every APDU received from phone and used for answer sent back to phone.
If your example is to work like that you first handle sms_control(), store something into buf_B() and then in next apdu want to return it then no - iit won't work, it will be rewritten by the incoming "next" apdu. So store that "something" into some other buf you malloced yourself.
Btw. shouldn't there be a "break;" before "case ACTION_MO_SMS_CONTROL: "? |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Tue May 31, 2011 10:16 am Post subject: |
|
|
| pz wrote: | buf_B() is a general buffer used for every APDU received from phone and used for answer sent back to phone.
If your example is to work like that you first handle sms_control(), store something into buf_B() and then in next apdu want to return it then no - iit won't work, it will be rewritten by the incoming "next" apdu. So store that "something" into some other buf you malloced yourself.
Btw. shouldn't there be a "break;" before "case ACTION_MO_SMS_CONTROL: "? |
Thanks Pavel for the reply. You suggested to store that "something" into some other buf I malloced. I did that or maybe I didn't quite get you. I thought all my response eventually needs to be passed to buf_B through retval(), which will be caught in ACTION_FILE_APDU and phone will read my response from buf_B. So after I stored my response in the buffer sms_resp_call I invoked retval which I understand triggered ACTION_FILE_APDU, where I need to copy over my response to buf_B inorder the phone to act on it. Please let me know if I thinking on the wrong line....
**I do have a break after my ACTION_FILE_APDU case in my original code but probably slipped out when I was copying over. Sorry for the confusion. |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Tue May 31, 2011 11:11 am Post subject: |
|
|
| tkm wrote: | | pz wrote: | buf_B() is a general buffer used for every APDU received from phone and used for answer sent back to phone.
If your example is to work like that you first handle sms_control(), store something into buf_B() and then in next apdu want to return it then no - iit won't work, it will be rewritten by the incoming "next" apdu. So store that "something" into some other buf you malloced yourself.
Btw. shouldn't there be a "break;" before "case ACTION_MO_SMS_CONTROL: "? |
Thanks Pavel for the reply. You suggested to store that "something" into some other buf I malloced. I did that or maybe I didn't quite get you. I thought all my response eventually needs to be passed to buf_B through retval(), which will be caught in ACTION_FILE_APDU and phone will read my response from buf_B. So after I stored my response in the buffer sms_resp_call I invoked retval which I understand triggered ACTION_FILE_APDU, where I need to copy over my response to buf_B inorder the phone to act on it. Please let me know if I thinking on the wrong line....
**I do have a break after my ACTION_FILE_APDU case in my original code but probably slipped out when I was copying over. Sorry for the confusion. |
In other words: in sms_control I am mallocing buffer to hold the reponse before passing over to retval.
| Code: |
void sms_control (u8 * s)
{
sms_resp_call=malloc (100);
sms_resp_call_len=0;
.........
........
stk_thread (smsplus_sms, s);
...................
retval (ret)
}
void smsplus_sms (u8 * s)
{
send_sms(sms, sizeof(t_sms_ex), ms, MSISDN_ADN, 0xF6, 0, NULL, NULL);
}
case ACTION_FILE_APDU:
if (((File_apdu_data *) data)->prev_ins == ME_CMD_ENVELOPE
&& ((File_apdu_data *) data)->ins == ME_CMD_GET_RESPONSE)
{
u8 *r = buf_B ();// should I not store here the response?
for (u8 i = 0; i < sms_resp_call_len; i++)
{
r[i] = sms_resp_call[i];
}
}
break; |
Hence, r u suggesting not to return to buf_B inside File_APDU? Many thanks.
Last edited by tkm on Mon Jun 13, 2011 9:36 am; edited 1 time in total |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Wed Jun 01, 2011 9:59 am Post subject: |
|
|
| Anything? |
|
| Back to top |
|
|
pz
Joined: 12 Mar 2004
Posts: 1161
|
| Posted: Wed Jun 01, 2011 1:17 pm Post subject: |
|
|
In ACTION_FILE_APDU you write/copy answer to buf_B(). I was trying to say that the content of buf_B() can be modified between sms_control() and ACTION_FILE_APDU.
Do you log it? The last code looks quite good, what do you see as passed to phone? Btw. don't forget to free the sms_resp_call. |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Wed Jun 01, 2011 2:23 pm Post subject: |
|
|
| pz wrote: | In ACTION_FILE_APDU you write/copy answer to buf_B(). I was trying to say that the content of buf_B() can be modified between sms_control() and ACTION_FILE_APDU.
Do you log it? The last code looks quite good, what do you see as passed to phone? Btw. don't forget to free the sms_resp_call. |
Many thanks Pavel. We used to log/debug a lot but because of continuing use of the TL2 with handset, I guess the TL2 cable has become quite dodgy. Hence, debugging became quite difficult now.
Nonetheless, I will follow your suggested method and share with you the outcome. I will try to load buf_B with my response in sms_control function after calling retval(). |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Wed Jun 01, 2011 4:02 pm Post subject: |
|
|
| pz wrote: | In ACTION_FILE_APDU you write/copy answer to buf_B(). I was trying to say that the content of buf_B() can be modified between sms_control() and ACTION_FILE_APDU.
Do you log it? The last code looks quite good, what do you see as passed to phone? Btw. don't forget to free the sms_resp_call. |
My last code sends out the second sms but not the original/first sms. But if I disable/don't call 'smsplus_sms(s)' than the first sms does go through. Pavel, if you think that my last code was good enough to send out two SMS one after another than I guess either there might be something wrong with my TL2 or 'not sure what' !!!
I have to say my Tl2 is close to broken and we are trying to order a new one, however, I hope the problem is not occuring because of semi-faulty TL2.
Pavel, I found out that modifying buf_B outside ACTION_FILE_APDU doesn't force ME to execute my request.
I am really though confused on how to tackle the TSIM issue which says 'buf_B' data gets invalidated if i call an STK command, which I think is happening in my case. Before/when my first sms is going to buf_B, I need to call send_sms, which is an STK command, which apparently is destroying the original sms/buf_B. |
|
| Back to top |
|
|
pz
Joined: 12 Mar 2004
Posts: 1161
|
| Posted: Thu Jun 02, 2011 9:01 am Post subject: |
|
|
I wonder what the log/debug will say (D. has already sent you an email on this).
Can you try to swap the order of stk_thread() and retval()? |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Fri Jun 03, 2011 4:44 pm Post subject: |
|
|
| pz wrote: | I wonder what the log/debug will say (D. has already sent you an email on this).
Can you try to swap the order of stk_thread() and retval()? |
Hi Pavel,
This is my full, well, important code stuffs:
And This is my log:
| Code: |
FROM ME: a0 c2 00 00 21
FROM ME: d5 1f 82 02 82 81 06 07 91 44 77 58 10 06 50 06 07 81 70 78 58 24 87 f4
13 07 32 f4 51 00 c5 5b f4
Debug begins
Going Forward
0058
Debug ends
CALL RET 9f14
Inside smspls_sms
Debug Ends SMS PLUS
TO ME: 91 26
FROM ME: a0 12 00 00 26
TO ME: d0 24 81 03 01 13 00 82 02 81 83 8b 19 01 00 0b 81 70 78 88 47 32 f9 00
f6 0c 37 30 37 38 35 38 32 34 38 37 66 34 90 00
FROM ME: a0 d6 00 00 02
FROM ME: 16 ff
TO SIM: a0 d6 00 00 02
TO SIM: 16 ff
FROM SIM: 90 00
TO ME: 90 00
FROM ME: a0 c2 00 00 21
FROM ME: d5 1f 82 02 82 81 06 07 91 44 77 58 10 06 50 06 07 81 70 78 88 47 32 f9
13 07 32 f4 51 00 c5 5b f4
Debug begins
Going Forward
0088
Debug ends
CALL RET SMS29f02
TO ME: 9f 02
FROM ME: a0 c0 00 00 02
sms_resp_call_len=
0016sms_resp_call_len_2=
0004CALL FILE APDU SMS2
TO ME: 00 00 90 00
FROM ME: a0 a4 00 00 02
FROM ME: 7f 20
TO SIM: a0 a4 00 00 02
TO SIM: 7f 20
FROM SIM: 9f 1e
TO ME: 9f 1e
FROM ME: a0 c0 00 00 1e
TO SIM: a0 c0 00 00 1e
FROM SIM: 00 00 c9 38 7f 20 02 00 66 6f ff 01 11 9b 00 22 09 00 83 8a 83 8a 00 80
80 80 80 80 00 00 90 00
TO ME: 00 00 c9 38 7f 20 02 00 66 6f ff 01 11 9b 00 22 09 00 83 8a 83 8a 00 80
80 80 80 80 00 00 90 00
FROM ME: a0 88 00 00 10
FROM ME: 13 a5 e4 fc af 07 e2 04 5f 82 4c 20 01 21 d4 a4
TO SIM: a0 88 00 00 10
TO SIM: 13 a5 e4 fc af 07 e2 04 5f 82 4c 20 01 21 d4 a4
FROM SIM: 9f 0c
TO ME: 9f 0c
FROM ME: a0 c0 00 00 0c
TO SIM: a0 c0 00 00 0c
FROM SIM: 0f 26 cc d3 40 1e d3 ab 0f b2 9d 3b 90 00
TO ME: 0f 26 cc d3 40 1e d3 ab 0f b2 9d 3b 90 00
FROM ME: a0 a4 00 00 02
FROM ME: 6f 20
TO SIM: a0 a4 00 00 02
TO SIM: 6f 20
FROM SIM: 9f 0f
TO ME: 9f 0f
FROM ME: a0 c0 00 00 0f
TO SIM: a0 c0 00 00 0f
FROM SIM: 00 00 00 09 6f 20 04 00 11 ff ff 01 02 00 00 90 00
TO ME: 00 00 00 09 6f 20 04 00 11 ff ff 01 02 00 00 90 00
FROM ME: a0 d6 00 00 09
FROM ME: 40 1e d3 ab 0f b2 9d 3b 05
TO SIM: a0 d6 00 00 09
TO SIM: 40 1e d3 ab 0f b2 9d 3b 05
FROM SIM: 90 00
TO ME: 90 00
FROM ME: a0 14 00 00 0c
FROM ME: 81 03 01 13 00 02 02 82 81 83 01 00
TO ME: 90 00 |
As I was saying, the second SMS overtakes the original/first sms and reaches destination. The first sms stays in the handset undelivered.
Please help me on this...........need to sent out both the sms.
Last edited by tkm on Thu Jun 09, 2011 9:10 am; edited 1 time in total |
|
| Back to top |
|
|
pz
Joined: 12 Mar 2004
Posts: 1161
|
| Posted: Sun Jun 05, 2011 3:59 am Post subject: |
|
|
Aaaah, ok. Easy fix, in sms_control() do not do stk_thread() at all, just retval().
Then in ACTION_FILE_APDU do the stk_thread() to send the sms. |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Mon Jun 06, 2011 11:27 am Post subject: |
|
|
| pz wrote: | Aaaah, ok. Easy fix, in sms_control() do not do stk_thread() at all, just retval().
Then in ACTION_FILE_APDU do the stk_thread() to send the sms. |
Thanks a lot, Pavel. I have tried that and looked into the log. It didn't work but I think I can see from the log what is stopping it.
This is my File Apdu case code after addopting your advise:
| Code: |
if(sms_resp_call_len>10)
{
u8 *r = buf_B ();
u8 i;
dbsp ("CALL FILE APDU SMS\n");
for (i = 0; i < sms_resp_call_len; i++)
{
r[i] = sms_resp_call[i];
dbih (r[i]);
dbsp ("\n");
}
dbsp ("\nAdding 90 for 1st SMS\n");
r[i]=0x90;
i++;
r[i]=0x00;
sms_resp_call_len=0;
first_sms=1;
free(sms_resp_call);
sms_resp_call=NULL;
dbsp ("\nStaring stk_thread for 2nd SMS\n");
stk_thread (smsplus_sms2, NULL);
dbsp ("\nComing out of APDU loop for 1st SMS\n");
}
dbsp ("sms_resp_call_len_2=\n");
dbih (sms_resp_call_len_2);
if(sms_resp_call_len_2>1)
{
u8 *r2 = buf_B ();
dbsp ("CALL FILE APDU SMS2\n");
u8 i2;
for (i2 = 0; i2 < sms_resp_call_len_2; i2++)
{
r2[i2] = sms_resp_call_2[i2];
dbih (r2[i2]);
dbsp ("\n");
}
dbsp ("\nAdding 90 for 2nd SMS\n");
r2[i2]=0x90;
i2++;
r2[i2]=0x00;
sms_resp_call_len_2=0;
free(sms_resp_call_2);
sms_resp_call_2=NULL;
}
|
And this is the log:
| Code: |
FROM ME: a0 c2 00 00 21
FROM ME: d5 1f 82 02 82 81 06 07 91 44 77 58 10 06 50 06 07 81 70 78 58 24 87 f4
13 07 32 f4 51 00 c5 5b f4
Debug begins
Going Forward
0058
Debug ends
CALL RET 9f14
TO ME: 9f 14
FROM ME: a0 c0 00 00 14
sms_resp_call_len=0016CALL FILE APDU SMS
Staring stk_thread for 2nd SMS
2nd SMS starts
Coming out of APDU loop for 1st SMS
sms_resp_call_len_2=
0000TO ME: 02 12 06 07 91 44 77 58 10 06 50 06 07 81 70 78 88 47 32 f9 91 22 (I think this is where it is going wrong. I think it should be 90 00 instead of 91 22 at the very end.)
FROM ME: a0 b2 72 04 1c
TO SIM: a0 b2 72 04 1c
FROM SIM: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff 90 00
TO ME: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff 91 22
FROM ME: a0 12 00 00 22
TO ME: d0 20 81 03 01 13 00 82 02 81 83 8b 15 01 00 0b 81 70 78 88 47 32 f9 00
f6 08 54 4d 6f 62 69 6c 65 00 90 00
FROM ME: a0 b2 73 04 1c
TO SIM: a0 b2 73 04 1c
FROM SIM: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff 90 00
TO ME: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff 90 00
FROM ME: a0 a4 00 00 02
FROM ME: 6f 43
TO SIM: a0 a4 00 00 02
TO SIM: 6f 43
FROM SIM: 9f 0f
TO ME: 9f 0f
FROM ME: a0 c0 00 00 0f
TO SIM: a0 c0 00 00 0f
FROM SIM: 00 00 00 02 6f 43 04 00 11 f6 ff 01 02 00 00 90 00
TO ME: 00 00 00 02 6f 43 04 00 11 f6 ff 01 02 00 00 90 00
FROM ME: a0 d6 00 00 02
FROM ME: 21 ff
TO SIM: a0 d6 00 00 02
TO SIM: 21 ff
FROM SIM: 90 00
TO ME: 90 00
FROM ME: a0 c2 00 00 21
FROM ME: d5 1f 82 02 82 81 06 07 91 44 77 58 10 06 50 06 07 81 70 78 88 47 32 f9
13 07 32 f4 51 00 c5 5b f4
Debug begins
Going Forward
0088
Debug ends
CALL RET SMS29f02
TO ME: 9f 02
FROM ME: a0 c0 00 00 02
sms_resp_call_len=0000sms_resp_call_len_2=
0004CALL FILE APDU SMS2
TO ME: 00 00 90 00
FROM ME: a0 a4 00 00 02
FROM ME: 6f 3a
TO SIM: a0 a4 00 00 02
TO SIM: 6f 3a
FROM SIM: 9f 0f
TO ME: 9f 0f
FROM ME: a0 c0 00 00 0f
TO SIM: a0 c0 00 00 0f
FROM SIM: 00 00 1b 58 6f 3a 04 00 11 f6 22 01 02 01 1c 90 00
TO ME: 00 00 1b 58 6f 3a 04 00 11 f6 22 01 02 01 1c 90 00
|
If you see the log where SIM is sending data to ME for 1st SMS it is wrapping 91 22 at the end, which I can't figure out why. I am passing 90 00 but that is being ignored. However, this doesn't happen when I send only the first sms. Any thoughts on how can I get rid of 91 22? Many thanks once again.
TO ME: 02 12 06 07 91 44 77 58 10 06 50 06 07 81 70 78 88 47 32 f9 91 22 (I think this is where it is going wrong. I think it should be 90 00 instead of 91 22 at the very end.)[/b] |
|
| Back to top |
|
|
pz
Joined: 12 Mar 2004
Posts: 1161
|
| Posted: Mon Jun 06, 2011 1:41 pm Post subject: |
|
|
No, the 91 22 is OK and it's result of the stk_thread() for sending the 2nd SMS. It says phone "there is a STK command long 0x22 bytes, fetch it." And as you can see in your log it follows with FETCH:
FROM ME: a0 12 00 00 22
TO ME: d0 20 81 03 01 13 00 82 02 81 83 8b 15 01 00 0b 81 70 78 88 47 32 f9 00 f6 08 54 4d 6f 62 69 6c 65 00 90 00
This is the sending of the 2nd SMS.
I assume you want the flow:
1. user send a sms (=1st sms)
2. you catch it with sms_mo_control and prepare body of 2nd sms
3. you use ACTION_FILE_APDU to modify where to send 1st sms (I think)
4. at the same time you start stk_thread() to send 2nd sms
5. phone ask for the second sms
6. there is sms_mo_control event for this 2nd sms
7. in ACTION_FILE_APDU you say "ok, send it"
Is this what you want? So what doesn't work? |
|
| Back to top |
|
|
tkm
Joined: 18 Jan 2011
Posts: 72
|
| Posted: Mon Jun 06, 2011 1:59 pm Post subject: |
|
|
| pz wrote: | No, the 91 22 is OK and it's result of the stk_thread() for sending the 2nd SMS. It says phone "there is a STK command long 0x22 bytes, fetch it." And as you can see in your log it follows with FETCH:
FROM ME: a0 12 00 00 22
TO ME: d0 20 81 03 01 13 00 82 02 81 83 8b 15 01 00 0b 81 70 78 88 47 32 f9 00 f6 08 54 4d 6f 62 69 6c 65 00 90 00
This is the sending of the 2nd SMS.
I assume you want the flow:
1. user send a sms (=1st sms)
2. you catch it with sms_mo_control and prepare body of 2nd sms
3. you use ACTION_FILE_APDU to modify where to send 1st sms (I think)
4. at the same time you start stk_thread() to send 2nd sms
5. phone ask for the second sms
6. there is sms_mo_control event for this 2nd sms
7. in ACTION_FILE_APDU you say "ok, send it"
Is this what you want? So what doesn't work? |
The flow is correct. My problem is: the first sms doesn't go out of the handset, it gets stuck. The second sms goes out properly. For the first sms i get this error from Blackberry handset: Failed to send message-SIM Toolkit control error. Please try again later. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
