Hi! I have a problem with the DSWiFi, i will post here the data to see if some DSWiFi code guru can see a total solution.

Hardware: DS Lite (new), with NinjaDS Stick.

Problem: All homebrew programs fails at connecting keeping in shearching AP forever, all Oficial Nintendo DS games work well. Tested with all combinations posible (WEP,DCHP,Etc.)

After doing a bit of research in the source of the DSWiFi (all versions included the latest 0.3c) i found that it nevers receives data, to be exact enters in the function Wifi_Intr_ExEnd but never enters in the while, so i tought that the hardware is not correctly initialized, but after doing more research casually found a partial solution:

Partial Solution
Compiling the DSWifi lib in the R17 version of DevkitPro works!!!
Compiling it with the /O0 (no optimize) of any Devkitpro version also works!!!

So i think is a problem with the new optimitations of GCC 4.1.1 (r18 +) that must do someting bad at initializing the hardware, optimizing part of the code that must not be optimized or making it too fast for Ds hardware accept it well.

With recompiling the lib and the homebrew programs works somewhat well but i still have sometimes problems with accept and recv, and the worse of all... i dont have the source code of all homebrew programs (BeUp )

My DsWifi and Ds hardware knowdeledge are not enought to solve this problem so please if someone have the same problem please comment!.

I have a DS Lite bought in October 06 and I have the same problem, so I'm totally stoked that you've found a clue about it. One correction: You probably meant to write "Wifi_Intr_RxEnd" as the function with the problem, right?

You say the loop is never entered, eh? I wish I could help figure it out. WIFI_REG(0x5A) looks like it tells you where to read a packet from, but that's the only reference to WIFI_REG(0x54) I can find in the code at all, so who the hell knows what it is?

Edit: On further thought, I guess it's supposed to be the end of the packet buffer.

BTW, how did you figure this out? I'm a C programmer but I'm totally new to embedded programming in general and DS programming in particular. Can you insert printf's in this code somehow?

W00T! It works here too. Note that you only need to compile the arm7 part with -O0. I left optimizations on for the arm9 code and it works fine.

Now we just need all the homebrew developers to compile their wifi libs that way....

Edit: Yowsa! I just used wifi_lib_test in wardriving mode and found *68* access points by just walking around my apartment!

Yes i mean Wifi_Intr_RxEnd, the E is the key that is at the side of R and i misstyped it XDDD
Im absolutelly noob on the DS wardware too, i found this only by pure luck, testing apps i found that an older version of wifi_test works (0.2a i think was) and recompiling it didnt work because i was using DevkitproR20, so after digging a bit i found the correct versions the make it work, and etc..

There are others homebrew that i tested later and works without recompile:

DSorganize (its compiled with R17 version)
DsLinux (they use they own version of dswifi, and can be they corrected something)
wifi_test0.2b or older taken from the page of the autor

So if anyone cant conect with other programs and can with these, you have the same problem.
Please add more homebrew if you found it!


Edit:
To test the the functions in the arm7 code i copy some variables i want to a region in shared memory and modify the arm9 wifi_test app to print out these values. I used some ints for the counts and a small char[64] to look what is doing. You can put more things if you use the FIFO queue properlly but i didnt want to interfere in the wifi_lib work.

this is awesome. i can't wait for my ds lite to have wifi connection.
Pointy Remote wifi works for the ds lite which was weird since that was made about a year ago and all the new wifi stuff doesn't work for my dslite

some homebrews that don't work for my DS lite (even with 0.3d/0.3e wifi update)
-Bunjallo: new DS browser with simple browser stuff (no special html stuff, no pics, flash, etc)
http://code.google.com/p/quirkysoft/

-dsAIM: AIM instant messenger
http://forum.gbadev.org/viewtopic.php?t=10...c&start=240 <-- its somewhere in the forum

-Beup


-DSFTP 2.4

btw,
will there be a place where i can dl ur updated version of the homebrew or will u give it to the developers to distribute?

