GP2X Whats The 940 Used For By The Os?

[MadDog]

I've had to resort to using my serial connection, although as soon as the USB connection dies I can't update the my exe. Also don't look as good on my desk as having just the power and usb cord connected.

Any ideas when running some of my code on the 940 will kill the USB? ( excluding a daft mem walk bug )

 

[Vimacs]

i would gues that you may write some data in a area thats used for usb cacheing?

 

[rixed]

I've often experienced the same behavior in the same circumstancies.

I thought I was poking around on linux mem, but never invistageted.
Secretly, I think I though the bug would disapear by itself

 

[MadDog]

i would gues that you may write some data in a area thats used for usb cacheing?

Need to get the source and have a look, ugh.

 

[Dzz]

I've had to resort to using my serial connection, although as soon as the USB connection dies I can't update the my exe. Also don't look as good on my desk as having just the power and usb cord connected.

Any ideas when running some of my code on the 940 will kill the USB? ( excluding a daft mem walk bug )

Which parts of the memory are you using?

How do you attempt to use the USB?

If you're using stuff based on my demo code, check out the latest version in the demo development thread. I had an issue where I was not properly restarting the menu and this could manifest itself when attempting to start the USB from inside the menu.

I used almost all of the uppermost 16MB in the free version of Vektar using code on the 940 and as far as I know it does not break the USB. So either it's actually something else (like the above) or maybe something in the range 32MB-48MB that is having this effect.

 

[Squidge]

Check dzz's demo tutorial, he has had the same problem and fixed it.

The 940 just runs the video decoding software used by mplayer. It doesn't run anything else.

 

[MadDog]

Which parts of the memory are you using?

Very little at the mo, 32meg -> 33meg and a bit of the last 16megs for the frame buffer.

How do you attempt to use the USB?

I'm using it to connect to with putty and to transfer my exec's when built.

I'm doing some experimentation at the mo and getting some odd results. I think i've done something naughty.

 

[Dzz]

Which parts of the memory are you using?

Very little at the mo, 32meg -> 33meg and a bit of the last 16megs for the frame buffer.

How do you attempt to use the USB?

I'm using it to connect to with putty and to transfer my exec's when built.

I'm doing some experimentation at the mo and getting some odd results. I think i've done something naughty.

Ok cool. If you do find a land mine in that upper memory area somewhere please let us know. The only ones I am familiar with at present are code at the very beginning of the 48MB area which is apparently code used for video decoding, and the locations of the screen buffers for /dev/fb0 and /dev/fb1.

 

[MadDog]

Ok, this is a bit of an odd one. If I leave the 940 running when I exit the app I then can't when I re run the code
upload new code and run that. But if I stop the 940 on exit all is well, no idea why this is, but if your using the 940 don't be lazy like me and ctrl+c that app instead of pressing your exit button on the console.

But the loss of the USB is another issue thats gone away whilst stripping out code to find the problem, if you see what I mean. So I must have been crashing the 940 some how, although come to think of it I did have my frame buffers around that area. MMm, the memu is still running when I start my app from the command line. I have been killing it the last hour with the kill command, find the process ID with ps. Maybe that is getting upset by me crashing the 940, if thats what I was doing.

I don't like knowing why something was crashing before fixing it, but at least I can continue with what i've been doing.

Thanks guys.

 

[MadDog]

Ha, found the code thats killing my USB connection, but I have not idea why!!!! :huh:

If I call this on the 940 bang! If I don't all is fine. The odd thing is that the 940 carrys on running I just loose all connection with the gp2x and need to reboot. I've tried the code inline and it still kills it. This is really odd. The code when run on the 920 works no problem.

static void WaitVsync()
{
//Have to wait for no VSYNC then wait for it to start.
if( (regs16[0x2804>>1]&1) )
{
//No VSync
while((regs16[0x1182>>1]&(1<<4)) == 0);
//VSync
while(regs16[0x1182>>1]&(1<<4));
}
else
{
//No VSync
while(regs16[0x1182>>1]&(1<<4));
//VSync
while((regs16[0x1182>>1]&(1<<4)) == 0);
}
}

 

[Dzz]

Hmm, that's an odd one. What value does regs16 have? I assume it's an unsigned short *?

Hmm, that's an odd one. What value does regs16 have? I assume it's an unsigned short *?

Try reading 0x2804 once and setting a variable then using that variable instead of reading it every time. Perhaps reading that register has a side effect.

 

[slygamer]

regs16 is offset by the base address of the 940T, right?

 

[MadDog]

Yer, i'm setting the screen mode ok. The only difference is that in this case i'm reading them not writing to them. I've just had a good look at the docs to see if the cache was setup ok, did not want it to be some permission issue. But the code is fine so i'm going to start plucking at straws, maybe a compiler bug that does not like a while loop that does nothing. :blink:

 

[MadDog]

This is really very odd! The app runs fine and exits ok over and over again from the menu. But as soon as you run it the USB stops working!!! And this only happens if the following lines are used....

//No VSync
while(regs16[0x1182>>1]&(1<<4));

//VSync
while((regs16[0x1182>>1]&(1<<4)) == 0);

This is insane, I would'nt believe it if it was not happening right in front of me. I think i'm going to go to bed, it may fix it's self in the night.

 

[TKF15H]

I think i'm going to go to bed, it may fix it's self in the night.

I've tried that, but unfortunately the elves only make shoes. The ones that work on software are employed by Microsoft. >_<

 

[rixed]

I also experienced this problem.

The VSYNC registers are not in cause, I think. This is more probably because we read them constantly in a tight loop on the 940 : the 920 can not access IO as fast as it thinks he can (some drivers, perhaps usbnet also, rely on the bogomips to time their IOs).

If, instead of reading those registers in a tigh loop, you pause for a while between two reads (counting down to 100 is enought) then the bug disapear.

 

[Dzz]

I also experienced this problem.

The VSYNC registers are not in cause, I think. This is more probably because we read them constantly in a tight loop on the 940 : the 920 can not access IO as fast as it thinks he can (some drivers, perhaps usbnet also, rely on the bogomips to time their IOs).

If, instead of reading those registers in a tigh loop, you pause for a while between two reads (counting down to 100 is enought) then the bug disapear.

Brilliant!