Re: SDSynchronousBusRequest taking long time

Thanks for the much helpful info. We will follow your suggestions to find the
problem.

Associated with this I have some more questions. The SDIO card we have is
NOT identified by the Symbol M70 running Windows Mobile 5.0 after a reboot.
We have to remove the card and re-insert it back for the OS to recognize the
card and load the driver dll. The registry settings are right as the driver
loads successully when we re-insert the card. So questions are:
1. Are there sources in Platform Builder that I can add some print
statements and find out what is happening during the boot process when the
devices are being loaded?
2. Is it possible to write a EXE that I can run to force load the driver
instead of physically re-inserting the card.

"voidcoder" wrote:


> Can you suggest me how to go through the debugger? The code runs on a
> Windows Mobile device. Currently I am debugging by writing to a file. I
>

Well, if you have no possibility to debug on the target device
it is getting more complicated. There are not too much things
you can do about it on a ready made WM5 device. Especially because
the bottleneck may be in the lower level sdcard host controller
driver (device specific) and not in the sdbus driver
or sdcard lib (device independent thing). Try different
WM devices, try to analyze sdcard sources, fortunately you have
PB installed. Look here:

....\WINCExxx\PUBLIC\COMMON\OAK\DRIVERS\SDCARD\SDBUS\*


It is definitely worth buying a development KIT if you
want to untie your hands. Try to google around, there
are enough devkits with SDCARD on board and Windows CE
support ...


--
Oleg


Advait wrote:
Sorry I was not aware that I could taget multiple groups in "to" field.
Can you suggest me how to go through the debugger? The code runs on a
Windows Mobile device. Currently I am debugging by writing to a file. I
thought SDSynchronousBusRequest is a call in a library provided by Microsoft.
How can I step through? I am new to Platform builder.
Thanks for your help.

"voidcoder" wrote:

Why not just step in debugger and see where
it spends so much time?

Also separate cross posting is evil. List all
target groups in "to" field if you want to post
to multiple groups.


--
Oleg


Advait wrote:
Hi,

From the SDIO driver we get from Arasan they use SDSynchronousBusRequest()
to issue a bus request to their chip.

We timestamp before and after calling this API, and it takes > 230ms. Why it
takes so long and how can we make it

much faster? The following are the code sample:

SDSynchronousBusRequest(pDevice->hDevice,
SD_CMD_IO_RW_EXTENDED,
argument,
SD_WRITE,
ResponseR5,
&response,
1,
blockLength ,
pBuffer,
0);



where:

argument = BUILD_IO_RW_EXTENDED_ARG(SD_IO_OP_WRITE,
SD_IO_BLOCK_MODE,
pDevice->Function,
wAddress,
SD_IO_FIXED_ADDRESS,
1);


SD_COMMAND_RESPONSE response


Your kind responses are greatly appreciated.


.

Relevant Pages

  • Re: SDSynchronousBusRequest taking long time
    ... Both are including SDCARD support and both are natively ... Here you can find some more boards with Windows CE ... You may need to sign your driver ... > card and load the driver dll. ...
    (microsoft.public.windowsce.embedded)
  • Re: SDSynchronousBusRequest taking long time
    ... Instead copy SDCARD tree to your platform ... While sdbus driver is a true ... > card and load the driver dll. ... on WM target to load your new sdbus driver instead of original ...
    (microsoft.public.windowsce.embedded)
  • Re: SDSynchronousBusRequest taking long time
    ... you can't get any boot log on retail WM device. ... You may need to sign your driver ... Instead copy SDCARD tree to your platform ... > card and load the driver dll. ...
    (microsoft.public.windowsce.embedded)
  • Re: SDSynchronousBusRequest taking long time
    ... Instead copy SDCARD tree to your platform ... While sdbus driver is a true ... > card and load the driver dll. ... on WM target to load your new sdbus driver instead of original ...
    (microsoft.public.windowsce.embedded)
  • RE: [UPDATED PATCH] EFI support for ia32 kernels
    ... >> reuse a single driver image for multiple architectures assuming there ... As one of the people responsible for the EFI Specification and our ... Perhaps the UNDI network card interface that Intel developed ... BIOS can't shadow that much ROM code. ...
    (Linux-Kernel)
Loading