#8858 - sgstair - Tue Jul 22, 2003 1:07 am
Hello, I'm working on a project and testing it on a Flash Advance 64M card. Access timings are set to 4/2 and prefetch is disabled.
Right now, the game works perfectly on a GBASP, but crashes at random locations on a normal GBA. Any idea why it might be doing this? I think it's likely it will work well on a professional cart, but can anyone give me more precice information?
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8860 - Dev - Tue Jul 22, 2003 5:18 am
Stephen,
I vaguely recall hearing something about the 64M cards having far more problems than virtually all other sizes -- if I come across something further in that regard, I'll follow up.
Can you create a really simple test case that causes it to crash? I.e. a simple loop that performs whatever operation you're doing that will generate a crash within, say, a few hours?
It might be easy to simply change the background color in a few places and when it crashes, you'll notice it's stopped changing -- by looking at the color, you'll be able to start narrowing down the area... or at least where in your logic it ran last before crashing!
If you've got a piece of test code that's small enough, it would probably be easy to isolate whether it's a timing issue, an interrupt issue, or just the cart being flaky.
Also, I've noticed that the GBA is far more prone to problems with dirty connectors and cart insertion placement than the SP is (although that might just be because it's much older...)
Still, every so often the cart won't boot, and by simply removing and then replacing the cart and backing it off a teeny bit fixes the odd weirdness... I don't really have any suggestion to offer regarding cleaning the contacts on the GBA, although looking at the ones here, they're pretty grimy! Same there?
Good luck!
Dev.
#8861 - sgstair - Tue Jul 22, 2003 5:38 am
Thanks for the reply :)
This project we've been working on for many months, and just recently were testing on gbasp - we knew it had some freezing problems on the regular gba with FA carts, and I imagine that's just a timing issue. (I'll try to hunt it down later, when it's more important)
The strangeness was just when we could test it on the gbasp, and it worked just fine, no freezing or anything.
Does anyone know of any hardware changes between gba and sp, cause there have to be some.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8862 - Dev - Tue Jul 22, 2003 6:26 am
It sounds like it could be the notorious 64M cart problem -- sometimes they're just plain flaky.
Have you tried cleaning the contacts on the GBA? Have you tried it with other units?
There's definitely some sort of HW changes between the GBA and SP, but no one's found anything that's "testable" yet...
The CPU has been revved, though (you'll be able to find a few images of the PCBs online somewhere, and the rev#s are bumped).
I strongly doubt that they'll have made any significant changes aside from optimization to reduce the die, but you never know... it doesn't seem likely that they'd want to screw around with fixing the bugs in the core that are already there just because they're making a new chipset.
Tepples, any thoughts?
Based on what I've seen elsewhere, there are definitely power-related issues from the backlight on the SP, but that should theoretically cause *more* problems not fewer!
Still, as I mentioned, you might think about adding a color change to your BG at the start of various top-level functions and making a test build that you just let run -- it'll rapidly let you isolate what general region was the last to execute before it died.
Dev.
#8870 - sgstair - Tue Jul 22, 2003 3:22 pm
Ok, I will play with the color changes - see what turns up.
The contacts are fine. We've tried this many times, with brand new carts and brand new gbas / gbasps
It could easily be the notorious 64M problem, I suppose the 'problems' with the gbasp having lower voltage or something are actually a bonus in this case?
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8878 - Dev - Tue Jul 22, 2003 5:46 pm
The only time I've heard of ANY problems with the GBASP's voltage is when people try to burn their flashrom and they're running on batteries with the LCD backlight turned on.
I'd doubt that it's the cause of your troubles, but you never know.
Dev.
#8879 - sgstair - Tue Jul 22, 2003 5:48 pm
I think a voltage difference might be the issue, since it does work properly on the sp, and crashes randomly on a normal gba.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8885 - Dev - Tue Jul 22, 2003 11:05 pm
If you don't have anything other than 64M carts, you might want to post a small demo that people could download and try on the 128M or 256M units.
Be sure to fill us in when you find the cause!
Dev.
#8898 - ampz - Wed Jul 23, 2003 1:53 pm
The GBA is 3.3V and there is no reason why the GBASP should not be 3.3V as well.
#8909 - sgstair - Wed Jul 23, 2003 4:53 pm
Maybe not a voltage difference but a current difference?
Even a voltage difference is possible - the gbasp has a different kind of battery altogether, and has a backlight too... people reporting problems writing flash carts is somewhat indicative of this.
There are some hardware differences, though subtle.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8924 - ampz - Wed Jul 23, 2003 10:13 pm
| sgstair wrote: |
Maybe not a voltage difference but a current difference?
Even a voltage difference is possible - the gbasp has a different kind of battery altogether, and has a backlight too... people reporting problems writing flash carts is somewhat indicative of this.
There are some hardware differences, though subtle.
-Stephen |
If you knew a bit about electricity you'd know that there cannot be a difference in current unless there is a difference in voltage for a given load (like a flashcart).
The type of battery is not important since both the GBA and the GBASP use a switch mode power supply (SMPS).
It is possible that the SMPS in the GBASP is weaker than the one in the GBA, making it fail when the load goes too high.
As you say, the load on the GBASP IS higher due to the backlight. It might make the SMPS fail if combined with a very power-hungry cart. Who knows.
People having problems with the SP should try shutting off the light.
#8925 - Dev - Wed Jul 23, 2003 10:44 pm
Yes, technically it's a current difference, but I didn't want it to get too complicated.
The fact is that the GBASP problems I've heard of ONLY occur when trying to erase and burn a flash rom when the unit is battery-powered and the light is on.
If running regular code, there should be no difference.
I'd suspect a BUG in the software rather than one in the hardware... at least until it can be definitely proven otherwise.
Dev.
#8931 - sgstair - Thu Jul 24, 2003 2:36 am
| ampz wrote: |
| sgstair wrote: | Maybe not a voltage difference but a current difference?
Even a voltage difference is possible - the gbasp has a different kind of battery altogether, and has a backlight too... people reporting problems writing flash carts is somewhat indicative of this.
There are some hardware differences, though subtle.
-Stephen |
If you knew a bit about electricity you'd know that there cannot be a difference in current unless there is a difference in voltage for a given load (like a flashcart).
The type of battery is not important since both the GBA and the GBASP use a switch mode power supply (SMPS).
It is possible that the SMPS in the GBASP is weaker than the one in the GBA, making it fail when the load goes too high.
As you say, the load on the GBASP IS higher due to the backlight. It might make the SMPS fail if combined with a very power-hungry cart. Who knows.
People having problems with the SP should try shutting off the light. |
I know quite a bit about electricity - and you've left resistance entirely out of the mix. It is possible that the SMPS will vary, not fail, in the sp when there is a heavy load, in which case the voltage and current will fall. however, the constant resistance in the equation may be different between the sp and the regular gba, causing there to be a different voltage/current ratio. If the SMPS were actually to fail, who knows what would happen, it's likely the cpu would be first to go though.
Also, I'm NOT having problems with the SP, I'm stating that this program WORKS on the SP, and DOESN'T on the regular gba.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8932 - tepples - Thu Jul 24, 2003 3:37 am
I have five distinct test environments available to me:- a Glacier GBA with a Visoly Flash Advance 256 Mbit cart
- a Glacier GBA with an MBV2 cable
- a GB Player with with a Visoly Flash Advance 256 Mbit cart
- a GB Player with an MBV2 cable
- VisualBoyAdvance
I'd be happy to test the code. Can you put source code and/or a binary on a public HTTP server and give us the URI?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#8935 - ampz - Thu Jul 24, 2003 10:21 am
| sgstair wrote: |
| ampz wrote: | | sgstair wrote: | Maybe not a voltage difference but a current difference?
Even a voltage difference is possible - the gbasp has a different kind of battery altogether, and has a backlight too... people reporting problems writing flash carts is somewhat indicative of this.
There are some hardware differences, though subtle.
-Stephen |
If you knew a bit about electricity you'd know that there cannot be a difference in current unless there is a difference in voltage for a given load (like a flashcart).
The type of battery is not important since both the GBA and the GBASP use a switch mode power supply (SMPS).
It is possible that the SMPS in the GBASP is weaker than the one in the GBA, making it fail when the load goes too high.
As you say, the load on the GBASP IS higher due to the backlight. It might make the SMPS fail if combined with a very power-hungry cart. Who knows.
People having problems with the SP should try shutting off the light. |
I know quite a bit about electricity - and you've left resistance entirely out of the mix. It is possible that the SMPS will vary, not fail, in the sp when there is a heavy load, in which case the voltage and current will fall. however, the constant resistance in the equation may be different between the sp and the regular gba, causing there to be a different voltage/current ratio. If the SMPS were actually to fail, who knows what would happen, it's likely the cpu would be first to go though.
Also, I'm NOT having problems with the SP, I'm stating that this program WORKS on the SP, and DOESN'T on the regular gba.
-Stephen |
I did not leave out resistance. Resistance == load.
I did not want to use the word resistance since a flashcart is anything but a purely resistive load. What I'am saying is just that since the voltage is the same, and the flashcart load is the same, there cannot be any difference in the current the flashcart sees. That's all.
For the flashcart voltage/current to vary, there must be a problem with the SMPS.
I'am well aware that you are having problems with the GBA, and not the SP. That is indeed a strange problem.
The GBASP cart connector is surface mounted, and the leads are probably slightly shorter. Might help the timing 0.1ns...
#8942 - Cyberman - Thu Jul 24, 2003 3:03 pm
If you are concerned about a voltage difference, changing the speed of the components, would be by lowering the voltage would slow the components down. The only real way to know what is going on would be to put the cartridge power supply rails on an ocilloscope and watch the wave form. A 20mhz scope will be all you need. Setting the triggering might be a bit of a challenge (IE finding something to trigger it so the wave shows something), though if you are in an endless loop it won't be as bad (each time the address is reloaded would be a good event to trigger on).
You can also look at the clock skew differences. Since all of this would be on the cartridge not the GBA, just open said cartridge and put the probs in I guess. :)
As for what the problem might be, there really isn't enough information to make a guess (and that's all it would be).
SMPS supplies will vary depending on the passive components and the controller chip, if the SMPS chip is different or the same etc. It depends on what there input voltages is what inductor they used, what decoupling cap they used on the power input to the SMPS and what post inductor filter capacitor they used that will determine it's behavior. In other words.. too many things, since a schematic for the SP is not likely to magically appear you can only derive information by what you observe.
Actually if the SP power supply is a bit better than the GBA then it's likely that supply voltage to the cart would be more stable. Depending on how much hardware they have on the cart the chip can be drawing to much current at the right time causing it to glitch. I've noticed this happens with designs that are close to the systems tolerances (I should say things I've made that are.. ;) ).
Experiment you need to thiink of ways to isolate each possibility.
If you REALLY think it's the power supply, decouple it, by adding an external power supply to the cartridge, granted it may take a while to put together, it does guarentee if it is the power supply or not. A nice LDO will work nicely and you can use a 5V supply with it, these are simple and cheap.
If you think it's the timing.. change the wait state used with the cartridge at the very begining of your program, that is something you can do with the GBA entirely in software perhaps the most practical of all the ideas ;)
Cyb
#8946 - sgstair - Thu Jul 24, 2003 5:18 pm
At the heart of what I am suggesting, is that the cartridge interface circuitry in the SP has a different resistive load than the gba. This resistance is then combined with the resistance of the cart, and DOES cause a different voltage/current ratio.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8947 - sgstair - Thu Jul 24, 2003 5:25 pm
Thanks cyberman - I'll be checking all this when I have access to the equipment (in a few weeks, when college starts again)
I think it is the timing, but clock skew is likely the issue, the flash cart may not be good enough to do what I want it to do. My instinct tells me it will work on a commercial cart, but I'm not sure about that either. I'll try to shift it to a lower waitstate - that might help. I'll also rewrite the interrupt handler, as I'm pretty sure it's interrupt related.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#8998 - Dev - Sat Jul 26, 2003 12:30 am
Now that you mention it, I recall some older 64M carts having trouble at anything faster than 4/2.
If you're using 3/1 and expecting it to work on older 64M carts, that could be the problem.
Dev.
#9002 - sgstair - Sat Jul 26, 2003 2:18 am
I mentioned already - I am using 4/2 for timing
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#9003 - Dev - Sat Jul 26, 2003 2:24 am
Well, I'm tapped then. You haven't provided enough information to help any further.
Be sure to tell us once you figure out what the problem was.
Dev.
#9005 - sgstair - Sat Jul 26, 2003 5:57 am
I'm not particularly looking for an answer - just a good guess. I was wondering if anyone had come across this issue before, cause it is rather obscure and I'd never seen or heard of it before. Why a program works perfectly on the GBA SP and randomly freezes on the regluar GBA with the same cart, same everything else just doesn't make much sense.
Anyhow- thanks to everyone for your suggestions/insights, I'm sorry but I'm not in a position to provide more information or else I'd have a rom out there for you to play with.
-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/
#9013 - Dev - Sat Jul 26, 2003 4:21 pm
My best guess is that either you've got a bug, or the latest chipset has fixed some weird issue relating to DMA and/or Interrupt generation.
If infact you've discovered a hardware-based timing issue, it may be possible to use it to detect GBA vs. GBASP.
Dev.