Jump to content
IGNORED

Please test: FG99 firmware for both non-QI and QI


JJB

Recommended Posts

Getting ready for my VCF-SE exhibit, I found that one of my FG99 units is not recognized by either a QI or non-QI system when updated with the JJB CPLD and AVR files.  I tried the process multiple times, and each time the only resolution has been to revert to the original 1.3 files.

Link to comment
Share on other sites

Would you be able to confirm if this only happens when you're updating the CPLD, ie. if you use my AVR update but leave the CPLD at the official 1.3?

 

BTW is there any difference you can think of between that particular FG99 and the other unit(s) you have? 

Link to comment
Share on other sites

6 hours ago, JJB said:

Would you be able to confirm if this only happens when you're updating the CPLD, ie. if you use my AVR update but leave the CPLD at the official 1.3?

With just your AVR, both consoles recognize the device, but running GROM images on the QI crashes the system.

 

6 hours ago, JJB said:

BTW is there any difference you can think of between that particular FG99 and the other unit(s) you have? 

This one with the problems is a bog-standard first-run.

Link to comment
Share on other sites

Scratching my head here! If you revert back to the original CPLD firmware the QI should not see FG99 as an option (that's where the problem started ? ). If you are able to start a GROM image but it then crashes on the QI that sounds like the original AVR (the data bus being pulled up on the QI but low on the original, see earlier in thread).

 

I have re-attached the original CPLD file for your convenience; I will triple-check the updates I have supplied so far and report back.

ORG1_3-UPDATE.PLD

Edited by JJB
attachment
  • Like 1
Link to comment
Share on other sites

1 hour ago, JJB said:

Scratching my head here! If you revert back to the original CPLD firmware the QI should not see FG99 as an option (that's where the problem started ? ). If you are able to start a GROM image but it then crashes on the QI that sounds like the original AVR (the data bus being pulled up on the QI but low on the original, see earlier in thread).

 

I have re-attached the original CPLD file for your convenience; I will triple-check the updates I have supplied so far and report back.

I will try it again tomorrow.  Perhaps the restoration to the original CPLD did not take?  No idea.  It is in a working state right now, so at least a good start, there.

Link to comment
Share on other sites

Sorry for the late reply. I got majorly sidetracked.

 

Testing results:

  1. Started with 1Q version from previous tests (the logo said 1Q).
  2. Tested a few carts, all successful.
  3. Using the hex file loaded 1B. Success, 1B is in the logo. 
  4. Tested a few carts, all successful.
  5. Placed v1.3 (from FG99 homepage) on SD card as update.avr. Update successful, 1.3 in the logo.
  6. Tested a few carts, all successful.
  7. Placed v1.1 (from FG99 homepage) on SD card as update.avr. Update successful, 1.1 in the logo.
  8. Could not find v1.2 on the FG99 homepage, skipped.
  9. Placed jjb_update.avr (from this thread) on SD card as update.avr. Update successful, 1.3 in the logo.

Combinations:

  1. FG99 cart #1 + SanDisk 32GB class 10 SD card.
  2. Repeated with FG99 cart #2 + same SanDisk 32GB class 10 SD card, same steps and all successful.
  3. FG99 cart #1 + Verbatim 32GB class 10 SD card, same steps and all successful.
  4. Repeated with FG99 cart #2 + same Verbatim 32GB class 10 SD card, same steps and all successful.
  5. FG99 cart #1 + SanDisk 256MB SD card, same steps but failed at step #5. When pressing FG reset to start the update the lights continue to flash as if there is no card. This SD does work for the menu and loading carts but see ??? below.
  6. Repeated with FG99 #2 + SanDisk 256MB SD card, same failure as Combo #5.

Separate issue:

This is likely best kept as a separate but related issue. I mentioned it earlier, so I'll close this loop.

I reported that one FG card does not power-up with SD card ready for the TI menu, you must press the FG reset button. I then reported that it appeared to be fixed, but I was wrong. This is a combination failure. I have yet to see the Gigastone fail in either FG99 or on any console. However, the SanDisk 32GB in FG #2 in various consoles will mostly fail to select at power-up but success is random. The failure also occurs for the SanDisk 256MB but at a very low rate. This appears to be the same start-up race condition as the AVR update, the SD card isn't ready to be opened and fails. Since it is random and seems combo based, I assume it is "on the edge" of working.

 

I hope this all helps. Again, thanks for the work @JJB. I know this is done on your spare time and for the benefit of all of us in the community. Thanks!

 

Mark

 

 

  • Like 2
Link to comment
Share on other sites

23 hours ago, JJB said:

Scratching my head here! If you revert back to the original CPLD firmware the QI should not see FG99 as an option (that's where the problem started ? ). If you are able to start a GROM image but it then crashes on the QI that sounds like the original AVR (the data bus being pulled up on the QI but low on the original, see earlier in thread).

Supposedly, I have restored the original 1.3 CPLD, still running your 1.Q AVR.  The QI console recognizes the FG99 but still crashes on ZeroZap (a GROM game.)

 

No idea what is happening here.

Link to comment
Share on other sites

3 minutes ago, JJB said:

Just to make sure I got it, the bootloader update has not resolved anything or have I missed something ?

@JJB,

The bootloader code has resolved the update issue for the three 32GB SD cards. They all update the AVR when an AVR file is placed on the SD card. Also, as you described the bootloader continues to solve the update issue no matter which AVR file I load; 1.1, 1.3, jjb_update all can be loaded with the new bootloader from the SD card in any order and multiple times.

The bootloader change did not get the 256MB SD card to work, but this card works for normal operation, like loading cartridges from the FG99 menu. The 256MB intermittantly does have the power-up issue of requiring you to press the FG reset button (a slightly different issue and we should avoid mixing the two issues for now).

 

Does that make it clearer?

 

Mark

Link to comment
Share on other sites

13 minutes ago, mvancopp said:

Does that make it clearer

Yes! I am happy to provide another bootloader update with a longer delay to see if it makes the 256MB card work for updating. If it does it proves a SD card timing issue. 

 

Again, fully understand if you had enough of testing and just want to play with your TI?

Link to comment
Share on other sites

4 minutes ago, JJB said:

Yes! I am happy to provide another bootloader update with a longer delay to see if it makes the 256MB card work for updating. If it does it proves a SD card timing issue. 

 

Again, fully understand if you had enough of testing and just want to play with your TI?

I am willing to test more, whatever change you believe is worth a test; a small incremental change, + a few milliseconds, or a wild try that is never meant to be released, like 100-200 milliseconds (just to prove the theory).

 

I'm game... ?

 

Mark

Link to comment
Share on other sites

10 hours ago, JJB said:

@mvancopp I have generated 3 hex files with 50ms, 100ms and 200ms SD card delays. The version displayed for all three should be 1.L

 

Cheers,

 

Jochen

 

I loaded all three test hex files and none of them work with the 256MB SanDisk; the lights flash once a second indicating no SD card, I push the FG reset and the blinking continues unchanged, and no update is performed. It seems this may not be a timing-based issue.

 

I suggest for implementation for both the normal operation, non update mode, and for update mode you:

  1. Wait 1 ms
  2. Try and open the SD card
    1. If fails test for > 20 loops
      1. Not > 20 then goto #1
      2. > 20 then stop and error

This should minimize delay with systems/SD cards that setup quickly, so the least likely to cause an unintended side effect.

 

I don't know if you need to "close" the SD card before "opening" it again. I believe you said the startup opens the SD, looks for the update file, if found jumps to the update and reopens the SD card. If there is a "close" function it might be safer to call it before a second opening. Also, is the second open really needed? These are guesses since I have no experience with programing the bootloader.

 

I will be away from the TI computer starting tomorrow for about a week. Maybe it would help to get you the FG99 + 256MB SD + 32GB SD (with the startup selection issue) and you can debug on the live pieces? (Is there a debugger for this???) PM me if you are interested. I can mail them quickly.

 

Mark

  • Like 1
Link to comment
Share on other sites

All, 

 

Although I will do some further testing, in the end some members likely will need to initially use the programmer/ISP method to be able to update the AVR via SD in future. 

 

I am happy to do it for you, either you sending me your cart or me sending you my programmer with instructions. I do live at the arse end of the world/New Zealand so keep mail timeframes and cost in mind. 

 

An alternative could be 1 exchange FG99 that we could swap around until everybody is upgraded. 

 

Anyway, just some ideas

 

One last thing I thought of to try is to use a proper SD formatter app. Formatting with the standard Windows option is apparently less thorough, with the "quick" option not even formatting but just wiping the file allocation table. 

Edited by JJB
Clarity
  • Like 1
Link to comment
Share on other sites

18 hours ago, JJB said:

All, 

 

Although I will do some further testing, in the end some members likely will need to initially use the programmer/ISP method to be able to update the AVR via SD in future. 

 

I am happy to do it for you, either you sending me your cart or me sending you my programmer with instructions. I do live at the arse end of the world/New Zealand so keep mail timeframes and cost in mind. 

 

An alternative could be 1 exchange FG99 that we could swap around until everybody is upgraded. 

 

Anyway, just some ideas

 

One last thing I thought of to try is to use a proper SD formatter app. Formatting with the standard Windows option is apparently less thorough, with the "quick" option not even formatting but just wiping the file allocation table. 

I can also do this.. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...