Hiya Magin,
This is an interesting discovery but also very strange, as the apps I have compiled with devkitpro R20 using -O2 do indeed work correctly on my DSlites (though they're the older kind.)
I can think of a few places in the code where optimization might cause problems... but if it were a bad problem I would have noticed, instead it seems like it might be a timing issue or maybe very specific to the new hardware?
If you have a chance, can you test the wireless lib test app I've compiled, at http://akkit.org/dswifi/wifi_lib_test.nds -- this *is* compiled with devkitpro R20, using -O2... but so far, from what I know it does work for everyone.

Thanks,
-Stephen

Tested: No AP found as always, no packet received.
Better if lokicat test it too.
Thanks for taking a look at it anyways!!!

Magin, lokicat; I think this is probably more likely related to the flashcard you're using to run the wifi apps - can you tell me what flash card you're using? There may be a hidden problem with the lib that doesn't show up except under very specific timing, which is triggered by the way the flashcard boots or something... but if I can't duplicate it, it's a lot more difficult to fix.

-Stephen

1. I'm using an ezflash 5 with a Japanese Kingston 1GB microSD.

2. Your wifi_lib_test doesn't work for me. When I recompile it against my -O0 arm7 dswifi lib then it works.

However, the -O0 trick doesn't seem to be a cure-all. I got DSFTP compiled against my dswifi (which was *not* fun, by the way) and it basically works, but it tends to crash pretty often. I suspect you're right about the timing issue, though I don't understand how the flashcard figures into it. (like I said, I'm a bit of a newbie) Maybe I'll try fiddling with the ez5 memory timing settings...

Edit: I tried speds 2, 5, 7, and 10 with the same results. No access points detected.

lokicat: thanks - I'll look into it further.
Please note that the -O0 'trick' is just that, it's not changing anything except for how optimized the code is - if there are timing-specific problems, it has the potential to change them, but it is generally not fixing anything unless the compiler is broken... which it's not.
I still don't know what the problem is, but I'll do what I can to find out...

-Stephen

I use a NinjaDS Stick version tested with bios 1.03 and 1.05 and SD speeds 1, 2, 3

About the -O0 trick note that the R17 (gcc 4.1.0) version compiles without problems and the laters (gcc 4.1.1) needs the -O0 so must be something about the news optimitations of this version.


If you wish you can write a little app to show the registers and i will execute and copy the results, to look what registers are wrong set or something, for my is too hard to program it at my level XDD


Very much thanks for the annoyance!!

As somebody who's written a compiler or two, I understand what -O0 is doing. I'm stoked on -O0 because it takes me from being totally unable to connect to any access point, period, to having somewhat unstable wireless access, which is huge improvement.

Also as somebody who's written a compiler or two, I can't say I'm very confident the compiler's not broken, just maybe that its brokenness isn't the cause of this problem. All compilers tend to be broken in one way or another...



Awesome. If there's anything I can do to help just say the word.

There are more people with the same problem as i see in the lasts topics.
Surelly a part of wifi_lib never worked and no one noticed because the older DS has already the correct sets by default and the very new ones does not have them correct. For much i look in the code i dont see anything suspicious, sgstair has do a awesome job and all registers are defined volatile as they must be, so find what is bad optimised will be very hard...

LOOOOOOOOOOOOOOOOOOOOOOOL
I finally hunted down the BUG!!!!!!!!!!!!!!!!!!

in the function:

void Wifi_WakeUp() {
u32 i;
WIFI_REG(0x8036)=0;
for(i=0;i<100000;i++) i++;
WIFI_REG(0x8168)=0;

i=Wifi_BBRead(1);
Wifi_BBWrite(1,i&0x7f);
Wifi_BBWrite(1,i);
for(i=0;i<400000;i++) i++;

Wifi_RFInit();
}

must change the u32 i to volatile u32 i
so it remains

void Wifi_WakeUp() {
volatile u32 i;
WIFI_REG(0x8036)=0;
for(i=0;i<100000;i++) i++;
WIFI_REG(0x8168)=0;

i=Wifi_BBRead(1);
Wifi_BBWrite(1,i&0x7f);
Wifi_BBWrite(1,i);
for(i=0;i<400000;i++) i++;

Wifi_RFInit();
}

Explanation: being smart as is the compiler it has tought that the "for" only maked the i value 100000 and 400000 so it simplified it to a asignation, making it to not wait the time expected here to init the hardware.
The volatile makes no optimize the fors.

Surelly old DS comes with Wifi kinda activated on power on and the news ones not, and because of it no one noticed until now.


Please lokicat and moncul test the changes and post here the results

Now we have to make the change on the ofical wifi_lib and wait for the autors recompile their aps

P.D.: If they put this change in the source, dont forget to put a litlle credit for me

Magin: Yes, that's exactly what the problem is. I suspected it was the other day, and mentioned it to crediar on IRC, but I haven't done anything about it yet. The better solution (and what the nintendo driver uses) is to call the swi delay function, rather than running around in a waitloop. I'll try to get this fix put in the lib soon, regardless of how it gets implemented.

-Stephen

Yes, the optimisation I believe would see those 2 for-loops as time-wasters (which they are) and would "optimise" the code - that is, remove the loops. Well done for spotting it. I don't have a DS so I can't do any testing or whatnot for you.

You're right Magin !!!
I made the change, recompiled (with original makefile : without -O0 of course) the dswifi lib then the wifilibtest and it works perfectly !
Very impressive !
i hope the dswifi lib will be released with taht change so many non open-source homebrews will work for everyone !

Congratualtions !

omg Magin, where do u learn about this stuff? xD

Finally the changes are putted in the official version!!!
Now wait the autors recompile their apps :D____

Thanks you all!!!

Hey, great news! Good job, guys!

I have the following problem =
Normally homebrew with the wifilib dont works.
But the recompilled wifilib-text app with this fix works.
Now Iv tried to fix the wifilib by myself, but it dont works.
Iv downloaded the src, changed and compilled, then Iv pasted the 2 folders into the lib and compilled some test apps, but anythink works.

Can maybe someone upload the compilled files with this fix D: ?

I've been suffered from this problem too.
I couldn't make it by myself, so I asked a Japanese programmer named Rudolph.
Here's his blog.(Unfortunately, all the stuffs are Japanese)
http://blog.so-net.ne.jp/Rudolph/

I can translate it for you, but you should keep in mind that I'm not so good at English and Japanese because I'm Korean.

Below is the contents from the Rudolph's blog.

WiFiを使用するHomebrewなソフトについて、現在分かっていることを
まとめておきます。
I'm arranging what I know about bunch of problems of homebrew softwares which uses Wi-fi connection.

当然正規のゲームでは問題ないのですが、devkitProのlibdswifiに不具合が
あるため以下のDSではWiFiが動作しません。
It is natural that there's no problem with DS games, but because devikit pro and libds have problems, it is impossible to connect on the Wi-fi homebrew with DSs listed below.

①Firmware用に512KBのFlashが搭載されている機種(iQueDS、韓国向DS、台湾向DS...)
①DSs which are loaded with 512KB of Flash memory for the firmware.(iQueDS、Korean version of DS、Taiwan version of DS...)

②最近のDS(詳細不明)
②Newest DS(Don't know about detailed things)

①については、Flashのサイズが変わったことによりユーザの接続情報が格納されている
アドレスが変更になっているようです(0x03FA00から0x100*4が、0x07FA00からに変更)。
In the case of no.①, I think the address where the user connedtion settings are loaded is changed, according to the change of the size of flash memory.(The address from 0x03FA00 to 0x100*4、is changed to start from 0x07FA00)

②のタイプについては詳細は不明ですが、最近出荷されているDSでは搭載されている
RFユニットが変更されているのか電源ON時の初期状態でWiFiが無効(Shutdown)に
なっているようです。libdswifiのWifi_WakeUpが正常に動作していない為、動作しません。
I'm not sure about details but, in the case of no.②, the change on RF unit of the newest DSs is not enabled to use Wi-fi connection(the state of shutdown) when the power is switched on. Because Wifi_WakeUp of libdswifi is not working properly, Wi-fi connection is not working either.

「wifi_arm7.c」　(上記2点を修正したlibdswifi 0.3.1のwifi_arm7.cのソース)
「wifi_arm7.c」　(The source of wifi_arm7.c from libdswifi 0.3.1 that solved the problems of ① and ② mentioned above)

libdswifiを使って作成された、WiFiを使用するHomebrewなソフトを強制的に動かす為の
パッチも公開します。
I'm releasing the patch that forces to work the Wi-fi Homebrews which are based on libdswifi.

①に対応する為のパッチ(通常のFlashが256KBのDSでは当ててはいけません)
The patch to solve the problem ① (Attention: This patch should not be applied on old DSs which uses 256KB of flash memory)

　　　"FE 0B 80 E2 02 0C 80 E2" を検索して、そこを
　　"7F 0A 80 E2 0A 0C 80 E2" に、8byte書き換える
　　　Find "FE 0B 80 E2 02 0C 80 E2" with your HEXCODE Editor(such as UltraEdit etc.,)
　　Change into "7F 0A 80 E2 0A 0C 80 E2"



②に対応する為のパッチ(チョット強引だが、全てのDSで使用できる？)
The patch to solve the problem ① (It is somewhat compulsive but I wonder this might be used by all DSs)

　　　"81 1C 83 E2 02 39 83 E2 10 40 2D E9 B6 23 C3 E1" を検索して、そこを
　　　"01 1C 83 E2 10 40 2D E9 B6 23 C3 E1 0D 00 00 EB" に、16byte書き換える。
　　　Find "81 1C 83 E2 02 39 83 E2 10 40 2D E9 B6 23 C3 E1"
　　　and change into "01 1C 83 E2 10 40 2D E9 B6 23 C3 E1 0D 00 00 EB"

　　　そこから56(0x38)Byte後の
　　　56(0x38)Byte from that address, you could find these addresses

　　　"10 40 BD E8 XX FF FF EA 04 E0 2D E5 40 00 A0 E3" -
　　　"XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX" の部分を
　　　"01 00 00 EB 10 40 BD E8 1E FF 2F E1 06 28 A0 E3" -
　　　"02 28 82 E2 01 20 52 E2 FD FF FF 1A 1E FF 2F E1" に、32byte書き換える。
　　　(XはVerにより不定)

　　　Change the address "10 40 BD E8 XX FF FF EA 04 E0 2D E5 40 00 A0 E3" -
　　　"XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX"
　　　into "01 00 00 EB 10 40 BD E8 1E FF 2F E1 06 28 A0 E3" -
　　　"02 28 82 E2 01 20 52 E2 FD FF FF 1A 1E FF 2F E1"
　　　(XX varies with the version of libdswifi)

一応、DSLiveWeatherで動作を確認しましたが、いつもの通り責任は持てません。
特に②のパッチは強引で、Wifi_Shutdown()を潰していますのでソースが公開されている
場合は修正したwifi_arm7.cでリビルドした方がいいです。
I confirmed working with DSLiveWeather but, as usual, I don't have any responsibilities for applying this patch.
Especially, it is recommended to rebuild the source code with corrected wifi_arm7.c when you have the source of the Wi-fi homebrew because the patch no.② is quite compulsive that it is ignoring Wifi_Shutdown().

I made an executable patch based on my post with CodeFusion 3.0.
Here's the link.

NDSL_Wi-Fi_Patcher.zip

Attention: Do not apply this patch if you don't have any problem.

Erm... SgStair, if what Magin said is true, could you please change the version number?

Unless the release is official... I don't think too many people may download the newer version.

Example: DSLiveweather was just recompiled and released, but it doesn't work on my new DSLite.

Plus In the past few weeks nobody has bothered to recompile their apps with a working version.

So could you please include this fix in a newer version number release soon? Maybe v0.3.2 or something?

Thanks.



Link doesn't work, could you fix please?